Code Design Methods
Code Design Methods
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?
I was wondering what other people were using to do code design to help with code organisation, what do you use?
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.
![Laughing :lol:](./images/smilies/icon_laughing.gif)
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.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
We knew the words, we knew the score, we knew what we were fighting for
-
- Posts: 2126
- Joined: Sat Nov 25, 2006 1:49 pm
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.
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC
(LordHavoc)
![Smile :)](./images/smilies/icon_smile.gif)
-
- Posts: 2126
- Joined: Sat Nov 25, 2006 1:49 pm
Or abstract factories for game entities!Labman wrote:Lots of singleton use
![Big Grin :D](./images/smilies/icon_biggrin.gif)
Code: Select all
Entity ent =EntityFactory.getInstance().newMonster ("ogre");
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC
(LordHavoc)
![Smile :)](./images/smilies/icon_smile.gif)
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!
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!
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!
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!
When my computer inevitably explodes and kills me, my cat inherits everything I own. He may be the only one capable of continuing my work.
-
- Posts: 2126
- Joined: Sat Nov 25, 2006 1:49 pm
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.lth wrote: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!
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC
(LordHavoc)
![Smile :)](./images/smilies/icon_smile.gif)
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.frag.machine wrote: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.
When my computer inevitably explodes and kills me, my cat inherits everything I own. He may be the only one capable of continuing my work.
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?
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?
-
- Posts: 368
- Joined: Thu Jun 25, 2009 4:45 am
- Location: Michigan
Wazat wrote: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.frag.machine wrote: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 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
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.
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.
When my computer inevitably explodes and kills me, my cat inherits everything I own. He may be the only one capable of continuing my work.
I would just like to point out that today's dilbert tackles, and answers, this very issue. ![Wink ;)](./images/smilies/icon_wink.gif)
![Wink ;)](./images/smilies/icon_wink.gif)
When my computer inevitably explodes and kills me, my cat inherits everything I own. He may be the only one capable of continuing my work.