I am considering making a turn based strategy game. You get a group of units and fight against other live players. It is going to be turn based, but I am not sure how I should do that.
The first way is that you have player 1 move all their units, do all their attacking, etc. Then player 2 goes, and all the other players go until you're back to player 1. The problem is in a game with lots of players, that could be a very long and boring process.
My other idea is to have every player take their turns at the same time. Once every player is done, it goes on to the next turn. This way the player that goes first has no advantage, and the players don't spend as much time waiting.
What do you think about these methods? Which do you think would work better? Do you have any ideas that you think would work better?
ID:153803
 Jan 5 2003, 8:23 am
|
|
|
Jan 5 2003, 10:35 am
|
|
Garthor
 |
Every player should take their moves at the same time, only nothing is actually done until the end of the turn, when all the units move. In all fairness, if you assign a unit to attack, that unit will follow the enemy, instead of making you make a blind guess as to where they would be going (which is a problem with same-turn games).
|
Hehe, good thing you mentioned that. I created a turn based demo which takes turns with movement. Although htere is a slight problem with lock up, but i'm sure you can fix it.
| |
OneFishDown wrote:
I am considering making a turn based strategy game. You get a group of units and fight against other live players. It is going to be turn based, but I am not sure how I should do that. Civ3: Play the World experiments with all the approaches you mention, none of which is perfect in all cases. I'd recommend that you implement the simplest approach (which is probably one-turn-at-a-time), while working to keep the architecture flexible. Then add in the other approaches as options once you have the simplest working and debugged. | |
Simultaneous movement is great if you want to simulate battlefield conditions prior to modern communications technology, but in general I do prefer turn-by-turn. One thing that definitely makes things go much quicker is to allow several turns' worth of commands to be entered to one unit--"move towards this spot every turn", "keep defending", "move up to this unit and attack", "assault this point until dead or victorious", etc.
| |
Malver and I where working on one like this before we were done the RTS. It was called nacle and was a computer version of a paper and pen game we made up. But he never got around to finishing it. Mabye ill ask after we are done with the RTS.
anyways, i'm into TBS's to. My favourite one is the disciples series. Its pretty cool and offers lots of custimization. I like that. Having different troops and evolutions, you can even give equipment to your leaders. | |
Leftley wrote:
Simultaneous movement is great if you want to simulate battlefield conditions prior to modern communications technology, but in general I do prefer turn-by-turn. One thing that definitely makes things go much quicker is to allow several turns' worth of commands to be entered to one unit--"move towards this spot every turn", "keep defending", "move up to this unit and attack", "assault this point until dead or victorious", etc. I agree... if a unit can't have its commands queued, have standing orders, or have its orders repeated -- especially if it's an installation or some other structure that you can't be depended on to check every few seconds! -- then there's almost no point in having a strategy game. (I'd plug Terra Dominus, but I've already plugged too much; that poor leak is just a trickle.) One problem with a turn-by-turn architecture is that, while everyone gets the same number of turns, the players who come first in the turn can always outgun the latter players (they get to shoot first) and the latter players can always outmaneuver the former players (they get to move last). One thing I've been thinking about is having a random system that randomises the order of the queue every turn (and makes sure that the last player in the queue doesn't become the first player in the next turn -- two turns in a row is highly unfair). Everyone will have an equal chance to outmaneuver or outgun the enemy -- it's depending a lot on luck, but, heck, most strategy games depend on luck as much as strategy. A round-robin strategy for reordering the queue is also possible -- player 1 starts the first turn; player 2 starts the second turn and player 1 goes last in the second turn; player 3 starts the third turn, player 1 goes second-to-last and player 2 goes last, etc. | |
Spuzzum wrote:
One problem with a turn-by-turn architecture is that, while everyone gets the same number of turns, the players who come first in the turn can always outgun the latter players (they get to shoot first) and the latter players can always outmaneuver the former players (they get to move last). That's why I am considering having every player go at the same time. This way it's a matter of who can command their units the fastest, not who goes first. The problem I see with this is a bit of a stalemate, where no player wants to go first and would rather ract to another player's move. For that I suppose I could put time limits on the turns. | |
That's why I am considering having every player go at the same time. This way it's a matter of who can command their units the fastest, not who goes first. The problem I see with this is a bit of a stalemate, where no player wants to go first and would rather ract to another player's move. For that I suppose I could put time limits on the turns. Oh. Ick. I thought you meant having every player issue their orders simultaneously, waiting until they're done (and/or until a time limit runs out), and then executing every player's orders at the same time. Then instead of a matter of who goes first or who commands their units the fastest, it's a matter of who can best anticipate their enemies' movements. | |
Leftley wrote:
Oh. Ick. I thought you meant having every player issue their orders simultaneously, waiting until they're done (and/or until a time limit runs out), and then executing every player's orders at the same time. Then instead of a matter of who goes first or who commands their units the fastest, it's a matter of who can best anticipate their enemies' movements. I suppose I'll make it all these different ways, and see which I like best. Either way it looks like I'll be writing a pathfinding routine, yay! | |
OneFishDown wrote:
I suppose I'll make it all these different ways, and see which I like best. Either way it looks like I'll be writing a pathfinding routine, yay! You might want to check out Deadron.PathFinding first... This uses an industry-standard algorithm, has several years of refinement built in, and is used by multiple projects (including Thieves and a PacMan clone Mapster did...man he should put that in FanGames, it was great!) Also, while it allows a great deal of flexibility if you want to override certain functions, the standard use has been boiled down to one simple call: dd_StepTowards(). | |
Deadron wrote:
You might want to check out Deadron.PathFinding first... [snip] is used by multiple projects (including Thieves [snip]) After a few initial hiccups (heh...), it's worked great! I highly recommend it to anyone who needs a good pathfinding system. Just remember to change the last argument to dd_StepTowards to a higher number if your paths have any degree of complexity to them. :-) | |
That's why I am considering having every player go at the same time. This way it's a matter of who can command their units the fastest, not who goes first. The problem I see with this is a bit of a stalemate, where no player wants to go first and would rather ract to another player's move. For that I suppose I could put time limits on the turns. Why not have all the players give their units orders. Then when everyone has given all their units orders, have everything carry out and preform their actions based on the speed of the units. This way it's fair for everyone and you don't need a quick trigger finger. | |
I took a few hours today and wrote an "industry-standard" pathfinding routine of my own. It is very fast, and the code is 1/5 the length of yours. Also, it has never failed to find the shortest path.
Also, it has all the features I'd need for the kind of game I'm using it for. I know exactly how it works, so any modification I'd need to do would be easy. | |
OneFishDown wrote:
I took a few hours today and wrote an "industry-standard" pathfinding routine of my own. It is very fast, and the code is 1/5 the length of yours. Also, it has never failed to find the shortest path. I checked out your demo, and it looks pretty cool. Can I ask what algorithm you used? -AbyssDragon | |
OneFishDown wrote:
I took a few hours today and wrote an "industry-standard" pathfinding routine of my own. It is very fast, and the code is 1/5 the length of yours. Also, it has never failed to find the shortest path. Sounds like a breakthrough! Since you like helping people learn how to program for themselves, you oughta write a post or a BYONDscape article on how to do such a cool pathfinding library. | |