RTS combat system

Question

I am developing a small-scale TB/RT Strategy hybrid, not unlike the Total War series. It's in the classic medieval setting, with only melee infantry combat currently implemented for testing. Units are fighting in small squads, but the egagements are individual (for example: 1v1, 1v2, 1v4 etc, but not 2v2, 2v3, 3v5, etc) and are taking place on whats usually considered an RPG level of detail (stats, items, scripts...).

The current rules use Java, with class Engagement implements Runnable and its run() method simply alternating the attack phases of two units until one of them is incapacitated. That was usefull for ATT/DEF equation balancing, but I'm not sure how to model the following:

• unit's attack, block, parry/conterattack phases during the engagement (deciding when to block, for additional DEF - one simple loop or a separate thread?)
• multiple units engaging one unit (for, say, caster/leadership takedown), where the outnumbered unit has to choose which attacker to repel/conterattack (loop or a check within aforementioned decision thread?)

Is real-time usually modelled as just a really quick loop, or a thread with interrupt and sleep/wait/join?

If needed, I can add the relevant code, but I think of this as a purely design, flow-modelling problem; simply put: What are the classes/interfaces (and their traits) I should rely on while resolving this problem?

Answer 1

Is real-time usually modelled as just a really quick loop, or a thread with interrupt and sleep / wait / join?

Good that you edited to add this since I cast my eye over this 10 hours ago, because this is at the core of your question. Since we're otherwise unaware of your requirements, it isn't immediately clear whether you suggested threading for any pressing purpose.

The answer should always be a really quick loop until you get to the point where that can no longer do the job. There is always a price paid in complexity and opacity when using threads.

To make steady progress and properly understand how things should work when threaded, set it up to run on a single thread first, then, if required after standard optimisations, go multi-threaded. This was how I got started with threading in Java; if I hadn't, it would have taken probably double the time to get things right given complexity of the base functionality (dynamic mesh construction) running in a single thread. For AI, similarly - don't complicate things more than necessary right now.

YAGNI - you ain't gonna need it.

Answer 2

Real Time

In addition to Arcane Engineer's answer. Real Time refers to the users experience, less than the actual state of code.

Turn based games wait for player input. Real time games constantly continue, regardless of if the player is acting or not.

How you implement it isn't important, so long as it forces the player to respond actively to game events.

That being said, avoid threads until you need them.

Unit Engagement

The other part of your question centers around unit engagement. Essentially what you need here is AI. A quick way to start is to define the behavior you want from your units in a given situation. "Unit A is outnumbered 2 to 1, it should do this."

You may consider a system that can read the state of an engagement and tell the individual actors what they should do. It can also determine the order of actions, which may become an issue as the order of actions can vastly change the outcome of an engagement.