next »

[Chombasu]

Greetings for the first time, fellow independent game developers! I'm part of a duo of programmers and several other researchers working on a grand-strategy game without any corporate support or monetary incentive (hummus & fruit shall do).

The game, currently under the working name perestroika is in its infant steps and the time has come for our miniscule team to decide on how to build the foundations for this game.

Here is the current situation: We have some alpha math codes written in Lua(!), mostly for the purpose of testing and experimenting. We plan to either translate these codes into C++ or write our own interpreter (in order to keep the format we have been working with. We have been putting equations written down on paper directly into Lua so far), although the latter is much less likely.
And our engine - this is the main element I wanted to present to the community and ask the experienced fellows here about:

We are currently at the point at which, having completed algorithms for a few of the basics, compiled a set of working test-codes (mostly based around the simulated world economy), we feel that in order to apply any code and test it properly we need an engine, as so far our disjointed programs and scripts are of little use in testing, let alone actually making a game.

We have started to write an engine in C++, and have a plan as to how it will run: The engine will be a base program which loads data from arrays and feeds it to a set of classes within the engine which in turn use the hardcoded algorithms and loading code to compile the data into each separate element of the game. For example: A tile of the game's map will have a data file, probably JSOND unless we find a better format, which will be loaded and subsequently presented to the player in the UI and run through each of the "scripts" (I call them scripts, but they will be either part of the engine and probably, during this very early testing period, individual programs) in order to generate the dynamic world which is to be played in. The point of this is to achieve a minimal amount of hardcoding: all of the attributes of the game are loaded by a barebones engine which we are currently writing in C++ which basically feeds the data to our algorithms.

I can procure any of what we currently have upon request if the explanation has been unclear. The engine is currently capable of checking a data file and recognising the attribution of a text label to a certain country, and loading a certain image according to that country's ID (here we have, basically, a rudimentary flag loading program). It is being built on gradually.

There is a tool that we are considering using for at least some parts of the game's core functions: SDL. We might use this to take care of input & rendering (although our rendering is currently fairly simple, we expect to run into problems using a tilemap to render Earth made up of individually selectable tiles, resolutions at different zoom levels and graphical representations of the game's selectable elements which are yet to be created).

As for actual development of the game's data files, we intend to make full advantage of our hardcoding-light plan and write a series of (semi) user-friendly editors for each type of data file or class which will be fed to the core game program - the intention of this is to, on the one hand, make the game easy for us to edit during testing phases, as we should simply be able to open up the files for the elements of our game (say, a country) and edit them using forms. On the other hand it will be very useful, we imagine, for future patches on our game, expansions, mods and all that malarkey.

So, community, what I want to ask you is this: Is the aforementioned plan seaworthy, is it plainly stupid, or is it perhaps somewhere inbetween? My experience with programming so far in my life has been almost entirely mathematical, with the small exception of a few text-based games, while my partner has a little more experience with engines for basic platformers and C libraries.

I, as well as my partner, will stick around to converse with anybody who's willing to give advice, as well as answer any questions concerning anything that I have omitted or been unclear about.

[BWG]

Interfacing with Lua from C++ is pretty easy. Use SDL for the graphics/interface, and call some Lua scripts from your code. There are plenty of tutorials out there for that. So you dont need to rewrite your game logic and core simulation algorithms in C++.
As for the tools, use whatever language you are comfortable with, or even just write a parser and create the data in a text editor.
The biggest advice I can give, is to say "finish the game". Writing custom engines and tools is great fun and a good learning experience, but ultimate goal is a game, so get it done by any means neccessary.

[Klaim]

The game, currently under the working name perestroika is in its infant steps and the time has come for our miniscule team to decide on how to build the foundations for this game.

Side note: I think you can't use this name http://en.wikipedia.org/wiki/Perestroika_(video_game)

[kamac]

Interfacing with Lua from C++ is pretty easy

I agree, and I must say that it is very fun to do that!

Here is the tutorial I've used:
http://elysianshadows.com/phpBB3/viewtopic.php?f=6&p=55901

It's incredible how easy it is to add your own functions 

Use SDL for the graphics/interface, and call some Lua scripts from your code

Yup. SDL will do. You can have a look at SFML or Allegro if it doesn't fit you.

So, community, what I want to ask you is this: Is the aforementioned plan seaworthy, is it plainly stupid, or is it perhaps somewhere inbetween? My experience with programming so far in my life has been almost entirely mathematical, with the small exception of a few text-based games, while my partner has a little more experience with engines for basic platformers and C libraries.

It's a good idea to make a 2D game when you are a beginner. You're lucky that your friend has some knowledge already. Make sure to keep asking him for help when you don't know something. But you've got to remember this: When you make a strategy game, things are most likely to get complicated when you want to do AI (Which, in strategy games, is hard).

Good luck anyways

[Chombasu]

Thanks for the advice, chaps! Looks like we might continue to write our algorithms in Lua if what has been mentioned is the case. I am concerned, though, that having any intermediate points between the mathematic code and the C++ code will slow the game down. Current projections for turn loading times are not particularly short, and we want to cut down processing time as much as possible. Will interfacing Lua with C++ slow our game down?

As for A.I. - We are writing every part of our game with A.I. in mind, allowing for it by adding discreet values, easy reference tags (so that in the A.I. code we can easily call up any of the game math processes that we want). We're also in the process of sketching up algorithms & flowcharts so that we can visualise the A.I's workings- all we need to do when it comes to it is transfer our drafts into code and make sure it's not buggy.

However, we only really want to start any work on the A.I. once we have a working game: say, a world with inactive countries but still able to generate, render and calculate the parameters of all the features such as economies, armies, politicians et ceteri.

Side note: I think you can't use this name http://en.wikipedia.org/wiki/Perestroika_(video_game)

Ah - it's only a working name, anyway. Any idea of a brand is utterly pointless at this stage, it's just nice to have something with a name.
Anyways, I would have thought the reds would be against any sort of bourgeois copyright nonsense. Maybe we'll have the F.S.B. after us...

[BWG]

Calling Lua functions to perform tasks is certainly a lot slower than doing the equivalent directly in C++, but I really wouldn't worry about it at the moment for 2 reasons:

1) Computers are very fast and getting faster all the time.
2) If does turn out to be a real problem, you can first optimise and redesign.

There is really no point in worry about something that probably wont ever be a problem. Just get it all programmed, and worry about real problems as they come up.
Now, I'm not saying you shouldn't plan ahead, but this is a learning experience for you, and you learn most by doing. So just get it done already!