2
\$\begingroup\$

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?

\$\endgroup\$
  • 1
    \$\begingroup\$ Though I dont understand much what is your goal, I am pretty sure Runnable will cause much more problems than solve - from your description you are not using it because you need threads but rather for saving objects state in thread's context. All the synchronization and mess for something that can be done by bool flag/enum just as good doesn't seem to be a good trade-off. \$\endgroup\$ – wondra Nov 26 '15 at 20:08
  • 1
    \$\begingroup\$ This sounds more like an AI problem, deciding when to block, which unit to defend against, these are the rules you have to make up. You could add a series of behaviours to your units, in a given engagement, check those behaviours, if one fits go with it. \$\endgroup\$ – ElDuderino Nov 26 '15 at 20:25
  • 1
    \$\begingroup\$ @wondra So, basically, ditch the thread - loop FTW? \$\endgroup\$ – Stefan Stanković Nov 26 '15 at 20:31
  • \$\begingroup\$ @ElDuderino Sure, I got the decision criteria ready, I'm just unsure how to implement the engagements. It seems like I'll resolve to simple real-time-like loop in the end. :D \$\endgroup\$ – Stefan Stanković Nov 26 '15 at 20:34
  • \$\begingroup\$ I see, sorry, I did misread the class name - thought you had one thread for each entity. Dedicated thread for AI is fine. \$\endgroup\$ – wondra Nov 26 '15 at 20:40
3
\$\begingroup\$

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.

\$\endgroup\$
2
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ I am already sketching up a decision tree, and assigning priorities to criteria. The good point is that basic units don't think much - they expect their local and global leadership units to process higher level of tacitcs/strategy, so I can build AI bottom-up. \$\endgroup\$ – Stefan Stanković Nov 27 '15 at 16:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.