• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
LAURENT*

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

26 posts in this topic

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?

0

Share this post


Link to post
Share on other sites

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

Edited by LAURENT*
0

Share this post


Link to post
Share on other sites
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.
2

Share this post


Link to post
Share on other sites

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.

2

Share this post


Link to post
Share on other sites

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*
0

Share this post


Link to post
Share on other sites

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.

2

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

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).

2

Share this post


Link to post
Share on other sites

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.

2

Share this post


Link to post
Share on other sites

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...
1

Share this post


Link to post
Share on other sites

 

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.

0

Share this post


Link to post
Share on other sites


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.

0

Share this post


Link to post
Share on other sites


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).

0

Share this post


Link to post
Share on other sites

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.

2

Share this post


Link to post
Share on other sites

I've redone the whole code and  made a prototype file exclusively for testing. I still need to do more testing but I'm going to try my hardest to have code up for review. I'm still alive.

0

Share this post


Link to post
Share on other sites
In my opinion the most important thing you need to tell yourself while coding(at least the one that bothers me the most) is that your code won't ever be perfect.

Personally if I don't end up rewriting lots of code or second guessing myself I at least THINK about doing it. A lot of people preach a lot of best practices here, and they are good to follow, but in reality the only real rule about coding a game is that the game has to work. Its a thing that a lot of us tend to forget and get hung up a lot on specifics. A lot of code for AAA games that seem all professional and nice are tangled webs of awfulness sporting every bad coding practice you ever have seen.

So basically, even if it nags at you crazy that you are being a bad coder, just try to focus on making it work and then thinking of ways to improve it later on.
1

Share this post


Link to post
Share on other sites


Personally if I don't end up rewriting lots of code or second guessing myself I at least THINK about doing it. A lot of people preach a lot of best practices here, and they are good to follow, but in reality the only real rule about coding a game is that the game has to work. Its a thing that a lot of us tend to forget and get hung up a lot on specifics. A lot of code for AAA games that seem all professional and nice are tangled webs of awfulness sporting every bad coding practice you ever have seen.

 

You still have to think about why this is happening. Most AAA games have a very thight deadline, and lots of money depends on fulfilling it. Also, there are probably people with that much experience in such an AAA-gamedev-team, that can work with this horrible code just like most other people do with "good" one. Even I notice with growing practice how much easier it gets to read and understand other peoples code, no matter how badly is is written. Also, in such an AAA-environement, probably most of the code in the end is hidden under some toolset, using an editor & scripting/visual scripting, so its not that bad.

 

I just feel that just "getting things to work" is, depending on the aims of the OP a little waste of time. He isn't part of any company and doesn't have any restrictions. Why not spend a little time getting to know how to create better code? I always try to view the cost/gain of things. If I spend an afternoon thinking about and refactoring my game object system, so that creating a new game object takes significantely less time, is less prone to error and thereby saves time spent on debugging strange errors, and also increases readability, why not? I already said in a previous post, I also worked under the motto "just get things done", and after ~6 months of work I ended up with a mario-clone I just couldn't work on any further. I would have liked to add powerups, etc... but the code was so badly broken... (3k LOC player class etc...). Why should a beginner, that just codes for a hobby, really try to "sh*t" code/features out as fast as he can? I think that improving your way of working with creating games is far more valueable. If you know how to create good code, you can still throw out badly coded pieces of work to get stuff done quickly, in a much more efficient way. If you don't, you will even struggle with what some people might declare "just get it done"-type of code.

0

Share this post


Link to post
Share on other sites

In my opinion the most important thing you need to tell yourself while coding(at least the one that bothers me the most) is that your code won't ever be perfect.

Personally if I don't end up rewriting lots of code or second guessing myself I at least THINK about doing it. A lot of people preach a lot of best practices here, and they are good to follow, but in reality the only real rule about coding a game is that the game has to work. Its a thing that a lot of us tend to forget and get hung up a lot on specifics. A lot of code for AAA games that seem all professional and nice are tangled webs of awfulness sporting every bad coding practice you ever have seen.

So basically, even if it nags at you crazy that you are being a bad coder, just try to focus on making it work and then thinking of ways to improve it later on.

 

This is a thing all programmer must struggle with, even if its not in their nature. When is it "good enough"?

Some people thing too little is good enough, coming short of having something that works within acceptable parameters. Others have their own quality standards which far exceed what would be sufficient, thus never actually releasing.

 

If you are programming for yourself, it may be complex to assess the 'good enough' and live by it (you don't have someone else QA-ing your code and saying 'that's fine'). Though the OP may indeed require more experience in the field, the above remains relevant to other individuals (if not all).

"Write games, not engines" :)

0

Share this post


Link to post
Share on other sites

Also, there are probably people with that much experience in such an AAA-gamedev-team, that can work with this horrible code just like most other people do with "good" one. Even I notice with growing practice how much easier it gets to read and understand other peoples code, no matter how badly is is written.

Not sure where you get that idea, bad code is harder to read than good code, thats kind of a generic point that relates nothing to how good you are at reading code. It's also not a good excuse. That's like saying you serve worse and worse food in your restraunt because the customers have progressively gotten used to bad taste. Your teammates are customers to your code, they're the ones that have to swallow it when they work with it.

Also, in such an AAA-environement, probably most of the code in the end is hidden under some toolset, using an editor & scripting/visual scripting, so its not that bad.

Not sure where this one comes from either, plenty of companies still code their own engines, even those using stuff like Unreal will still end up having to write a bunch of code generally, there will be plenty of programmers out there dealing with code that isn't hidden under a fascade of a tool.

I just feel that just "getting things to work" is, depending on the aims of the OP a little waste of time. He isn't part of any company and doesn't have any restrictions. Why not spend a little time getting to know how to create better code?

Because it isn't a little code, proper programming practices are often a lot of learning and practice and hard calls to make without having written the same kind of "thing" a hundred times before. A lot of people(including myself) got a lot of spiel from places like here where everyone was basically going "No you have to do it THIS way, otherwise it sucks." It stuck, many a time I sat there staring at code thinking "I know this is wrong, but how do I fix it?" Days and weeks and months of wasted time trying to be 'correct' when in reality I should have just been putting code to keyboard.

If anything there should be a rule that whenever you code something new, the first two or three times you make a similar thing, you forget all coding good practices and just make the code work, see what it actually does and what it needs and ignore generic advice.

I always try to view the cost/gain of things. If I spend an afternoon thinking about and refactoring my game object system, so that creating a new game object takes significantely less time, is less prone to error and thereby saves time spent on debugging strange errors, and also increases readability, why not?

Except I would bet money that you spend much more than an afternoon on it, if you work on a game for a month you might spend days of time just worrying about refactoring. If I had to be logically accurate the only real way that better code is ever worth more money is when it saves more effort in the future.

Everything past that is just being nice for the coder, and although I'm a stickler for pretty code, the reality is that you're going to be working with a lot of slobs or people being rushed to get things put together, so its worth learning how to deal with it and not just be used to everything being neat and perfect.

Why should a beginner, that just codes for a hobby, really try to "sh*t" code/features out as fast as he can?

Because it is one of the only feasible ways you can learn. For instance people on these forums often demonize the concept of a singleton or any kind of global managers. Problem is those things usually simplify code, they simplify it enough to where a lot of developers use them religiously for things like engine subsystems. For a beginner or just for a small project they are probably time savers more than anything else, but I was taught to avoid them like the plague.

If anything that just points out that "there is no golden rules in programming" should apply to best practice advice as well.
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0