Battle Engine

Here we go. No need to have separate topics for this right now. Just post everything in here.

The engine is set up for real-time combat ala "Tales of" or similar.
The difference between real-time, wait, and turn based is actually very simple: Battle Actions. In addition, a real-time game loop always allows non-blocking script updates and allows scripts to do pretty much whatever they want. Although we will be focusing on turn-based first.

How it works:
--c++ engine side
----Manage entities, updates, rendering, scripts.
----Keep a queue of Battle Actions to be used by scripts.
----Handle all the heavy implementations that 99% of the time scripts wouldn't even want to deal with to keep it simple and running fast.

--Script side
----Allow access to all game data.
----Keep track of animation states, and self states.
----Add each combatants actions to the BattleActionQueue as they are input. (since UI is under construction this could be just auto-attack for now)
----Generate enemy actions with AI. (again, probably auto-attack)
----Run combat simulation
------Combatants take an action only when they have an action pending, then are responsible for removing it from the queue when they are done.
------Repeat.


I have undoubtedly forgot to include something, and am in the process getting script bindings together...
This should be fun!

@Imzogelmo : How are the damage formulas coming along?

Clearly the C++ side will have to control the battle loop.

Various games have used different methods of organization within that loop, though. I suppose that's where some of scripts have to take their cues.

FF1, for instance, has all characters to input their commands, from first to last. They cannot be skipped, but anything can still be cancelled and changed until the last character's command is confirmed.Then all combatants (characters and monsters) execute in order of some initiative value.

FF6 has speed stats for each combatant (subject to modifiers) and those are used to fill an ATB gauge. When the gauge is full, the command selection menu comes up (characters only, monsters just go to the next line in their attack script). Each command has a specified 'wait time,' (and it only depends on the command, not the character) so at a specified tick in the future the command will execute. And of course when the time comes, it executes and the ATB gauge resets. Characters in the ready-to-take-command state can also be skipped, forward or backward through the queue, if that is desired.

Conflicts for scheduling are handled behind the scenes (although I suspect it just occupies the next non-conflicting battle 'tick').

Another thing to note is the actual attacks have to be very fault-tolerant. The attacker may now be immobilized, or the intended target may no longer be valid, forcing the engine to re-target according to some criteria. Statuses may now be applied which alter the targeting (confusion), hit percentage (blind), etc. So there have to be specified hooks for these types of conditions, and checking at input time is not always sufficient (as intervening attacks may have changed the battle).


Hit determination and actual damage scripts are going to need access to few things: attacker attributes, target attributes, and spell/attack attributes.


Question: What kinds of math routines will we have at our disposal? I'd suggest we have a sort of standard set for clamping, lerping, etc.

Yep. BattleActions have a delay that is decremented each tick. If "!action.IsReady()" then it cannot be set as the current action. The idea is that if a combatant is unable to act, then he/she is responsible for removing any actions. (or some script)

Bad targets will just have to be tested I guess. I don't have code for that yet.

Yes, there is a shit ton of overloaded math routines. Screw rpg maker, we got much better stuff! :)
-all standard c-lib math
-vector, bounds, simple collisions, matrix math
-random, clamp, min, max, lerp, spline, ex; "r = rand( lerp(a, b), vec2().dot )" etc..

Look in script/api for scripting documentation. It's the best I got right now.

I added a new script directory with various crap. All modified stats are handled now so if you look in combatant script file that should be everything needed for all attributes. (The underlying implementation may change but as long as you reference by .atk .hp etc nothing will break.)
I'm currently in the process of adding character battle sprites, loading. If you noticed all the assets are in the repo now. :)


Gotta go, my coffee is ready!

As for formulas,

Hit determination (for spells) is probably one we want to make in the spell class (with option to override in a few select instances).
Damage is probably best handled on a spell-by-spell basis (some things may not even cause damage).

Okay, it's almost there!

The holdup was I needed to load all the data from the xml files, finish some code to instantiate game objects, add scripting for it, manage all this crap, and be able to initialize combat entities from it, to name a few.

How it works:
Verbage: Well call Map-type entities "Players", "Npc's", and "Enemies", and Battle types "Monsters" and "Characters" for now.
-Battle Combatants (Monsters and Characters) derive from "IGameEntity" which magically makes script classes inherit from a c++ class. From here you can theoretically do anything you want and can clone QBert using the battle engine if that's what gets you, but for now we'll go into the standard RPG stuff. :P

I basically chose a "every entity can do whatever it wants" approach instead of the more 1990-2000 "everything is handled by one big battle engine" approach. I'm about 98.17% sure this is not how early FF (or SNES) RPGs did it, but a more modern approach is way more flexible and powerful. The downside is things may be more tricky initially since "do whatever you want" is not always what you want. ..Make sense?

[// todo: write battle logic design here... have fun! //] :P

Side note on animations:
spriteset.state = WALKING; //states is an array of animations
spriteset[CASTING].frame = 0;
there are no flags available to scripts yet (flip etc.)

Side note on functions, declarations: I try to make everything as easy to use as possible despite their complexity, but because of the sheer amount of things that need work on there may be things left out, incorrect, horribly named, etc, so if you have any suggestions for anything don't hesitate!

Also the projection is set at 256x224. Should it be something else?

Thoughts?

[edit] HAVE BATTLE LOOP AND SCRIPT COMPILES! ...I'll finish the rest tomorrow.. it needs sleep now.
..Also needs targeting data still...

Gleeok, are you using Microsoft Visual C++ by any chance? If you are, try loading it in Visual C#, because if it works, you can install XNA Game Studio, which will allow you to easily load in the graphics and sound files.

Quote:

---

Originally Posted by Anarchy_Balsac

Gleeok, are you using Microsoft Visual C++ by any chance? If you are, try loading it in Visual C#, because if it works, you can install XNA Game Studio, which will allow you to easily load in the graphics and sound files.

---

I've got XNA 3.1 but the code is written in c++ which may be a problem for .NET. ;) The script language is angelscript which is very c# and java-like though.

For 2D games the game engine I'm using can already do everything that XNA can do (except faster, compiled, and cross-platform) so I'm not worried about low level stuff at this point. In fact, some of the core classes were actually modeled after XNA classes when I originally moved an old shmup game away from .Net to OpenGL and c++, so there are a lot of similarities.

Quote:

---

Originally Posted by Gleeok

I've got XNA 3.1 but the code is written in c++ which may be a problem for .NET. ;) The script language is angelscript which is very c# and java-like though.

For 2D games the game engine I'm using can already do everything that XNA can do (except faster, compiled, and cross-platform) so I'm not worried about low level stuff at this point. In fact, some of the core classes were actually modeled after XNA classes when I originally moved an old shmup game away from .Net to OpenGL and c++, so there are a lot of similarities.

---

Nice, but does it also use the side window that allows you to load in graphics and sound via the mouse? Cus that's my favorite part of using XNA.

Well, I sort of rebooted this stuff heh. I wish I could of just had the time to be continuous with development instead of it basically sitting for a year. Oh well; that's life I guess.

In the final phases of fixing up the battle queue logic so it can handle true ATB events. If I have this right (I think I do) then we have two properties of an Action: wait time, and cool-down time. Aside from that there is two more properties: battle speed, and delta—where delta represents the speed modifier of the parent (or anything I suppose), like haste or "instant action" for example. Question: Would battle speed modify the wait values for them, or is it used only for pre-actions such as the battle guage?

Aside from that, also getting (script) CombatActions together now. Once the foundation for that is laid out then the scripts for Actions, Combatants, and Battle classes will pretty much all be worked on side by side. That's all I managed to get done today. blarg. My only concern is that if I get preoccupied with other matters it might go unfinished yet again... :\