Code Design Methods

[Labman]

Working on a prototype game engine, the code was getting messy and I started doing some redesign using UML as I have recently been doing some high level design at work in UML and found it helpful for orginising thoughts.

I was wondering what other people were using to do code design to help with code organisation, what do you use?

[mh]

Pen and paper.

I have tried various CASE tools (and other things) in the past, and generally find that they have imposed their own policy a little too much. I work better with pen and paper; boxes, squiggly lines and arrows.

[frag.machine]

Lately I've been studying design patterns for professional needs, but it's amazing how some of these patterns fits nicely in game design too, to the point I am considering to use OO to build a game engine.

[Labman]

Lots of singleton use

I tried using pen and paper and it can be good for sketching out some new code, but I can quickly get out of date and is hard to bring up to date without recreating what you have done.

[frag.machine]

Lots of singleton use

Or abstract factories for game entities!

Code: Select all

Entity ent =EntityFactory.getInstance().newMonster ("ogre");

[lth]

For games you're working on at home yourself, I find that thinking too hard about the structure gets in the way of having fun - I work all day as a software engineer so I don't really want to come home and make sure that my mod is completely MVC and tidily using well-commented code. I just can't be bothered!

Of course, if you're serious about what you're doing then having a good understanding of design patterns is important but I'd say that one of the most important parts of understanding design is when *not* to do it. I've seen an awful lot of over-engineered systems that have clearly been built by pattern fanatics who've had to add extra patterns to span the gap between their favourite patterns and you end up with a horrible patterny mess when what was really required was sticking to a few core architectural features and then not being above using glue, nails and sticky tape to bridge the gaps!

[Wazat]

Probably more often than I should, I just get a good idea of what I want to do into my head and start coding. UML is useful for some people, but it's a big slowdown for me that doesn't help me much. Frankly, it's when I actually get into the code that I realize what I forgot in my planning, and that often changes the design quite a bit. I code a little, revise my design, and then get into the serious implementing. Occasionally I jot down some notes and minor diagrams, but these are throwaways that are just there to help me along. I won't update them.

One strategy that has helped me though is commenting a header file before writing it, and commenting functions before filling them with code. On occasion I need to do that to wrap my head around a problem and get it planned out before I write a bunch of code that I'll have to rewrite later unless I think about it first. One big advantage of this is those comments serve a dual purpose, both planning and documenting. When you come back later and need to remember how a function works, or someone else comes along to make modifications, your planning comments are there. You update the comments as things change because they're the code comments, so they remain useful throughout the development process.

Everyone has different tastes, and different tasks call for different tools anyway. I don't often build huge architectures from scratch. I'm a feature developer and modder. I take an existing application and add components. UML and other planning strategies are probably much, much more helpful when planning an entire system from a high-level view, instead of individual features that link into the existing system.

I suspect that UML etc, when it is kept rigorously up to date, is also useful for a newcomer who needs to know how the system is laid out without tracing through the code line-by-line ("Wait, how does feature x get its information over to feature y? And when does widget Z get used?").

Edit: BTW lth, I envy people who continue to develop at home. Good thing to do!

[frag.machine]

For games you're working on at home yourself, I find that thinking too hard about the structure gets in the way of having fun - I work all day as a software engineer so I don't really want to come home and make sure that my mod is completely MVC and tidily using well-commented code. I just can't be bothered!

Of course, if you're serious about what you're doing then having a good understanding of design patterns is important but I'd say that one of the most important parts of understanding design is when *not* to do it. I've seen an awful lot of over-engineered systems that have clearly been built by pattern fanatics who've had to add extra patterns to span the gap between their favourite patterns and you end up with a horrible patterny mess when what was really required was sticking to a few core architectural features and then not being above using glue, nails and sticky tape to bridge the gaps!

Yup, I could not have said that better. While design patterns can help you a lot, when they start to get in your way while you're trying to do basic things it's time to reconsider what you're doing. As everything in the life, extremes (either excess or no patterns at all) should be avoided.

[Wazat]

Yup, I could not have said that better. While design patterns can help you a lot, when they start to get in your way while you're trying to do basic things it's time to reconsider what you're doing. As everything in the life, extremes (either excess or no patterns at all) should be avoided.

I agree with both of you. A little can be helpful in the right situation, but too much designing or designing the wrong things will have the opposite effect, bogging you down instead of helping you along. I've actually worked at a place where pathological planning may have been part of its downfall.

[Labman]

I totally agree with not doing UML etc for feature adding to already existing systems, esp if they don't have anything like that to start with as you would have to model a lot of code that already exists bogging you down.

I also agree that over planning isn't a good idea. Currently I'm only planning ahead for the current and next iteration of my project, if it's not planned for the next couple of iterations, its not a requirement yet. It's much easier to redesign code once you know exactly what it's going to do rather than planning a long way ahead. Unless you are doing comprehensive design, and who wants to do that in their spare time anyway?

[Team Xlink]

Yup, I could not have said that better. While design patterns can help you a lot, when they start to get in your way while you're trying to do basic things it's time to reconsider what you're doing. As everything in the life, extremes (either excess or no patterns at all) should be avoided.

I agree with both of you. A little can be helpful in the right situation, but too much designing or designing the wrong things will have the opposite effect, bogging you down instead of helping you along. I've actually worked at a place where pathological planning may have been part of its downfall.

I agree with all three of you.

Depending on what I want to do I usually have it thought out in my head on how it is going to work and I start coding.

Here is a coding process that commonly happens to me:

1. Have an idea
2. Figure out how to make the idea work
3. Code in your idea that works
4. Look back on the sloppy code you have done
5. Fix it up.
6. Refer to step 4 and Step 5

[Wazat]

I'm about the same, Xlink. However, there's a lot of good to be said about planning complex things out enough that you write reasonably good code the first time around. This creates cleaner systems overall that are less burdened by vestigial or inefficient bits of code, and they're better organized and more readable. It can also be much faster to code this way because there's less cleanup and starting over... depending on what you're doing.

Having coded both ways, I can understand someone justifying either method. You just have to weigh the pros and cons and see which method fits your situation, needs and style the best.

[Wazat]

I would just like to point out that today's dilbert tackles, and answers, this very issue.

[Junrall]

Once in a while I like to use a simple flowchart with yes, no, and loops.... then let the code fly where it may land!

[Teiman]

Another think interesting could be something like "Doxygen" or "phpDoc" for QuakeC. Only not... because only a few people will document his code that way.