I have 4.5k lines of code and no clue

[TSMI]

I have a "roguelike". it's 4.5k lines of code. It's data driven, favours composition over inheritance, is very encapsulated, and it barely does anything. It hurts my head even thinking about it. Considering a re-write - this has happened to me multiple times, I get this far, get confused, and start again (usually in a different language).

My problem is not with individual algorithms. I either get them from a library or code them up myself.

My problem is about structuring game. What does this class/module/method/object/function/whatever do? What's it responsible for? How do I group them? What knows about what? Where does this information go? It turns into a huge spider web of confusion for me.

I know some people can just hack a game together and not care about how stuff looks or modularity or anything else. Those people presumably have much larger brains than i do, because even though my code is clean by most standards I still have no clue what's going on.

Are there any good resources on this higher level stuff? The interconnection between different parts? Because it's biting me in the ass again and again.

[TheCreator]

Don't rewrite. You will probably make similar mistakes over and over again, it's always like that. Instead just go on with your old code. After reaching a certain point the more code you have, the easier it seems to maintain. Really. It's just hard to have the complete image at the beginning, but as soon as the code grows, you suddenly see what the real problems are and you are able to fix them step by step.

[Krice]

What does this class/module/method/object/function/whatever do? What's it responsible for?

If you don't know where you need a class you are in trouble I would say. Classes or any code at all is designed for a purpose, in other words the reason for that class to exist must come first. We need source code only to express and implement the ideas of a gameplay.

[Quendus]

I tend to make mistakes when it comes to this kind of thing as well. Start by commenting your code, possibly renaming functions and arguments so that they self-document. Consider autogenerating HTML documentation with some system or other.

For the process of deciding which class each function/functionality should go in, a software engineering book or blog might be worth a read (I don't have any specific recommendations). A decent general guideline would be that each module of the code should have as small an interface as possible to the rest of the code. Sometimes it's just not possible to make those interfaces as small as you want them, and you have to either refactor classes or sacrifice interface size.

One thing that's *really* helpful when dealing with large codebases is a way of typing part of a function name and going to its definition. This could be either an actual feature, or just a text search that covers all open files or all project files. If you're in a state of flow, and your functions are well enough named that you can remember/guess what the function you're looking for is called, then you can get around a complex codebase very quickly without needing to remember where everything is.

The other advice I would give is: If you're writing a game, write a game. Not an engine.

[TSMI]

I tend to make mistakes when it comes to this kind of thing as well. Start by commenting your code, possibly renaming functions and arguments so that they self-document. Consider autogenerating HTML documentation with some system or other.

I do all of the above, though I should possibly do it even more.

The other advice I would give is: If you're writing a game, write a game. Not an engine.

Guilty as charged.

[TheCreator]

I tend to make mistakes when it comes to this kind of thing as well. Start by commenting your code, possibly renaming functions and arguments so that they self-document. Consider autogenerating HTML documentation with some system or other.

I do all of the above, though I should possibly do it even more.

Documenting the code won't help you if you don't have any idea how it should work. One issue I can deduce from your previous post is that you try too hard to follow OOP rules. As a contrary, in my game some of the crucial classes are not encapsulated at all - their members are public. What is more, the instances of these classes are global variables. Very ugly design, but it never caused any serious harm. Perhaps you should do the same at the beginning. You can refactor your code later - if you ever feel that it solves some problem. If the encapsulation only prevents you from writing code, just don't use it.

[Ancient]

I have a "roguelike". it's 4.5k lines of code. It's data driven, favours composition over inheritance, is very encapsulated, and it barely does anything. It hurts my head even thinking about it. Considering a re-write

PRIME is 45k lines of code not counting generated files. It is strongly data driven, uses hardly any composition or inheritance, is somewhat encapsulated.

The most often linked article at rec.games.roguelike.development in response to questions about rewrites is this: http://www.joelonsoftware.com/articles/fog0000000069.html . For good reason.

My problem is about structuring game. What does this class/module/method/object/function/whatever do? What's it responsible for? How do I group them? What knows about what? Where does this information go? It turns into a huge spider web of confusion for me.

This is a sign of trying to foresee everything.

Take executing a floppy disk of hacking in PRIME. You (here a monster/hero game instance) use two objects: a computer and the floppy disk. Should the doHack procedure be a member of shObject or shMonster (who does the hacking)? Hero->doHack (comp, disk) or ...? Should the object the function is called on behalf of be the computer or the floppy disk? comp->doHack (disk) or disk->doHack (comp)? Maybe it should stay a separate routine accepting both a computer and a floppy disk? Programming::doHack (hacker, comp, disk)?

Does not matter half as much as you might think. Quit worrying and pick one you like best. I am pretty sure no option will make coding things significantly harder for you. Making a decision propels you forward and *then* you may really examine the impact of your choice. Chances are you will not care much at that point because possible improvements stemming from choosing another approach are minuscule enough to not be worth the effort of switching.

[Krice]

try too hard to follow OOP rules. As a contrary, in my game some of the crucial classes are not encapsulated at all - their members are public. What is more, the instances of these classes are global variables. Very ugly design, but it never caused any serious harm.

The most important thing in game development is make the game run and work. Players don't care how it is done. However I would say in right hands OOP is more powerful and it can also prevent bugs which are often difficult to fix. When I look at my transition from C to C++ one of the results has been a dramatic change in the number of bugs.

[requerent]

I have a "roguelike". it's 4.5k lines of code. It's data driven, favours composition over inheritance, is very encapsulated, and it barely does anything. It hurts my head even thinking about it. Considering a re-write - this has happened to me multiple times, I get this far, get confused, and start again (usually in a different language).

My problem is not with individual algorithms. I either get them from a library or code them up myself.

My problem is about structuring game. What does this class/module/method/object/function/whatever do? What's it responsible for? How do I group them? What knows about what? Where does this information go? It turns into a huge spider web of confusion for me.

I know some people can just hack a game together and not care about how stuff looks or modularity or anything else. Those people presumably have much larger brains than i do, because even though my code is clean by most standards I still have no clue what's going on.

Are there any good resources on this higher level stuff? The interconnection between different parts? Because it's biting me in the ass again and again.

If you want to throw your code up on pastebin or google code, I'd definitely take a look at it.


It's difficult to know what is really causing you problems. I mean, you have a game loop and you have a series of objects that update in that game loop. Then you have a display manager that reads the information happening from the game and displays it on the screen for the player.

[TheCreator]

The most important thing in game development is make the game run and work. Players don't care how it is done. However I would say in right hands OOP is more powerful and it can also prevent bugs which are often difficult to fix. When I look at my transition from C to C++ one of the results has been a dramatic change in the number of bugs.

Yep. But only in right hands. I remember my earliest days of C++ development. That was an OOP disaster. I used to have more bugs than lines of code. Every single feature would crash sooner or later. I did not use a debugger. I did not have source control. I did not have unit tests. The only good thing was that I dared to ignore encapsulation rules. That allowed me to proceed with the game, somehow. Had I done otherwise, the project would have been dead and forgotten already.

[guest509]

  That happens to me to, or used to. Trying to keep the entirety of the code base in my head at any one time. I actually gave up on being a programmer because my brain just wasn't working that way. So I have no solutions. I think the issue you are facing is a very common issue though, so take heart, it happens to everyone.

[kraflab]

The most important thing when writing a game is, in my mind, getting an absolute bare-bones playable entity as soon as possible.  Make it so there is no engine.  When I start a roguelike the first build is just a character moving on a map, and the sooner the better.  Don't get bogged down in wondering if you have anticipated every possible connection between objects that you'll need.  Put pieces of engine onto your game rather than pieces of a game onto your engine.

In terms of maintaining oop principles, you should just do whatever works for you.  As far as I'm concerned, "Public:" is part of the opening brace of a class definition.  I write things very strict and very sloppy at different times depending on what type of mood I'm in, and it doesn't seem to make a real difference to me.  I could see that type of worrying being important if you are coding a game with someone, since you want the code style to be the same across the board, but otherwise don't worry about it.  You'll end up writing cleaner code automatically (and if you get upset about an old bit of code you can do a small rewrite of that section, faster because you'll be more experienced).

Really, to anyone else who has problems dealing with large blocks of code, my advice is to just keep making more programs and games.  Each time you make one, you make the next faster, cleaner, simpler.

[Munge]

The other advice I would give is: If you're writing a game, write a game. Not an engine.

Guilty as charged.

[/quote]

This is always the problem, the best/quickest developed roguelikes are "bad" code, cobbled together at light speed. My "quick-hack" code is full of singletons, static variables, and if I want to do something I just do it and I dont really care where it goes - that way you can get the job done.

Dont ever add features because you think you will need them, write a game, only a game, expand your game with features etc. 

If you are a professional programmer you would probably spend 6 months designing interfaces, components and tests before one line of code, then a few more months prototyping, interface definitions, components, unit testing .... No. Write the game from the start, then you have a game.

[roocey]

The other advice I would give is: If you're writing a game, write a game. Not an engine.

Guilty as charged.

This is always the problem, the best/quickest developed roguelikes are "bad" code, cobbled together at light speed. My "quick-hack" code is full of singletons, static variables, and if I want to do something I just do it and I dont really care where it goes - that way you can get the job done.

Dont ever add features because you think you will need them, write a game, only a game, expand your game with features etc. 

If you are a professional programmer you would probably spend 6 months designing interfaces, components and tests before one line of code, then a few more months prototyping, interface definitions, components, unit testing .... No. Write the game from the start, then you have a game.

This is what I do too. I wonder: is this a common trait for people who learn how to program by making games?

The code for @Star Wars is quite messy and poorly documented. I'm wary of going open source for those reasons, but it still works, which, at the end of the day, is all I can really ask for. I contemplated the idea of giving up @Star Wars or restarting from scratch numerous times, but eventually I was able to work out most of the major kinks and got everything in place that I needed to really start working on the game.

[requerent]

This is what I do too. I wonder: is this a common trait for people who learn how to program by making games?

No matter how much self-driven practice you have, it's very difficult to uncover a more productive programming paradigm on your own.