Jump to content

  • Log In with Google      Sign In   
  • Create Account

Deceptively complex problem...


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
5 replies to this topic

#1 Plethora   Members   -  Reputation: 679

Like
0Likes
Like

Posted 17 April 2013 - 09:21 AM

I'm working on an SRPG with a tactical map and a turn based battle system.  However, rather than having each "side" get a turn during which they move all their units, I'm going with an initiative based system where each unit on the battlefield gets an individual turn based on an individual initiative score.  Each unit gets an initiative score from 1-10 with 10 being the fastest unit.  That score is subtracted from 20 with the result being n.  The unit the gets a turn every nth round.

 

I just started implementing code to determine (and eventually display) the turn order.  I had planned to keep a container of references which would be sorted and could simply be iterated over as turns were taken.  The front end of this is fine.  For a unit with a score of 8 you insert a reference every 12th round.  But obviously I'm not going to keep references all the way out to infinity.  I'm going to have to store the turn order to some point, say 50 rounds from current, and as turns are take I'm going to have to go back in and extend it further.  How to I, then, accurately track the "remainders" between a units last turn and next when they go over the "line", so to speak.  If a unit is going to have a turn every 15 rounds, and I'm keeping track up to 50, then where do I store those 10 rounds between 45 and 60 that will be left off?  I could have each unit maintain a "remainder" variable, but that seems potentially messy...

 

Thus, I'm starting to think that's not the best implementation.  My next thought was just have each unit maintain a list of when it will take its next N turns, then iterate over the units and store the order.  This seems like it would work quite well, except that I predict I'll have to do a lot of extra searching and sorting this way.  Of course, I probably won't do enough searching and sorting to impact performance even in the worst case...

 

I think in typing this I've convinced myself of implementation number two... but I think I'm going to post this anyway, as I would love to hear some different thoughts if anyone has any.  This just seemed like such a trivial problem but I've extended quite a bit of thought energy on it...


I'm working on a game!  It's called "Spellbook Tactics".  I'd love it if you checked it out, offered some feedback, etc.  I am very excited about my progress thus far and confident about future progress as well!

 

http://infinityelephant.wordpress.com


Sponsor:

#2 Brother Bob   Moderators   -  Reputation: 8202

Like
2Likes
Like

Posted 17 April 2013 - 09:39 AM

Why do you need to keep track of the turn order for multiple turns ahead? If the initiative of a unit doesn't change dynamically, then the turn order to infinity is perfectly predictable given a unit's next move. However, if the initiative change dynamically (for example; special item to boost initiative by X for Y rounds), then it would be a bad idea to store multiple moves ahead to begin with.

 

My initial idea: Store all units and their next move in a priority queue sorted by the time for the next move. Items will be popped in order of the time of next move. When you pop a unit from the queue at time T, put it back into the priority queue again with time T+20-initiative. You can find out the complete sequence of times to move a unit by adding multiples of 20-initiative to the unit's time.



#3 Plethora   Members   -  Reputation: 679

Like
0Likes
Like

Posted 17 April 2013 - 10:19 AM

Well, I'd like the player to be able to see the turn order for some period of time into the future, and the specifics of my implementation mean there will be situations where one unit may get multiple turns before another unit gets one (which is by design), so there would need to be two entries shown for unit A before one for unit B.  Though, I think a priority queue of sorts would likely work but I'll have to play with the details a little bit.

 

I don't really need to extend things out that far, but I think its reasonable for a player to want to see at least when any given unit will get their turn next.  I do intend to allow dynamic changes as well (though clearly I'm not at that stage yet), but I feel like it would just be a matter of recalculating the list with a new value.


I'm working on a game!  It's called "Spellbook Tactics".  I'd love it if you checked it out, offered some feedback, etc.  I am very excited about my progress thus far and confident about future progress as well!

 

http://infinityelephant.wordpress.com


#4 Brother Bob   Moderators   -  Reputation: 8202

Like
3Likes
Like

Posted 17 April 2013 - 10:24 AM

Keep two lists, one for turn order as played by the game, and one for the turn order as displayed to the user. The displayed turn order can be calculated to any length given the game turn order, and can be recalculated at any time an initiative changes.



#5 Plethora   Members   -  Reputation: 679

Like
0Likes
Like

Posted 17 April 2013 - 10:41 AM

That should work I think, I'll work on it.

 

Thanks for the help!  :)


I'm working on a game!  It's called "Spellbook Tactics".  I'd love it if you checked it out, offered some feedback, etc.  I am very excited about my progress thus far and confident about future progress as well!

 

http://infinityelephant.wordpress.com


#6 SamLowry   Members   -  Reputation: 1642

Like
0Likes
Like

Posted 18 April 2013 - 03:16 AM

You could also actually keep an infinite list, and use laziness. In Haskell, the solution would be quite simple:

 

generate :: a -> Int -> [[a]]
-----------------------------
generate x n = concat $ repeat $ replicate (n - 1) [] ++ [[x]]


combine :: [[a]] -> [[a]] -> [[a]]
----------------------------------
combine xs ys = map (uncurry (++)) (zip xs ys)


a = generate "a" 5      - "a" is repeated every 5th turn
b = generate "b" 3      - "b" is repeated every 3rd turn
c = generate "c" 7      - ...

result = a `combine` b `combine` c
--> [[],[],["b"],[],["a"],["b"],["c"],[],["b"],["a"],[],["b"],[],["c"],["a","b"],[],[],["b"],[],["a"], ...]

 

 

Depending on the language you use, it can be easy to simulate this, or it can boil down to solving the same problem you are tackling now.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS