next »

[tergem]

Alright, I'm making my first real game in awhile. Feel free to also use this thread about Strategy game design in general.

The game is a strategy game that is best described as a mix between Civilization and Diplomacy. It is within my skill level but will take a couple months to get to something which I'll be happy to put up onto the DevLogs.

The question: Should I have tiles (like Civ) or Splotches of Land (Like Diplomacy/Risk)?

Some things that are decided (some programmed in already, well as far as I can without making the design choice I'm asking you to make). These ones that are listed are to help you make your decision, I have more already ready (Units, buildings)
1.) Like Diplomacy there will be Simultaneous turns. I like this because it adds a layer to the strategic thought required in the game.
2.)Like Civilization there will be Cities where you can build things. Unlike Civ you can't create new cities, what's there in the beginning is there to the end.
3.) Like Diplomacy there will be a limit on how many units you can have. (By industry, London>Cardiff)
4.) Like both there will be communication between Allies.
5.) Like Civilization there certain areas will yield natural resources (oil to power vehicles is an example)
6.) Like Diplomacy there will be supporting of units, helping them hold something or take something (in a simpler way than Diplomacy however).
7.) Like Civ different units will have different Defense/Attack stats.
8.) There will be water, this may change your mind or it may not
9.) No randomization, pre-made maps based on real wars.

If you would like to play either game to get a better idea (both free):

WebDiplomacy.
FreeCiv, not as good but should give you the idea.

[synapse]

Very cool idea - both games are revolutionary and extremely fun.
3) What dictates the total number of units?
6) Can you get more specific?  Diplomacy's system was deep but not really that complex (especially for a computerized version).
7) Again, can you get more specific? Diplomacy had deep strategy but was very simple.  What is your reasoning for adding defense/attack?  What exactly separates attack vs. defense in a simultaneous-turn system?

Also:
What platform will the game be developed on?  This is a huge question that not that many devs seem to take into account early enough in the development process.

[tergem]

^3.) Either the total amount of industry in the city (because I put the cities there, either by hard coding now or by a map editor that is waiting for your input as to the type of map), or by population, either is good. But Industry reflects the actual building of things (which reflects that you use resources), and population shows how many people you have to pool out of. Not sure which one is a superior form of military capability, I could add both but then I'm afraid of making it too complicated for everyone (including myself).

6.) The support is extremely simplified, if you make a unit support another it just adds its support value to its attack value and defense value. So if an infantryman with a support of 2 supports a tank, then the support of two gets added to the tank (initially, say, A;4, D:3| I think that's a bit overpowered) it will become A:6, D:5. The tank then carries on to whatever it was doing, attacking or defending. There are a few flaws with this, but this is the closest I can get without being sued methinks. If you have a better  suggestion feel free to bring it up.

7.) The reason was when I realized artillery is a whole lot less useful at defending itself than attacking, and more useful as a supporting unit. The attack is only when it moves, the defense is only when it holds. If two units go into each other, then they were both attacking and the strongest attacker wins. Really it is extremely simple, but I will have to add something in the tutorial that makes this clear.

Did this answer your questions?

Edit: Forgot the Platform! PC .EXE (gah, not online! How could you?) freeware until it becomes close to a masterpiece (which I doubt), if it does get to masterpiece then I don't know if I should go for the money, or stay freeware. Of course as I'm working in C# I could port to XNA then to the 360, making some money there. But I significantly doubt that the 360 has many strategy lovers.

[synapse]

It all sounds good except the platform   Make it a web game and you'll probably get several orders of magnitude more users.  You might even make money from it

[tergem]

Yeah the platform is an issue, I might want to port it to Java (or learn flash, a preferred option|Actually there is Silverlight, might give that a shot). However it might be nice to make it in what I know will work right now.

However my question isn't answered: Do I go with tiles or splotches of land?

[synapse]

Think of it from a user's perspective.  It's a lot more compelling if it's variously-shaped territories rather than just tiles.  Just represent it in the back-end as a general graph.

I vote against Silverlight and Java and push towards Flash.  It's a got a lot more reach, and people hate installing new plugins.  If you are really forward thinking, you could also try HTML5.

[Derakon]

Tiles are more amenable to algorithmic analysis of the board; Risk-style splotches create more variety. It's much harder to make a natural-looking map with chokepoints, territories with many borders, etc. if you're working strictly within tiles than if you work with irregular blotches. However if you want to have things like elevation, terrain effects (jungle, desert, etc.) then blotches become unwieldy because they tend to only work reasonably at very large scales.

[brog]

Tiles are more amenable to algorithmic analysis of the board

Not necessarily true - blotches can just be stored internally as a graph, and most of the algorithms you want to do (like pathfinding) work just as well on a general graph; they don't care about the tile structure.

Use tiles if you want a large map with lots of different places to be.  It's easy to deal with irregular splotches if there are just a small number, but difficult if you have dozens.  A grid of tiles scales better. (edit: I mean here easy for the player)

Use yotches if you have a smallish number of places at a broad scale (countries, provinces).

Use tiles if you want abilities of a geometric nature - zap multiple tiles in a line, blast a circle of radius R.  With smotches you can do a circle of radius 1 and that's about it (i.e. one crotch and all the hotches adjacent to it).

[tergem]

Think of it from a user's perspective.  It's a lot more compelling if it's variously-shaped territories rather than just tiles.  Just represent it in the back-end as a general graph.

+

Tiles are more amenable to algorithmic analysis of the board; Risk-style splotches create more variety. It's much harder to make a natural-looking map with chokepoints, territories with many borders, etc. if you're working strictly within tiles than if you work with irregular blotches. However if you want to have things like elevation, terrain effects (jungle, desert, etc.) then blotches become unwieldy because they tend to only work reasonably at very large scales.

This leads me to want to put in more Risk style blotches, the only terrain will be land and water (to keep things simple for an moderately skilled programmer). I want historical looking maps, representing historical events (or later on in map creation hypothetical ones) in real places. So the blotches sounds best!

Tiles are more amenable to algorithmic analysis of the board

Not necessarily true - blotches can just be stored internally as a graph, and most of the algorithms you want to do (like pathfinding) work just as well on a general graph; they don't care about the tile structure.

Use tiles if you want a large map with lots of different places to be.  It's easy to deal with irregular splotches if there are just a small number, but difficult if you have dozens.  A grid of tiles scales better. (edit: I mean here easy for the player)

Use yotches if you have a smallish number of places at a broad scale (countries, provinces).

Use tiles if you want abilities of a geometric nature - zap multiple tiles in a line, blast a circle of radius R.  With smotches you can do a circle of radius 1 and that's about it (i.e. one crotch and all the hotches adjacent to it).

First what is with your changing variations of the word blotch? (Yotch, Sotch...). Grids of tiles do scale better and are easier to make pathfinding for, but I only heard of connecting blotches by lists of which one can go where (because of their irregular shape). I want to make things simple, no Radius or anything like that. The most complicated would most likely be missiles; which would be able to support anywhere, but only once.

I have the drawing of what my first map would look like as blotches, so thank you guys for your help.

So blotches it is!

Further questions:
Transportation across water: Convoy (diplomacy), Carry (Civ), none at all (capture a coastal city and build land units there, this seems to be the simplest to program), or other?

Good ideas for resources? How they would be used and such? I have oil as a barrier to building vehicles, I'm open to more suggestions.

Online play, if any, what form should it be in?

Know any good recent historical conflicts, or good hypothetical ones?

[X3N]

Might help to think of what theme/setting you want then translate that into mechanics.
Looking forward to what this thread produces.

[Derakon]

Grids of tiles do scale better and are easier to make pathfinding for, but I only heard of connecting blotches by lists of which one can go where (because of their irregular shape).

Actually, brog's right and I was wrong -- blotches are pretty easy to deal with from a computer perspective, easier than tiles would be. You just need to get used to thinking of the game in terms of a (mathematical) graph of nodes and edges. Each node is a blotch on the map, each edge is a shared border between two blotches.

Want to pathfind from blotch A to blotch B? Do a breadth-first-search starting from A and continuing until you reach B. You can even adjust the route the AI is likely to take by "weighting" edges differently based on the game state and using Dijkstra's algorithm to find the best path. For example, you could increase the weight of edges that require the unit to pass through enemy terrain, decrease the weight for passing through territories that have developed rail systems, etc.

In general, graphs are amenable to elegant recursive or queue-based algorithms that should make analysis rather straightforward.

[tergem]

^That sounds good.

Thanks for the Algorithm link!

[synapse]

Do you even need pathfinding?  Don't get caught up in the excitement of a new algorithm and try to shoehorn it into the game design before establishing that it's necessary

[tergem]

No it's not needed now. However if I do want a single player experience I will need pathfinding. Besides it will have to wait until later, on the bright side I can program the Blotch class with this in mind. This might just have to become a DevLog soon, so I may want to devote more time to this project than I'm doing now.