Jump to content

  • Log In with Google      Sign In   
  • Create Account


I hate my code....How do you structure your code for a game?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
26 replies to this topic

#1 LAURENT*   Members   -  Reputation: 186

Like
0Likes
Like

Posted 08 June 2014 - 09:20 AM

I must learn this magically technique of putting everything together neatly so I can finally stop hitting road bumps or a lot less of them. Is there any techniques for doing this?



Sponsor:

#2 sunk   Members   -  Reputation: 202

Like
13Likes
Like

Posted 08 June 2014 - 09:46 AM

With out being to specific, I've found that breaking things up into many small components works well, not only for games but for general software. The idea is to make many small components (that does only one thing, but it does it very well) that are easier to test and maintain and build something bigger out of them. For example, when making a game, you might want to write a generic lighting system that's totally separate and not coupled with any game code. This component has a simple interface that exposes only a few functions/methods to clients so that its easier to maintain and less breaking when changes are made. Don't embed any specific domain knowledge into the component.

 

Then you can start putting these components to together to build something bigger. Testing becomes easier and finding out where a bug lives is also easier since there's only one place you'll likely need to look. Try limiting them to only exposing one/two functions.

 

Also here's a good link more specific to game design: http://stackoverflow.com/questions/1901251/component-based-game-engine-design . Search gamesutra for similar articles since they do talk about similar topics.

 

I'd also say try being more DRY. If you find a open source library that does what you need, don't write your own and just adopt it. Make changes as necessary and commit to the project if it doesn't meet your needs. Also read books like: clean code. Author talks alot about writing more maintainable code.



#3 ilreh   Members   -  Reputation: 281

Like
6Likes
Like

Posted 08 June 2014 - 10:30 AM

With the capablities of OOP people get often tempted to build an all-purpose engine instead of a game. Does your code really have to be that "maintainable"? Code gets rewritten all the time. Game companies dump the game in the middle of the process and start anew because they decided to make the game differently. Software companies often have a horrible codebase because they focus on making requirements work and satisfying their client next to nothing. See game development as an iterative process and just add that one function wherever it fits. You will rewrite it anyway. Once the functions are there and you have figured out how things work, reconnecting the dots is always possible.

#4 Andy Gainey   Members   -  Reputation: 1977

Like
3Likes
Like

Posted 08 June 2014 - 11:04 AM

Here's an example of someone going through a good process of structuring code:  Casey Muratori:  Working on The Witness, Part 11

 

The essence is to just write the code to do exactly what you need it to do at first.  Then refactor as you go, whenever you see opportunities for code reuse.  The data structures and code structure that will result will probably fit your needs quite appropriately, rather than being ill-suited in the way that unfortunately often happens with up-front design.



"We should have a great fewer disputes in the world if words were taken for what they are, the signs of our ideas only, and not for things themselves." - John Locke

#5 Alundra   Members   -  Reputation: 795

Like
4Likes
Like

Posted 08 June 2014 - 11:16 AM

It's nice to not like your code, because then you want more and more.

The best way to have a good code is to practice more and more until you have more results with less code.

It's called the experience and you can't get it without working on projects.



#6 swiftcoder   Senior Moderators   -  Reputation: 9731

Like
11Likes
Like

Posted 08 June 2014 - 11:20 AM

  1. Keep it simple
    If you need a feature once, write it the simplest way possible. If it turns out that you need that feature over and over, only then should you refactor it into a generic solution.
  2. Don't be afraid to refactor
    If you find your the design/API of earlier components are causing problems later on, refactor them to make more sense. You know more about how the system fits together now, than you did when you wrote it the first time.
  3. Prototype often
    Get features in a rough form first, so that you can see if they work well in the system. If they aren't, go back to the drawing board before you invest too much time.
  4. Work with others
    Having someone else work on the same codebase (and review each other's code) is a great way to keep the code clean. You will each be accountable to someone other than yourself, and you both need to be able to understand the code.

Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]


#7 LAURENT*   Members   -  Reputation: 186

Like
0Likes
Like

Posted 08 June 2014 - 05:12 PM

My code uses classes. Should I have classes with the same variables? Is this simple?


Edited by LAURENT*, 08 June 2014 - 05:33 PM.


#8 Tutorial Doctor   Members   -  Reputation: 1506

Like
2Likes
Like

Posted 08 June 2014 - 09:38 PM

I so know the feeling. Especially lately. I have taken a break myself. I have enough stress at work. Haha.

I guess I am the all purpose engine maker. Trying to make my code reusable and easy to understand so that I will be able to make the next game quicker.

My road bumps come from logic problems far above my reasoning skill. I guess keeping it simple as possible should help us.

They call me the Tutorial Doctor.


#9 Ravyne   Crossbones+   -  Reputation: 6892

Like
9Likes
Like

Posted 08 June 2014 - 10:20 PM

Its kind of a skill that can only be developed through practice and experience. Over time you'll develop a sixth sense about code and code structures that are bad now and only going to get worse if they stay as they are.

 

As some guidelines --

Keep things simple: Start by only implementing functionality you need. The only thing worse that building the wrong thing early is building a *lot* of the wrong thing early. This also helps stop you from building things without having need-driven requirements.

Follow the DRY (Don't Repeat Yourself) principle -- Whenever you write the same code more than once, its a candidate for becoming a function. Especially now that most languages support some kind of lambda function, you can easily factor out common code, even if its never useful outside of one function.

Prototype and explore -- Even people with a lot of experience don't just get things right from the git-go; Everyone builds little prototypes, redesigns, and refactors pretty aggressively.

Seek critique: Its hard to learn by reading other people's code, especially when you're too green yourself to evaluate its quality. Better for someone with less experience is to submit your code for commentary -- by those with real experience -- and to take their suggestions and implement them in your code.

 


My code uses classes. Should I have classes with the same variables? Is this simple?

This question makes me think that maybe you're really green, and need to spend some time concentrating on learning programming fundamentals. But I'll try to give an example.

 

A class is a kind of cookie-cutter, its not the cookie itself -- Imagine that you're making a Pong clone. You don't create two paddle classes, one for each player -- instead, you create one paddle class, and then you realize two of them (two "instances" of the class), assigning one for each player. The ball might be a separate class -- even though there's just one, you still create the ball class and then realize a single one (just one "instance"). Now, say, you want to spice things up with a crazy, 3-ball sudden-death tie-breaker. Because you have a ball class, you can just create two more instances. But doing so might expose places in your code where you assumed there would only ever be one ball -- *the* ball -- and so you will have to take that existing code and change it to work with multiple balls. This is refactoring, and its perfectly normal. With experience, you'll begin to see opportunities to build this kind of flexibility into your code before you need it -- this kind of flexibilty, driven by opportunity rather than kitchen-sink-thinking, is usually good -- good code is flexible in these kinds of ways. However, beware of adding unnecessary flexibility, in keeping with keeping things simple.



#10 kunos   Crossbones+   -  Reputation: 2203

Like
2Likes
Like

Posted 08 June 2014 - 10:45 PM

My code uses classes. Should I have classes with the same variables? Is this simple?

 

this sentence doesn't make sense at all... and that means you are simply still a beginner and your knowledge of programming is not yet at a level where you can actually discuss about these things.

 

Concentrate to make things work, no matter how ugly they are, you'll make them prettier and reusable later. Keep studying and making games, have a look at some other people's code.. you'll start to see patterns emerging... that's all that it is: just experience.


Stefano Casillo
Lead Programmer
TWITTER: @KunosStefano
AssettoCorsa - netKar PRO - Kunos Simulazioni

#11 LAURENT*   Members   -  Reputation: 186

Like
0Likes
Like

Posted 09 June 2014 - 05:55 AM

Hey I'm almost practically self taught so I may have holes here and there. I'm only using classes because every source code I found uses them. Hey if their doing it why not do it too. I'm keeping the classes  it looks like something I should get used to.

 

 

I'm going to post some code up later and let you guys evaluate it. My code will be simple, easy to test, and classes won't have variables of the same name. 


Edited by LAURENT*, 09 June 2014 - 09:18 AM.


#12 Alundra   Members   -  Reputation: 795

Like
2Likes
Like

Posted 09 June 2014 - 09:26 AM

You can write a whole game without class, look at quake source code, it's a monster source code without one class.

If you say you use class because others use class, that only mean you don't understand what class give you.



#13 SuperG   Members   -  Reputation: 476

Like
0Likes
Like

Posted 09 June 2014 - 11:12 AM

You can write a whole game without class, look at quake source code, it's a monster source code without one class.

If you say you use class because others use class, that only mean you don't understand what class give you.

Might it not be that in those old day those dev where very routine in C programming and C++ was then fresh to them.

And with that approach used or see C++ from C perspective.

 

Also MS flight simulator keep rather long in that series to full assembler use.

 

I think it's more every thing has it's pro's and con's. And with that depending on the situation it can be really good thing and others a bad thing. 

So Classes has there place but it is not the solution everywhere. Yes with experience you get in the long run a better routine in this. But following other blindly you might learn bad practices.

Also you an use classes where appropriate.

That my impression and her say.

Just like Laurent I am a beginner to.



#14 Orymus3   Crossbones+   -  Reputation: 6840

Like
2Likes
Like

Posted 09 June 2014 - 01:44 PM

The key answer here is simply: practice.

 

I was working on a game once (and the code really sucked). Taught me a lot about what I did not want to do on the next project. But even as I moved with the project, I learned. If you are not affraid to refactor as you go, then your organization will be better than if you try to plan everything ahead.

 

For example, it is possible that, in the course of programming a game, you'll end up with something you call "bullets". For the sake of the argument, I'll assume you are using OOP and using classes. At a given point in time, you might realize that bullets continue to exist upon release and still have meaningful interactions in the given world. 

 

I would suggest using a "manager" or "controller": Essentially, a singleton (an object you instantiate only once) that will handle all of the operations that are relevant to all of your bullets. While these actions will still be governed by the bullet themselves, the logic will feel more intuitive, and the performance will be much better as well.

 

It is just one example of something you might uncover while practicing. (I realize some people may say there's a better way to handle this, but true learning comes from meddling with things, so I'd rather let the OP experiment and figure it out on his own).



#15 Juliean   GDNet+   -  Reputation: 2330

Like
2Likes
Like

Posted 09 June 2014 - 05:32 PM

Warning, the following post is heavily opinion based, but I feel this can morever so help a beginner from engaging in some very bad practices (and, you know, these opinions where formed through my own practice).

 


I would suggest using a "manager" or "controller": Essentially, a singleton (an object you instantiate only once) that will handle all of the operations that are relevant to all of your bullets. While these actions will still be governed by the bullet themselves, the logic will feel more intuitive, and the performance will be much better as well.

 

While I personally would say that something like a bullet-manager is reasonable, specially for a beginner project, there is NO reason ever for it to be a singleton. Does he need access to the bullet manager throughout his entire game? Probably not. Should there every be only one bullett manager? To be fair, he might probably only ever need one, but that does not mean that instantiating a second one hurts, and the unnecessary global access kills it all. I just had to write this, because not only is singleton the one pattern that gets told to each and every beginner that there is (seriously, name one person that did not come across it as one of their first patterns they heard of). Also its just misused almost always, like in this case. Specially for someone who quote unquote states that he "hates" his own code, won't lead to any good. So, don't do singleton, never ever, this will help in keeping your code at least halfway clean.

 


Keep it simple
If you need a feature once, write it the simplest way possible. If it turns out that you need that feature over and over, only then should you refactor it into a generic solution.

 

I also got a slight problem with this, because out of my own experience, beginners code faults doesn't really come from overengineering. I can probably only speak for myself beacuse thats where I've seen it, but my first code didn't suck because I tried to add too many things or wanted to be clever by designing it in all weird ways, but because I simply didn't know how to write good code. So K.I.S.S. is probably rather a thing to recommend to an intermediate, if a beginner tries to account for it, it might even reduce in worse code, because that beginner might be thinking to himself: "Am I overcomplicating it by making a seperate class for it? Isn't it overkill to add this as a private method instead of just granting public global access?".

 

As for some direct advice for the OP. Partice, by trial and error. Dont' be afraid to refactor, as others have said, and also don't be afraid to start over. Once you've gotten the hang of programming per se, also don't be afraid to try out different kind of coding styles and patterns. You are not part of some game company and therefore not under any pressure or deadline whatsoever. As long as you work alone, its a safe playfield for you to test whathever you want, and see what works, and what doesn't. Always have a straight goal in mind you are working on - e.g. "I want to get enemy patroling going", and design your code around that goal. Also, if you have any specific questions about your code design, feel free to ask them here on the forums, there is enough people to be willing to help you.



#16 swiftcoder   Senior Moderators   -  Reputation: 9731

Like
1Likes
Like

Posted 09 June 2014 - 05:40 PM

So K.I.S.S. is probably rather a thing to recommend to an intermediate, if a beginner tries to account for it, it might even reduce in worse code

Yes, at the time I wrote that, the OP's skill level was not clear, and this isn't the "for beginners" forum, so...

Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]


#17 ilreh   Members   -  Reputation: 281

Like
0Likes
Like

Posted 09 June 2014 - 08:16 PM

 

I also got a slight problem with this, because out of my own experience, beginners code faults doesn't really come from overengineering. I can probably only speak for myself beacuse thats where I've seen it, but my first code didn't suck because I tried to add too many things or wanted to be clever by designing it in all weird ways, but because I simply didn't know how to write good code. So K.I.S.S. is probably rather a thing to recommend to an intermediate, if a beginner tries to account for it, it might even reduce in worse code, because that beginner might be thinking to himself: "Am I overcomplicating it by making a seperate class for it? Isn't it overkill to add this as a private method instead of just granting public global access?".

 

How can K.I.S.S be a bad advice? The point here is that you can't give anyone reasonable advice on how to structure their code without reading through all of it. Why? Because those situations tend to be unique and if there was a book that could make anyone apply a fitting structure for any situation there was no need for programmers. A programmer has a problem and finds a solution, ideally with least involvement of ressources and greatest stability. That's what programmers do. The more problems you solve, the better you get.

 

There is no "using this is always wrong" or "do that and you're fine". Well yes, you can tell someone to pass by pointers instead of copying the variable and use the return in a certain situation or that include guards might save you trouble in the long run but an advice on how to structure their code IN GENERAL? There's only one advice I can give: if anyone tries to tell you how you should generally go about structuring your code -> move on.

 

People pay lots of money for experienced people who are able to make fast and good decisions for new problems. There's a road that people walked to get to that level (and lots of smashed keyboards and rivers of coffee). If you know the language and don't like that code you wrote then rewrite it (don't tell me you can't, there's a thought on which you base your disgust). Of course if you're a beginner, the first programs you write will be poorly written. What did you expect? If you could apply a good structure for a new and demanding requirement and make it all run then you wouldn't be a beginner.



#18 Juliean   GDNet+   -  Reputation: 2330

Like
0Likes
Like

Posted 10 June 2014 - 03:59 AM


How can K.I.S.S be a bad advice? The point here is that you can't give anyone reasonable advice on how to structure their code without reading through all of it. Why? Because those situations tend to be unique and if there was a book that could make anyone apply a fitting structure for any situation there was no need for programmers. A programmer has a problem and finds a solution, ideally with least involvement of ressources and greatest stability. That's what programmers do. The more problems you solve, the better you get.

 

I didn't say it was bad advice per se, but its a little inappropriate here. True, you can't recommand any patterns or coding styles without seeing any piece of code the OP wrote, but I'd say that for someone that said all out of them selfs "my code sucks", chances are that K.I.S.S is not going to help him at all. Lets take myself as an example, my first code did really suck and I knew it, because after a certain point there was just no going on. I didn't refactor, thats for sure, but I also had a problem where I wouldn't want to create a new class for a new feature, because I though it was going to make my code 10 times as complicated. So if someone told me about "K.I.S.S" I'd probably have been like "yeah, I already don't make new classes and try to keep things in one class, so what?". Point is, there is much point of missunderstanding and it can hinder work for someone who already has problems with his own code.



#19 Orymus3   Crossbones+   -  Reputation: 6840

Like
0Likes
Like

Posted 10 June 2014 - 06:39 AM


So, don't do singleton, never ever, this will help in keeping your code at least halfway clean.

 

I've heard this a lot. What is the reasoning behind "singletons are evil"? I'm not disputing they are, I'm just curious (I could learn from this).



#20 swiftcoder   Senior Moderators   -  Reputation: 9731

Like
2Likes
Like

Posted 10 June 2014 - 06:54 AM

I've heard this a lot. What is the reasoning behind "singletons are evil"? I'm not disputing they are, I'm just curious (I could learn from this).

This is a decent overview. I'd rather we didn't derail this thread with a singleton discussion, so create a new thread if you want to discuss pros/cons.


Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS