Temple of The Roguelike Forums
Development => Programming => Topic started by: TSMI on January 31, 2013, 07:39:21 AM
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
How do you mean? It seems to me that the only way to uncover more productive programming is to do it on your own. Someone teaching you is going to teach you their way. Even if they've already discarded the less productive techniques, isn't it likely that there are other more productive techniques you won't learn from them?
-
How do you mean? It seems to me that the only way to uncover more productive programming is to do it on your own. Someone teaching you is going to teach you their way. Even if they've already discarded the less productive techniques, isn't it likely that there are other more productive techniques you won't learn from them?
I agree with this 100%. The only way to uncover a more productive programming paradigm is on your own, since no one else is you :P
-
How do you mean? It seems to me that the only way to uncover more productive programming is to do it on your own. Someone teaching you is going to teach you their way. Even if they've already discarded the less productive techniques, isn't it likely that there are other more productive techniques you won't learn from them?
Disagree completely. You learn to program from somewhere. Even if you pick up a book and teach yourself, you utilize the techniques and paradigms within. Self-taught programmers typically learn procedural programming. A little bit of education and you learn about the invariably superior advantages of OOP. Then you typically discover that your hierarchy is unwieldy and the overhead is too large, a bit more education and you learn about aspect-oriented or component-based design- etc. Then you have development/design methodologies like test-driven, agile, black-box, SOLID etc.
Different models are better/worse for different degrees of complexity and applications. There are some that are generally bad in that they result in poor maintainability and difficult debugging.
Experience and education have dual-importance in the improvement of your expressiveness and productivity. A lot of research has gone into production methodologies/paradigms that don't really trickle down to introductory programming.
A few lists worth looking at to get an idea of the creative solutions people have come up with.
http://en.wikipedia.org/wiki/List_of_software_development_philosophies
http://en.wikipedia.org/wiki/Programming_paradigm
If you search "Is ____ good for games?" on google, you'll get a lot of interesting perspectives.
-
How do you mean? It seems to me that the only way to uncover more productive programming is to do it on your own. Someone teaching you is going to teach you their way. Even if they've already discarded the less productive techniques, isn't it likely that there are other more productive techniques you won't learn from them?
Disagree completely. You learn to program from somewhere. Even if you pick up a book and teach yourself, you utilize the techniques and paradigms within. Self-taught programmers typically learn procedural programming. A little bit of education and you learn about the invariably superior advantages of OOP. Then you typically discover that your hierarchy is unwieldy and the overhead is too large, a bit more education and you learn about aspect-oriented or component-based design- etc. Then you have development/design methodologies like test-driven, agile, black-box, SOLID etc.
It's silly to talk about "typical" things because you just have to make too many assumptions. I'm totally self taught and I have a completely different perspective from the one you provided. The "typical" anything doesn't exist, so there's no reason to talk about them :P My anecdotal evidence is just as meaningless as yours though.
Programming paradigms aren't magic secret codes. They're an obvious manifestation of the underlying systems. You don't need to read a book or check online to know they exist.
-
How do you mean? It seems to me that the only way to uncover more productive programming is to do it on your own. Someone teaching you is going to teach you their way. Even if they've already discarded the less productive techniques, isn't it likely that there are other more productive techniques you won't learn from them?
Disagree completely. You learn to program from somewhere. Even if you pick up a book and teach yourself, you utilize the techniques and paradigms within. Self-taught programmers typically learn procedural programming. A little bit of education and you learn about the invariably superior advantages of OOP. Then you typically discover that your hierarchy is unwieldy and the overhead is too large, a bit more education and you learn about aspect-oriented or component-based design- etc. Then you have development/design methodologies like test-driven, agile, black-box, SOLID etc.
It's silly to talk about "typical" things because you just have to make too many assumptions. I'm totally self taught and I have a completely different perspective from the one you provided. The "typical" anything doesn't exist, so there's no reason to talk about them :P My anecdotal evidence is just as meaningless as yours though.
Programming paradigms aren't magic secret codes. They're an obvious manifestation of the underlying systems. You don't need to read a book or check online to know they exist.
I'm just saying that it is ignorant to dismiss alternatives when there is a wealth of experience condensed into easy-to-follow techniques. Saying they're "obvious" is a little ridiculous.
-
It's silly to talk about "typical" things because you just have to make too many assumptions. I'm totally self taught and
Typical way for a young programmer is thinking that whatever he is doing is right. You need to be a little bit scientific mind to forget your ego and start gathering analytic information and experience from programming. It's good to remember that things like OOP were not invented by accident. They actually needed OOP in large scale programs and it was designed that in mind.
-
It's silly to talk about "typical" things because you just have to make too many assumptions. I'm totally self taught and
Typical way for a young programmer is thinking that whatever he is doing is right. You need to be a little bit scientific mind to forget your ego and start gathering analytic information and experience from programming. It's good to remember that things like OOP were not invented by accident. They actually needed OOP in large scale programs and it was designed that in mind.
Most programmers I know are pretty sure they know what they're doing is wrong :P
-
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.e 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.
Grepping my source directory for "goto" returns 66 matches. That might be a signal my code is sloppy. Never stopped me from publishing the sources.
Yes, I put a lot of hacky and decidedly "evil" solutions into the program. The high rate of bugs in PRIME is partially a reflection of this. The code is full of unneeded globals, too many statics and whatnot. Well, except singletons but that is mostly stems from my commitment to data driven paradigm over OOP.
-
This is what I do too. I wonder: is this a common trait for people who learn how to program by making games?
No, luckily it isn't. Some people (including me) would write the code first and start to think about any possible improvements much later. I'm unable to design anything without an existing code. It's just like sculpting, you can't create a sculpture out of nothing. Bad code is not necessarily a bad thing - it might as well be a raw block of stone that needs further efforts to become a masterpiece. I think that many programmers are missing this point.
On the other hand, I have recently found out that writing tests first (so called test-driven development) really helps to produce working complex code that would be otherwise very hard to get right. Once the test cases start to pass, your code is probably working. It's that simple. However, I doubt that it would be equally simple for a newbie programmer.
-
Grepping my source directory for "goto" returns 66 matches. That might be a signal my code is sloppy. Never stopped me from publishing the sources.
Good old goto:) It's not bad if it works and causes no bugs. Even Kaduria has 7 gotos, although most of them are relics from ancient times...
-
This is what I do too. I wonder: is this a common trait for people who learn how to program by making games?
No, luckily it isn't. Some people (including me) would write the code first and start to think about any possible improvements much later. I'm unable to design anything without an existing code. It's just like sculpting, you can't create a sculpture out of nothing. Bad code is not necessarily a bad thing - it might as well be a raw block of stone that needs further efforts to become a masterpiece. I think that many programmers are missing this point.
On the other hand, I have recently found out that writing tests first (so called test-driven development) really helps to produce working complex code that would be otherwise very hard to get right. Once the test cases start to pass, your code is probably working. It's that simple. However, I doubt that it would be equally simple for a newbie programmer.
Well, I can hardly consider myself to be a proper programmer. Perhaps its immature, but I did start off with the sole intention of creating a game. Learning how to program and all the related intricacies are secondary stepping stones - necessities probably, but secondary in my mind. Though I have to say after working with it for a couple years now, I've started enjoying programming more. It's quite satisfying when everything comes together and works as I hoped it would.
Grepping my source directory for "goto" returns 66 matches. That might be a signal my code is sloppy. Never stopped me from publishing the sources.
Yes, I put a lot of hacky and decidedly "evil" solutions into the program. The high rate of bugs in PRIME is partially a reflection of this. The code is full of unneeded globals, too many statics and whatnot. Well, except singletons but that is mostly stems from my commitment to data driven paradigm over OOP.
I'll have to consider just publishing my source someday in that case - maybe someone can learn from my mistakes. :D
I'm glad I got two responses with somewhat opposed points of view. I suppose that proves my original theory wrong.
-
This is what I do too. I wonder: is this a common trait for people who learn how to program by making games?
No, luckily it isn't. Some people (including me) would write the code first and start to think about any possible improvements much later. I'm unable to design anything without an existing code. It's just like sculpting, you can't create a sculpture out of nothing. Bad code is not necessarily a bad thing - it might as well be a raw block of stone that needs further efforts to become a masterpiece. I think that many programmers are missing this point.
I think this is true when it comes to implementing rules and gameplay- but honestly, there are a lot of important things that you don't need to do this with. Keeping rendering and logic separate becomes rote after you're taught that way or discover that porting to a new rendering framework is a PITA otherwise.
With a proper framework, you can have discrete state/session management that allows for replaying and saving functionality (and analytics), you can have cross-platform compatibility, interface with many renderers, and... well, the list goes on. If you don't have a proper framework and desire these features at some point, you're probably looking at a complete redesign. You can include test-driven development or any other preferred set of techniques if you set your boilerplate up that way- but they don't emerge from working on a project half-way through without a lot of avoidable problems.