Overly Generic Engines

Started by
12 comments, last by solinear 19 years, 7 months ago
Righty. I was thinking about my RPG/SRPG (Strategy Role Playing Game) engine dilemma, and I was thinking about how to make it... Overly Generic - so that (through the use of scripts or such) I can *seamlessly* switch between the two genres for some interesting effects. All the SRPG games I've seen so far (Tactics Ogre, FFT etc) have not included the "walk around" RPG element. I was thinking of making an SRPG engine that did include this (or an RPG that did strategising (sp?)) This way, I can switch from a single character hack 'n slash to a multi character turn-based brawl. I don't think this would be entirely too dificult to do, but would it ruin the gameplay? Granted, I'm intending the game to be comical in nature (what else does a hobbiest have going?) so it shouldn't be that detrimental... And think how much nightmare scripting will this take... not to mention a pain-in-the-butt map editor... Oh well. Suggestions? Comments? Flamethrowers? All welcome. [Edited by - Mushu on August 21, 2004 8:28:50 PM]
Advertisement
What RPG *doesn't* have strategic combat? Perhaps I'm just misunderstanding...
Quote:Original post by Telastyn
What RPG *doesn't* have strategic combat? Perhaps I'm just misunderstanding...

err... like "strategy game rpg": (technically you can argue that every game with 'combat' has 'strategic combat'.)
  • Tactics Ogre
  • FFT
  • Fire Emblem
etc.

As compared to "rpg" (no examples needed) which lack the "grid-based moving element", and are limited to a strict set of characters (cannot "make" or "train" more).

An SRPG differs from a Strategy game in that your units/characters have the ability to "level up" over time, learn new skills, and become stronger.

An RPG differs from an action/adventure game in that your characters can "level up" (usually), and that (usually) it is turn based in one meaning or another.

But those are just my definitons, and if anyone wants to start a new thread about this, I think it would certainly be clarifying.
Yeah, you are trying to undertake something huge. I would make heavy use of scripts. For example, make it so you can walk around with collision detection. For battles, just script the walking (don't let the user dierectly control it). Then, gradually add more and more funcitonality until you have everything you will need, and use what you've made when and how you need it (in battles, while walking around, etc.).

EDIT: Mushu, the background is dark grey, not black.
Not giving is not stealing.
Quote:Original post by thedevdan
Yeah, you are trying to undertake something huge. I would make heavy use of scripts. For example, make it so you can walk around with collision detection. For battles, just script the walking (don't let the user dierectly control it). Then, gradually add more and more funcitonality until you have everything you will need, and use what you've made when and how you need it (in battles, while walking around, etc.).

EDIT: Mushu, the background is dark grey, not black.

Well, I've got a lot of it done (pretty much all of it graphical, not gameplay though), and since I've been consistant only with my indecisiveness, I can easily sway either way with it.

The thing is, there would be two separate types of battles:

-RPG battles where there is no movement, only actions; and
-SRPG battles which do involve user controlled movement.

There's no way I would try and interjoin the two somehow; some battles will be one style, and others the other style.

And I know the background isn't black. I just put the text as black so everyone has to squint ;)
Perhaps I'm still not seeing the subtle distinction, but every D&D game I've played since the Gold box games did this. The gold box games even had distinct tile movement for combat.

They mostly didn't do it seamlessly, but that's a engineering problem and not a game design problem.
Quote:Original post by Mushu
Quote:Original post by thedevdan
Yeah, you are trying to undertake something huge. I would make heavy use of scripts. For example, make it so you can walk around with collision detection. For battles, just script the walking (don't let the user dierectly control it). Then, gradually add more and more funcitonality until you have everything you will need, and use what you've made when and how you need it (in battles, while walking around, etc.).

EDIT: Mushu, the background is dark grey, not black.

Well, I've got a lot of it done (pretty much all of it graphical, not gameplay though), and since I've been consistant only with my indecisiveness, I can easily sway either way with it.

The thing is, there would be two separate types of battles:

-RPG battles where there is no movement, only actions; and
-SRPG battles which do involve user controlled movement.

There's no way I would try and interjoin the two somehow; some battles will be one style, and others the other style.

And I know the background isn't black. I just put the text as black so everyone has to squint ;)


You could put them together, as long as the actual actions are the same. I guess they aren't though?
Not giving is not stealing.
Quote:Original post by Mushu
Well, I've got a lot of it done (pretty much all of it graphical, not gameplay though), and since I've been consistant only with my indecisiveness, I can easily sway either way with it.

The thing is, there would be two separate types of battles:

-RPG battles where there is no movement, only actions; and
-SRPG battles which do involve user controlled movement.

Sorry - it was late at night (= bad) when I wrote this. I also meant to add that the multicharacter battles will be strictly turn-based, while the single character battles will be done in real time, hack 'n slash style.

The actual programming of it shouldn't be all that bad, because I would just have to add another game state; graphically it's all the same.

The real problems here are
  • how to make the abilities etc interchangable between turn-based "select your attack" and real time button mashing.
  • (programmically) fixing my script readers to accomidate this change
  • some other stuff.

The reason I thought about doing this is my engine (right now) is set up as a hack 'n slash. Then I considered how to add more friendly characters to it. Since you can only control one character at a time, (and I don't really feel like writing more AI then I have to) I figured the turn-based approach would work best. So I guess my next question would be: is this not the correct approach?
Riffing on the comic angle, it might actually be interesting to explore how the singular/group dynamics worked even in the non-combat scenes - why do all your party members disappear into your pocket? What do they do in there? Are they down there playing bones? Do they keep losing valuables to one another (and more importantly does this exasperating tendency affect combats)?

Of course, this could also turn into the endlessly repetitive "You pathetic descendant of monkeys!" that so easily ruined the later Wing Commander games.
No Excuses
Have you taken a look at Knights of the Old Republic?
What it essentially does is give each character a queue of actions (something also seen in "The Sims"). These queues let you set up a series of actions on one character, then jump over to another character to set their actions. You can switch characters at any point if a change of action is needed. Even better, you can fill these queues will the game is paused. How often the user pauses determines whether the game has a more turn based or real-time feel.

Another option would would be to pause and prompt the user when a party member not currently being control is waiting for an action. By specifying that this command request only happens for party member not being controlled, you effectively disable the feature when there's only one person in the party. This would play like a turn based game with real-time "scenes" between each persons turn. The player would basically play in real time until one of the party members enters their "waiting" state.

This topic is closed to new replies.

Advertisement