From: Athens of Finland
Just a few points... I'd be more than happy to contribute to a project like this too, although I couldn't guarantee that I'd be able to give it much time.
About implementation technology: I'd suggest Java. Why? 1) Its independent of platform and because the wargamer community is small enough as it is setting up additional limits by the choice of a technology would be unnnecessary. 2) With the new 1.4 version you can (I'm told) do fast fullscreen graphics, too. 3) There are relatively good, free tools. 4) Its not that slow, and besides speed is not really all that essential in a game like that. 5) It offers a nice, clean object oriented development platform (objects would be a natural choice for something like this project, IMO) and it also offers relatively good debugging facilities. 6) The JDK contains (again, I'm told) a system for loading classes from .class files dynamically and instantiating objects from them. This offers a natural extension method, if properly designed.
However I'd like to point out that the implementation technology is not an issue at this point. I'd like to see at least an outline of the game rules (preferably playtested on some sort of makeshift tabletop-environment) and a list of other requirements set for the engine even before I start to think about the general architechture, let alone write a single line of code. In a project of this size it is absolutely necessary to use some sort of software engineering method, even if its not all that fancy.
Originally posted by davewolf:
a lot of very good replies.
This is the way it could work:
1. A maximum of maybe a few thousand units per side. (Units means the lowest-level units.) The way you call the units depend on the scenario design.
2. A maximum of maybe up to 10 hierarchical levels. (I mean the command structure. In a division-level game there would be divisions, corps, armies, army groups, whole fronts, high command for example, that would be 6 levels.) The way you do this depend on the scenario design too.
There must be any limits. Not just because resource management. A totally unlimited game would probably too difficult to make.
3. The best thing would be if you could give orders at each level but that's a bit too much.
4. Full aerial and naval implementation.
These 4 points would mean that you could design every scenario of human history. (No sci-fi because no space combat.)
Of course Mogami and Jonas are right you have to do this step by step. These are only the goals for final victory.
But Loki is right too. If you look at the WIR formulas you can see that they are just damn formulas, anything else. To keep the things balanced will be hard. Don't forget your still working on the WIR balance after how many years of playing? But to programme these formulas/rules isn't that difficult.
5. Simultanous movement. What I personally like much is Europa Universalis. It's a real-time game but you can pause and give orders as slowly as you like to. Nevertheless that's one thing that would be very hard to design really good I think. But if it won't work we still would be able to return to a turn-based game. So the risk would be limited.
Very important: programming language, tools and so on.
I would like to suggest VisualBasic as programming language. Don't blame on me now! There are some reasons why I think so:
a. Basic is one of the most simple languages. Even some of those who aren't real programmers should be able to 'read' most of the source code and could suggest modifications or discover bugs. No other common programming language is that simple. Blame on Microsoft - I don't like them too. - but it is simple.
b. There are free VisualBasic editions available for learning purposes. Everyone could use them. Info here: http://msdn.microsoft.com/vbasic/downloads/tools/cce/default.asp
c. Compiled basic is fast enough for such a game. We don't speak of a 3d-real-time-air/land-combat-simulation, do we?
d. c, Java and so on are much harder too learn. I suggest to do it as simple as possible on the first step and focus on game design. On the next step it could be converted to Java or whatever and made portable.
But these are just some thougts. They depend on how many programmers we would have, especially C-, or Java-programmers. If there are enough, fine. Then we could do it that way.
On of those programmers would be me. It's not that I need to do this. If enough other ones would do this work I'd watch and enjoy. But someone has to do the job.
Tools? If you think of map editors and so on then I believe we have to develop them ourselves. If someone finds one we could use properly this would of course be much better.
So step-by-step I wrote. First there should be a map where units can be moved. Then, what happens when they meet: combat. And so on. The first step will be enough work but would be seperated into many much smaller tasks.
I hope I didn't forget to answer to any question but this should be enough this time.
Anyway much thanks for each reply.
"Bingeley bingeley beep!"
- Terry Pratchett, Feet of Clay