A broad code design question
Hi, I apologise if this is too broad or if it sounds like "how do you make a game?".
I have made several mini games, mostly not utilising OOP concepts, although I have done a few with atleast a few classes. I am now looking to undertake a bit more of a major project, specifically a turn based (hotseat) strategy game, so no AI or networking for now.
I like to thoroughly plan my code before I write it, but with a project this size I really struggle through this stage, so obviously I can't start coding it just yet.
I am looking for any pointers, tips or examples on game code structuring, it is essential that these are in c++ and contain extensive use of c++ features, they don't have to be games but it would be preferred. I have looked at source code for many games and they are usually coded only in C and generally seem to be quite a mess, this is something I want to avoid as I would like to be able to continue to work on this project and maintain it. I do have Battle for Wesnoth lined up for a download on my off-peak though.
My basic idea of the "correct" way to do it would be to have a header/source pair for each class, but that's about as far as my certainty goes. I have also been introduced to the idea of having a base game class, which contains all game elements, minus things like rendering and object creation. Is that a good way to go? Opinions? Tips? :)
Sorry for such a long, rambling post. Any help will be greatly appreciated.
I have made several mini games, mostly not utilising OOP concepts, although I have done a few with atleast a few classes. I am now looking to undertake a bit more of a major project, specifically a turn based (hotseat) strategy game, so no AI or networking for now.
I like to thoroughly plan my code before I write it, but with a project this size I really struggle through this stage, so obviously I can't start coding it just yet.
I am looking for any pointers, tips or examples on game code structuring, it is essential that these are in c++ and contain extensive use of c++ features, they don't have to be games but it would be preferred. I have looked at source code for many games and they are usually coded only in C and generally seem to be quite a mess, this is something I want to avoid as I would like to be able to continue to work on this project and maintain it. I do have Battle for Wesnoth lined up for a download on my off-peak though.
My basic idea of the "correct" way to do it would be to have a header/source pair for each class, but that's about as far as my certainty goes. I have also been introduced to the idea of having a base game class, which contains all game elements, minus things like rendering and object creation. Is that a good way to go? Opinions? Tips? :)
Sorry for such a long, rambling post. Any help will be greatly appreciated.
You're probably right! *copy/paste*
Still, it isn't entirely a game related question. Please, anyone feel free to drop me some hints if you have any.
Cheers
Still, it isn't entirely a game related question. Please, anyone feel free to drop me some hints if you have any.
Cheers
The most applications have some settings.
So to manage by it you can use Singleton class.
Also we often use some class that keep array/list/vectors, so for those classes you can use iterator.
I prefer to have my iterator class and IteratorFactory class for this goal.
Also it quit comfortable to have a compositor pattern to keep/manage by tree represented data.
So to manage by it you can use Singleton class.
Also we often use some class that keep array/list/vectors, so for those classes you can use iterator.
I prefer to have my iterator class and IteratorFactory class for this goal.
Also it quit comfortable to have a compositor pattern to keep/manage by tree represented data.
Okay, I've read your question a little more carefully.
Really? Did you just look at the formatting and a couple of functions or you actually studied the code in depth, including the relationships between the data structures and functions? To an outside observer who can just see the finished product, code will always look messy and disorganized. Only someone who understands how the code works and why it does what it does can truly see the internal logic. If someone who knew what they were doing wrote the code, it's very unlikely that it looks like it does by accident.
That's not a problem if you're maintaing your own code. Unless you remove yourself from the project for a very long time (how long will depend on how long you've been working on the project), you shouldn't have trouble remembering where everything is or why it's there.
I used to think that. I'll spare you the trouble: don't do that. Having too many files means that a) the inclusion graph is a nightmare impossible to visualize (I've tried several times to draw it for a certain project with many files and failed every time), and b) that many headers are going to be compiled several times (for that same project, I once counted how many lines were being compiled. The project is twenty something thousand lines long, and the compiler has to compile 1.5 million lines to build it, including language, system, and user headers). Instead, organize code based on its function.
Sounds to me like you have no idea what you're trying to do. This is usually a symptom of setting too vague a goal. You should start by setting very well defined design goals, only then can you start thinking how to do it. "Turn based strategy game" is too broad; Worms, Civilization, and chess all fit that description, but they're very different games.
Some questions you should ask yourself:
* Is it a clone of a popular game? (Answering this as "yes" saves a lot of design decisions, obviously)
* Do I care about portability?
* Do I need performance above all? (C/++ may not be best languages for the task. A language that's not as fast but has more safety [paritcularly memory-wise] may be better.)
* Will the game have audio?
* What type of graphics (if any at all) will it have? (2D, pseudo 3D, 3D, text)
* What are the basic gameplay components it will have?
| I have looked at source code for many games and they are usually coded only in C and generally seem to be quite a mess |
| this is something I want to avoid as I would like to be able to continue to work on this project and maintain it. |
| My basic idea of the "correct" way to do it would be to have a header/source pair for each class |
Sounds to me like you have no idea what you're trying to do. This is usually a symptom of setting too vague a goal. You should start by setting very well defined design goals, only then can you start thinking how to do it. "Turn based strategy game" is too broad; Worms, Civilization, and chess all fit that description, but they're very different games.
Some questions you should ask yourself:
* Is it a clone of a popular game? (Answering this as "yes" saves a lot of design decisions, obviously)
* Do I care about portability?
* Do I need performance above all? (C/++ may not be best languages for the task. A language that's not as fast but has more safety [paritcularly memory-wise] may be better.)
* Will the game have audio?
* What type of graphics (if any at all) will it have? (2D, pseudo 3D, 3D, text)
* What are the basic gameplay components it will have?
Last edited on
| Sounds to me like you have no idea what you're trying to do. |
I didn't include some information that didn't seem necessary to the question. I humbly apologise.
It will be a turn based strategy based on simple tile maps (think Advance Wars)
It will be somewhat simplified however, I am not trying to recreate Advance Wars, simply borrow some ideas to help me decide on design features.
The maps will be 16 by 10 tiles and I have decided on 64x64 pixel tiles to allow a certain level of detail. The window will be 1024x768 with the map in the top 1024x640 and the leftover strip for some unit data etc.
The game will be built using SFML as this is what I have the most knowledge in, SDL was the other obvious choice but SFML wins for simplicity, ease of use and the fact that I have more experience with it.
As of now, the only audio the game will include will be background music, which I will compose myself.
There will be 3 different unit types; a close combat unit, a ranged unit and a scout. There will be several different attributes to each unit, speed (how many tiles it can move in a single turn), strength, and range (minimum distance from a target to attack).
For the close combat unit to take a tile from an enemy unit, you send it to the tile the enemy unit is on, the ranged unit and scout both fire from a distance whether I will have a seperate "attack" button to use them, or just do it through telling them to "take" the tile, even though they won't physically do it.
Close combat will be slow, but strong.
Ranged will be faster, less strength but maximum attack range.
Scout will be the fastest, but not very strong or with very good range.
Portability would be nice, but it isn't my biggest concern, although it should be relatively simple to achieve using SFML. As this probably won't be the greatest thing ever created, I probably won't bother though. I am making it on windows, for windows.
It will be programmed in C++, it's an industry standard and it's what I wish to learn. I have tried several other languages but C++ seems the most suited. This game is going to be an educational experience, it should help further my knowledge of C++.
This is getting to be a rather long and messy explanation for a forum post of the top of my head (yes, I do have this written down somewhere as well).
All control will be through the mouse and I will possibly add keyboard shortcuts later.
Does this sound like an acceptable idea of what i want to do? Too broad? Please, any suggestions are welcome. (this isn't in an aggressive tone)
| Really? Did you just look at the formatting and a couple of functions or you actually studied the code in depth, including the relationships between the data structures and functions? |
Perhaps I haven't studied many as closely as I should, part of the reason being in C, part of the reason that they rarelly have a project file, and I've been brought up in Windows, where things like that are generally expected. However I still stand by my saying that ones I have looked at get quite messy. I would blame it on the idea of having many different contributers over a long period of time but I'm sure commercial projects with just one or two close-knit programmers would have similar issues (they would know what is going on, why would they care if others can't read it) Also the main reason I ask for examples is to see classes and other OOP concepts at work in a real game.
| That's not a problem if you're maintaing your own code. |
While that is certainly true to some extent, I don't know how long I may be away from my project at any given time. I have essentially taught myself programming, I used to have small projects that I couldn't recognise after a few days away. That's not so much an issue now, as I have developed better habits. But I feel if the size of the project goes up, so will the difficulty in keeping track of everything; this is why I feel the need to gather more information before proceeding.
| don't do that. |
Fair enough. Excellent advice. I imagine I will have a pair for my factory stuff, one for graphics and one for game stuff. Perhaps a few more for obvious things that I've missed, but I'm tired.
Anyway, I just used over 4000 characters writing an answer to someone who answered my question...
Cheers!
Topic archived. No new replies allowed.