Allegro.cc - Online Community

Allegro.cc Forums » Game Design & Concepts » Project Planning / Management

This thread is locked; no one can reply to it. rss feed Print
 1   2   3 
Project Planning / Management
alehbeer
Member #12,996
July 2011
avatar

Hey allegro peoplez!
I was wondering what you guys and girls use for planning out a programming project. Books/webpages read, self-established routines, software, etc. For example, lets say you were asked to make a game engine, how might you draw that out on a chalkboard to make programming it easier and manageable? I know this is a fairly open-ended question but any thoughts and comments would be appreciated.

l j
Member #10,584
January 2009
avatar

I do it like this:

Start programming whatever comes up in my mind.
One flaw in the design.
Scrap and start all over again.

This method has never failed me!

I never actually finished any project in my entire life.

Yodhe23
Member #8,726
June 2007

Copy programme I like with features I thought would be cool not in original...

Write code with only a vague, i'll figure it out as I go along approach.

Polish turd until reflection is obtained.

.......
What I should of done....

Get good education (mathematics degree), and well paying job preferably with a merchant banking company.

Pay some code monkey to design the game I want.

Blame code monkey for not writing the new Doom in 2 months from scratch, and
compling with my constant changing designs every week/day/hour/sec.

Pay a PR company to pass of the incomplete game as an innovative ground breaking interactive new media piece of digital fiction. Get you mates at the merchant banking company to package up your company as a barely legal assest stripped paper company and flog it some investors claiming it to be the new Zynga/EA whatever.

Take money and run, spend life on beach with piles of money, and all the earthly delights that can be obtained with it.

.................................

Can you guess which route I took?

www.justanotherturn.com

verthex
Member #11,340
September 2009
avatar

If you want to get really technical there is MS Project.

jmasterx
Member #11,410
October 2009

Use MS-Project to organize your code monkey(s).

Make flow charts of algorithms, methods, classes.
Make Data Flow Diagrams of entities and functions in the game.
Make Entity Relationship Diagrams to know how many instances of things each thing should have.

Make a design manual and strictly stick to it; Don't find yourself half done and say "ouuuu that would be such a cool feature to add!". DNF tried that and we all know how that turned out :O .

If you have several code monkeys, be sure to get high quality leather for the glove you use to smack them when they tell you your deadlines are "unattainable".

If you are the only monkey, then do whatever is necessary to stay motivated, agile, and productive (booze, women, coffee, games)

If you follow these guidelines you should have no trouble dishing out the next $BEST_SELLING_GAME in $REASONABLE_TIME !

Good Luck!

Tobias Dammers
Member #2,604
August 2002
avatar

Phase 1: Think. A lot.
Phase 2: Write between one and 20 prototypes. Abandon them all.
Phase 3 (happens spontaneously): One of the prototypes gains critical mass. Add it to source control (if I haven't already). Gradually massage it into shape, ruthlessly refactoring as early as possible.
Phase 4: Project grows too complex for me to keep all issues and nice-to-haves in my head. At this point, I set up a text file (yes, a f**ing plain text file) which I use to dump all to-do's. I add this text file to source control and keep it up-to-date. This way, whenever I have time to work on the thing, I have an abundance of things to do.

---
Me make music: Triofobie
---
"We need Tobias and his awesome trombone, too." - Johan Halmén

Trezker
Member #1,739
December 2001
avatar

My process lately is that I start the project, coding along happily.
If the project doesn't die in a week or so I put it up on github.
Then I use githubs issues instead of having a todo document.
I also use their wiki for design and documentation pages.

I don't try to plan out the entire project ahead of time.
I write down any ideas as soon as possible just to keep a clear head.

As for code design I try to think ahead to avoid future refactoring that I know I'd probably have to do later anyway, this part requires experience so don't sweat it much. If it turns out you didn't predict the needs it just means you have to refactor more often than more experienced programmers.

james_lohr
Member #1,947
February 2002

I like to keep a collection of design documents:

1) What I plan to do
2) What I've already done which isn't immediately obvious from looking at the code
3) What I should do regarding reuse and extension of what I've done
4) What I shouldn't do regarding reuse and extension (e.g. possible pitfalls)

And the final step is to break up with your girlfriend so that you can code in peace. :P

ImLeftFooted
Member #3,935
October 2003
avatar

I've always like the saying "build enough tools and the project builds itself."

But that doesn't help with prioritization. For that I have a moleskin notebook where I write everything. Typically a page is some goal of the project and a todo list of items to get that goal completed. I may or may not complete the goal depending on what I decide, but I write everything down.

When I'm getting ready to work I map out the goal for this session on a whiteboard and think really hard about it. After thinking really hard most of the code is finished and it just needs to be dumped out of my head and into a computer. I keep a todo list on the whiteboard so I don't miss anything and for that gratifying stroke marking each as done.

Tobias Dammers
Member #2,604
August 2002
avatar

Trezker said:

If it turns out you didn't predict the needs it just means you have to refactor more often than more experienced programmers.

I find that the more experienced I get, the more time I spend refactoring.

---
Me make music: Triofobie
---
"We need Tobias and his awesome trombone, too." - Johan Halmén

Trezker
Member #1,739
December 2001
avatar

I think that may be because unexperienced programmers don't know much about refactoring so they ugly hack their way into an unmaintainable corner.

It's pure chance if you run into an unmanagable or 'finished' state first. ;)

james_lohr
Member #1,947
February 2002

I think it's a necessary process, and all programmers must go through this repeatedly both to develop the problem solving skills necessary to be able to debug other people's code, and to fully appreciate the importance of design and best practices.

When I look back at the hideous code I used to write, I'm actually astounded at how much I managed to complete and how much "brute-force" thought I must have thrown at my projects to follow the spaghetti code I used to write.

Now that I'm a more experienced programmer, it feels like most of my effort is concentrated on thinking about what is the cleanest way to do something, and how best to refactor existing code so that it is consistent with whatever addition I am making.

Tobias Dammers
Member #2,604
August 2002
avatar

Trezker said:

I think that may be because unexperienced programmers don't know much about refactoring so they ugly hack their way into an unmaintainable corner.

I think that it's because inexperienced programmers often misjudge the complexity of the thing they are currently working on, and their ability to make sense of it later. Additionally, if you aren't using source control yet, refactoring is a dangerous thing.

When I look back at the hideous code I used to write, I'm actually astounded at how much I managed to complete and how much "brute-force" thought I must have thrown at my projects to follow the spaghetti code I used to write.

Same here, and I think it's the same for everyone. My old code, however, also often suffers from over-engineering, trying to be too clever. Sometimes, I'd write a whole framework which I would then use once, not even touching half of what it could do. These days, my approach is more like start with a pragmatic solution that works for one case, and then gradually refactor it into something more generic.

---
Me make music: Triofobie
---
"We need Tobias and his awesome trombone, too." - Johan Halmén

tobing
Member #5,213
November 2004
avatar

1. Use source control. Like svn or git.
2. Use a design document, or at least a todo list, like this:
http://www.abstractspoon.com/tdl_resources.html
Really great tool for prioritizing task, dividing tasks into subtasks until they become manageable, and keeping track of efforts and times (optional).
3. Use a good IDE, like MS Visual C++ Express on Windows or the Eclipse C++ package on linux. Get used to the debugger.

As for refactoring and writing re-usable code: I always have the main project and a number of libraries, one of them is my own tools and whatever library. Then I start to code on the main project, and whenever I find something which is needed in another project or seems to be re-usable, I move that stuff into my library, where I can put it in shape.

bamccaig
Member #7,536
July 2006
avatar

  • Think about the project from a high-level perspective.

    • What "business"[1] entities exist?

    • What logical entities will be useful to glue the business ends together?

    • Try to imagine how you might modularize the application.

  • Focus on one thing at a time and try to keep it simple (but safe and reliable).

  • Insist upon good design practices: data encapsulation, dependency injection, least privilege, etc.

  • Refactor the code as soon as you add more paint to the picture.

    • Assume there's always a better way.

    • Automate as much as possible. You're human and therefore prone to error. Let the computer do as much as possible for you.

  • Record your thoughts in plain text; in comments, in TODOs, in READMEs, and document all good and bad practices within the project, and highlight questionable areas or ideas.

References

  1. I don't mean "business" in the goods/services-for-money sense. Pac-man would be an example of such an entity in a Pac-man game.
Mordredd
Member #5,291
December 2004
avatar

Cough

tobing said:

3. Use a good IDE, like MS Visual C++ Express on Windows or the Eclipse C++ package on linux

{"name":"58199d1294879461-kennt-wayne-double-facepalm.jpg","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/7\/e\/7e5689b14e4c3c964f23a68b2f9f5a33.jpg","w":350,"h":280,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/7\/e\/7e5689b14e4c3c964f23a68b2f9f5a33"}58199d1294879461-kennt-wayne-double-facepalm.jpg

GullRaDriel
Member #3,861
September 2003
avatar

That one made my day ^^

"Code is like shit - it only smells if it is not yours"
Allegro Wiki, full of examples and articles !!

tobing
Member #5,213
November 2004
avatar

The (de)motivator is a nice one. ;D

I don't see how that relates to my 3. above, though... ???

james_lohr
Member #1,947
February 2002

tobing said:

I don't see how that relates to my 3. above, though...

I guess some inexperienced programmers think that sophisticated IDEs like Netbeans, Eclipse and Visual Studio are bad. :P

Arthur Kalliokoski
Second in Command
February 2005
avatar

They're not bad, per se, but they have little to do with project planning/management. It's like saying the decor of the CEOs office affects his performance (well it might if he's a touchy-feely type).

They all watch too much MSNBC... they get ideas.

tobing
Member #5,213
November 2004
avatar

I would say that the choice of platform and development tools does have a significant impact on your project. For small projects it might not seem too relevant, but if you have to work on some 100000 lines of code it does make a difference if you have a good IDE and debugger or not. :P

Tobias Dammers
Member #2,604
August 2002
avatar

I guess some inexperienced programmers think that sophisticated IDEs like Netbeans, Eclipse and Visual Studio are bad.

They're not bad, per se, but it seems that many inexperienced programmers can't code their way out of a wet paper bag without one. As with any other tool: if you can program, sophisticated tools can make for a significant productivity boost, but if you can't, no tool in the world is going to help you much.

tobing said:

I would say that the choice of platform and development tools does have a significant impact on your project. For small projects it might not seem too relevant, but if you have to work on some 100000 lines of code it does make a difference if you have a good IDE and debugger or not.

If you have to work on a 100k line project, and you can't do it without an IDE, then I'd consider the project broken. There is no excuse for lack of structure, encapsulation, and documentation, and if those three are good enough, I can easily manage a million LOC and more using just vim, grep, find, and a web browser to navigate the documentation.

---
Me make music: Triofobie
---
"We need Tobias and his awesome trombone, too." - Johan Halmén

Arthur Kalliokoski
Second in Command
February 2005
avatar

I'm "debugging" a prog that uses signals, and strace(1) is about the only way to find out what's happening in real time. No IDE can replace that.

They all watch too much MSNBC... they get ideas.

tobing
Member #5,213
November 2004
avatar

I have been working on an about 2 million loc project, and am now involved in a 7+ million loc project. Even if I could do some work using a simple text editor and find stuff using grep, why should I? When I have tools like eclipse or the Visual Studio with Visual Assist around the corner? It just doesn't make sense to not use good tools when you have them.

It also doesn't matter if the project is considered broken or not: we build a product from these sources which is sold to customers. They want features and support in case of problems, and they don't care about the code structure - we, the developers, do that. We try to keep the stuff nice and clean, but it turns out that whatever you do, code tends to get dirty or outright ugly after some years (and some releases and a lot of added features, all without breaking existing functionality).

Debugging using a debugger is only one of several tools to find bugs. Trace is another one, and sometimes you find nasty bugs using traces, sometimes you find them using the debugger and breakpoints. Sometimes you find bugs using assertions in your code, and so on. It's always a matter of knowing the tools and using them as appropriate.

Just this morning we understood a race condition, which we have seen every few weeks, since months, but only this crash (due to an assert in the code) had all callstacks involved and much more information we built in, so we finally understood what really happened and can now think about a solution.

bamccaig
Member #7,536
July 2006
avatar

tobing said:

I have been working on an about 2 million loc project, and am now involved in a 7+ million loc project. Even if I could do some work using a simple text editor and find stuff using grep, why should I? When I have tools like eclipse or the Visual Studio with Visual Assist around the corner? It just doesn't make sense to not use good tools when you have them.

The important word in IDE is "integrated". That's the problem with GUI tools. They can't talk to each other easily. No such interface exists. So every GUI tool tries to do everything itself and none of them do anything well.

There are certainly cases where an integrated environment is useful. For example, debugging in a graphical editor that can highlight the current line, evaluate expressions under the mouse, etc., can be quite nice. However, graphical tools, and especially integrated environments, do a lot of other things very poorly.

Personally, I do most of my work on the command line whenever I can. When I'm stuck using Visual Studio (I personally hate it) Alt+T+V launches the current code file in gVim for me. I use a graphical browser, and a text-browser isn't really a substitute in the current world of funny images and videos, but that's the only GUI application that I care to use (well, and if I ever have to view or manipulate graphics)...

I can type a command list much faster than I can navigate a graphical menu system.

 1   2   3 


Go to: