Discussion Game design

[ar81]

As you may know the last time I took a course on programming was in 1986 when I learned BASIC for Wang PC. Later I learned the basics of Visual Basic 5. To me it is like taking a "basic course of Windows" for today's standards.

The first projects, Mesh Wizard, Surface Base Wizard, and the first version of Space Orbinomics that used DGIII were my first "real world" practice. The code works, but from my view today it is just too messy, the work of an amateur. If you could see the code, you'd look like this.

When I tried to remake Space Orbinomics I realized that I was having lots of problems because the code became long and unbearable.

I had to restart the project, this time using Object Oriented Programming, but it also became unbearable. So I discovered that perhaps something was wrong in the way I am approaching design (organizing code in modules and class modules).

So I think that if a second attempt to restart the project is to be made, I better come with something that does not lead to a dead end where I need to remember lots of things. Any design tips?




I found a book that provides these tips, but I do not understand what it means:

• Avoid hidden code that performs nontrivial operations.
• Keep your class hierarchies as flat as possible.
• Be aware of the difference between inheritance and containment.
• Avoid abusing virtual functions.
• Use interface classes and factories.
• Use streams in addition to constructors to initialize objects.

It seems that a game is like a movie, where preproduction matters to reduce costs or to avoid dead ends that makes the project to be unfinished vaporware again.

Certainly I got tired of learning by making mistakes when things become too complex because of a poor design. Any tips on how to design games?

While you post here, I am coding a "mini-game" that was planned to be originally included in Space orbinomics, but I decided that it should be a separate game.

I will not tell you what it is about, but I bet you will love it. It is about 70% finished, a bit closer to a game than closer to vaporware.

Any tips on game design to speed up coding or to simplify it, would be useful and appreciated.

 

[Moach]

ooh, those are very relevant tips...

let me elaborate on them...

>> Avoid hidden code that performs nontrivial operations.

if something important is to happen at a point of your code, make sure that it is clearly visible and understandable, ideally in proportion to it's importance...
an example of what not to do is to put an all-important function call inside an "if" condition block... if a bool-returning function is REALLY important, at the very least break the statement over a few lines so it can be seen...

not just about general readability, there are other ways that code can be hidden... destructor functions are a goldmine for this kind of undesirables... you don't really call them, but they happen anyways - so check what goes into them, don't let "implicit" code get too much responsability in it's hands...


>> Keep your class hierarchies as flat as possible.

I've had this problem before, and all i can say... *facepalm*
my boss at the last place i worked used to overcode everything... to undertand what was going on you'd have to browse over tens of classes which inherited eachother and added one or two functions at a time...
reusable, maybe.... for him, at least, but for anyone other than the author, plain unreadable
so while you can, keep your inheritances to a reader-friendly minimum


>> Be aware of the difference between inheritance and containment.

the best way to think of this, is to mind that classes can have two types of relationship with other classes... an object can "have" another object, or an object can "be" another object... respectively, containment or inheritance...
think about it... a ship IS a type of vehicle, therefore, ship extends vehicle... now a ship HAS a thruster, but thruster doesn't extend ship - since a thruster by itself is not a ship nor a vehicle, a thruster is "owned" by a ship, which is also NOT a thruster...


>> Avoid abusing virtual functions.

in a way, virtual functions allow you to call a function by the name of a function that could do something else completely different... this is another way of having hidden code, and therefore, should be used with caution


>> Use interface classes and factories.

not too sure about that... i, myself have never seen the use for this type of thing... some design patterns seem to me like just overcoding in some cases...
maybe if you have something that's really intricate, it might be worth it tho...


>> Use streams in addition to constructors to initialize objects.

i'm really not sure what this is supposed to mean... can anyone clarify?

 

[MeDiCS]

One of the best tips is think. Unless you have a clear image of what you're trying to archieve, don't code. Imagine the necessary modules, and it's most important interfaces.

Even after you start coding, don't drop the planning. Also keep in mind that the design is not constant, but the rate in which it changes decrease as the codebase gets bigger.

I think coding is very personal, but one thing that helps me a lot when I see a dead end (or more commonly, feel that something is just not 'right'), is to partially or completely rewrite the module or the program. Even if you have written all types of apps in existance, every project introduces something new, which you incorporate in your design after each rewrite.

 

[cjp]

I found a book that provides these tips, but I do not understand what it means:

Then maybe they're just one step too far at this moment. Learning goes step by step, and you need to have done the previous steps in order to understand the next step.

It seems that a game is like a movie, where preproduction matters to reduce costs or to avoid dead ends that makes the project to be unfinished vaporware again.

Starting with a good design is definitely a good way to prevent getting stuck halfway the project because you made a wrong decision somewhere. On the other hand, it is my experience with programming that you often need to have done the programming before you get a good feel of the problem.

So, for a good program you need a good design, and to make a good design you need to have made the program in the first place. So it often feels to me that, for complicated software, you don't escape from making it twice. Of course, what is complicated and what is not depends on your experience level.

I will not tell you what it is about, but I bet you will love it. It is about 70% finished, a bit closer to a game than closer to vaporware.

If you told what it's about, then people could post suggestions on how they would design the software.

Any tips on game design to speed up coding or to simplify it, would be useful and appreciated.

I often use two important kinds of classes:

• Resource management classes. They represent some external resource that is being used by your program. Examples: user interface elements (such as windows), network connections, a handle for a sound API, or files you're reading or writing. You can obtain the resource in the constructor (open the network connection, create the window, open the file etc.), and release it in the destructor (close the network connection & so on). Examples of methods are methods for sending/receiving network data, drawing things in the window, reading/writing data from/to files. The member variables contain handles for the external resources and additional data that is necessary for remembering the state of the resource.
• Data classes. They represent the 'virtual' objects of your software. For instance, for Orbiter this consists of things like spacecrafts, planets and MFDs. The member variables contain all the state information of the object (e.g. positions, velocities for spacecrafts).

 

[Urwumpe]

Also, I recommend to extend the two classes of cjp by using the classic Design Patterns as reference, until you are good enough to realize that the Design Pattern are not the end of all wisdom. For 99% of the work, the Design Pattern cover it all good. The remaining 1% are the reason why good programmers are so rare.

Also, being able to read the code has a higher priority than writing fast programs. If you don't know if you can find bugs in the best code, use a slightly worse one for the start and implement the better code as option once you have a reference for debugging.

And: Don't worry if 99% of your code is bureaucracy to make the important 1% of the code look good. Smart ways to handle your data and get the data into action are critical. Such infrastructure is just normal. For example it is often harder and much more code to read information for a small game or part of a game from configuration files, instead of hard coding it. But the work pays out when you extend this part, and have a clean separation of data and code to work with.

And the most important rule: Don't waste a single second thinking that you have now learned enough and can do it all. There is always unwritten code waiting for you, and especially games depend a lot on the programmer being able to find non-standard solutions for non-standard problems. Experience is more important than talent, because talent without experience is wasted talent, while you can become a great programmer from experience alone...it just takes much more time and much more discipline and much more dirty boring standard code work. But well...Rome wasn't build on a single day.

 

[dbeachy1]

And: Don't worry if 99% of your code is bureaucracy to make the important 1% of the code look good. Smart ways to handle your data and get the data into action are critical. Such infrastructure is just normal. For example it is often harder and much more code to read information for a small game or part of a game from configuration files, instead of hard coding it. But the work pays out when you extend this part, and have a clean separation of data and code to work with.

:goodposting: Well-said! Sometimes you necessarily end up with a lot of code in your framework (which is "hidden") just so that your main code (which is not "hidden") is easy to extend and reuse. Like Urwumpe said, that often takes more work up front and results in more total lines of code, but it pays off big-time later because once your core framework is finished and debugged you don't have to mess with it just to extend your main code. So don't feel bad about having to write a lot of "hidden" code just so your "main" code is easy to understand and extend. Complex programs require lots of code -- there is no way around that. And the cleaner you can make the "non-hidden" part of your code, the better -- even if that means a more complex "hidden" framework underneath it. :thumbup:

 

[ar81]

One of the things that I have realized by now is that giving intuitive names to local variables and properties, as well as making the object easier to use by main code is something that requires design. That way I should not come to remember how should I use its properties and methods.

I am also debating about making a single object to manage groups of things, or making separate instances of an object. Making a single object for an array of things requires indexing and it allows searching objects and returning a result, but it also makes the management a bit more complex.

For example if I have the name of a station or base and the location where it is, and I want to determine if location is a planet or moon, if it is inner or outer solar system, etc, it looks to me that I should use a single object to manage all planet data. Right?

So if experience prevails it means we need trial and error, dumping projects because of a bad decision? I plan to go for a master degree in the near future, and I think all the pitfalls I have had with Space Orbinomics may be rewarding as a lesson, but I am also concerned about if I would be able to make projects without dumping them half the way.

 

[MeDiCS]

It's inevitable you'll dump code, for a variety of reasons, and it's no problem if you come up with better code to replace it, or just don't need it altogether. It's one of the main reasons to use a SCM (Source Code Management) system, such as SVN, Git, Mercurial, etc.

 

[ar81]

It seems to me that I also need to document how to use objects in my code.
After a few months I will not remember how to use the object.
So I think preproduction design will be a key part of design.

It also looks like having a flat structure of objects seems better.