Looks like you are hard-coding your engine. That´s pretty bad idea, because creating a game this way is much more difficult to maintain. Take advantage out of object-oriented design, that is one of the key features of C++. Also use of arrays would be nice idea. Here´s an example:
See? Think levels as objects (things that exist) & also keep in mind, this isn´t even the smartest solution. An example:
1 2 3 4
struct Level{
bool is_room; // If this isn´t true, then this is room entrance.
Level(void) : is_room(true){} // Initialize variables of this struct(ure).
};
I haven´t orientated myself with these pieces of code that further, but this kind of game engine design can be quite inflexible & hard to maintain.
Please learn more about generic, modular & object-oriented programming. That´s my main recommendation. You remind me about my early, flawed game engines that were quite badly designed. Learn more & you will figure out more benefits C++ has to offer. It makes your programming easier on the long run, trust me.
http://paste.pocoo.org/show/452598/ Notes- The empty voids WILL be filled when we get to that point (Haven't worked in weeks and with school coming up even less time) - The Intro questions will be rremoved (too embarresing of a story to tell xD - Even though this version may not be completed, when I master C++ I will remake it (If it hasnt been made now)
General Coding and Naming Conventions:
Straight away, I noticed uninitialized objects. It's imperative that you initialize any object prior to its use. Your naming convention proves difficult to read. The identifiers aren't distinctive enough to determine their use.
Flexibility and Maintainability:
This design is far from flexible. in fact, this code is stiff as a plank. Games should be easily maintainable, especially when they grow. your code is neither flexible or maintainable.
White-Space:
There's so much of it. Since there's so much, you sometimes lose track of the line you're currently reading, just like the ConsoleColor class. The excessive use of white-space could prove problematic in the long run.
Documentation:
Your game lacks suitable documentation, which will make the code less understandable when editing it further on down the road. Documentation is vital, especially if you're working in a team. Your games
documentation level is below minimum. We don't don't even know the game's title.
Platform Compatibility:
Since you've managed to incorporate system( ) into your design, you've binded this game to the Windows operating system. Your game is not cross-platform.
Project Management:
Your project doesn't have this. Shockingly, you've crammed everything into a single source module. The lack of project management skills has cost you maintainability, especially when combined with the lack of documentation.
Overall:
I'm sorry to inform you, Logart, but this design is poor. You've defeated the purpose of OOP. In doing so, you've wasted time, space, and forfeited maintainability. The documentation levels are insufficient, the traces of documentation you did provide are less than acceptable, your ability to create cross-platform games is being called into question (personally speaking), your naming conventions are ineffective and uninformative, and you've created a game that behaves in an undefined manner when your global variables are used.
Final Rating: 3/10
Additional Foot Note: The game fails to compile in Visual C++ Express 2010 with many errors.
I understand completely, but FYI I don't understand classes yet, and I haven't got the best idea as to what Object Oriented Programmining is about. Thanks for the review! :P
Just to add on, modular, OOP, re-usable features etc posted so often in this forum is not C++ programming language specific. The same concept is applicable in other OOP like say Java for instance.
The only main difference lies in their syntax and usage but the concept is same. E.g in Java we can have interface ABC {...} syntax but we do not have that in C++ but we can simulate that easily also.