GBA games: Building from the blueprints (project planning discussion)
Author
Okay... so, a lot of us are thinking about making a GBA game, or at least a technical demo. We''ve spent some time learning about the code and have started learning how to put things together.
How do you put it all together? What are some of the coding styles and methodologies that you guys and gals have learned about?
I''ve heard of a few myself, and in college, I learned about project planning and risk management. Sure, they sound like big words right now, but as you grow and become a better programmer, you will still need to learn how to be a good project manager.
Seriously - what have you all benefited from (or wish you never spent time dealing with) in the course of all your programming and projects?
With project planning and risk management (and other related topics), a fair to considerable amount of time is spent laying out the plans for a programming project. A lot of effort is spent at the beginning to define what the project is about and getting it moving. But at the same time, all this pays off when you need to remember specific reasons why a piece of code is so necessary (i.e. no other code can be substituted or used for it).
The golden payoff is a working program. But even failures are valuable too, if they are documented. Post-mortems are much more profitable if documentation and logs were kept of the project progress, so mistakes can be avoided.
Feedback?
-slippers2k
Attack life''s problems like a Subaru... with all four wheels
I would try and talk, but I am not that experienced yet. I have just started programming my snake game. As of coding style, I am just setting it up in functions, so I can call it in one big game loop. I''m hoping this thread can benefit me, so I can refine my project skills with others.
For the record, this is probably my first post ever in this forum. I haven''t done any GBA development, though I do have an interest (which I''ve been putting off) in giving it a shot, if only for the fun of it.
Beneficial:
Wish I''d never dealt with:
Nothing really. There are some things that I hardly ever do anymore (like developing 3d rendering engines, because there are so many freely available options to choose from, even if they need some tweaking), but the knowledge gained from having tried my hand at them in the past is certainly useful, both in general and in using them effectively.
Too true. Just don''t forget to document all the rationales, designs and so forth!
Now that''s one thing I''ve never done - maintaining a project log. In fact, you''ve just inspired me to look into developing software tools that integrate with the source repository and build tools to maintain an automatic change, build and defect log... Thanks!
quote:Original post by slippers2k
Seriously - what have you all benefited from (or wish you never spent time dealing with) in the course of all your programming and projects?
Beneficial:
- patterns and antipatterns
- development methodologies (favorite? the UNIX philosophy, which encompasses about 9 elements - see the book of the same name by Gancarz)
- leveraging existing tech
Wish I''d never dealt with:
Nothing really. There are some things that I hardly ever do anymore (like developing 3d rendering engines, because there are so many freely available options to choose from, even if they need some tweaking), but the knowledge gained from having tried my hand at them in the past is certainly useful, both in general and in using them effectively.
quote:With project planning and risk management (and other related topics), a fair to considerable amount of time is spent laying out the plans for a programming project. A lot of effort is spent at the beginning to define what the project is about and getting it moving. But at the same time, all this pays off when you need to remember specific reasons why a piece of code is so necessary (i.e. no other code can be substituted or used for it).
Too true. Just don''t forget to document all the rationales, designs and so forth!
quote:The golden payoff is a working program. But even failures are valuable too, if they are documented. Post-mortems are much more profitable if documentation and logs were kept of the project progress, so mistakes can be avoided.
Now that''s one thing I''ve never done - maintaining a project log. In fact, you''ve just inspired me to look into developing software tools that integrate with the source repository and build tools to maintain an automatic change, build and defect log... Thanks!
Author
What are risks and milestones that the console developer has to assess when considering a game project? Has anyone had experience or a postmortem from even a non-commercial console game project that has really taught them about programming?
When participating in my senior design class''s programming project, I was basically the project''s paperwork manager. I had designed presentations which discussed architecture and process flow for the program we were working on, a securities program under a GNU license. Some of the things we did in terms of paperwork involved keeping project minutes, creating presentations, and maintaining a website with the current updates of our situation. In terms of actual project management, we divided sections of the project up and communicated via email to keep on track of what was necessary. We convened in class to update ourselves as to what we were doing.
Looking back, a more vigorous manual documentation procedure would have at least given us a guide to accompany our program. The program was really designed with an experienced system admin in mind, but still - I suppose it would have given us more clarity while we were designing it too. We did not spend too much time calculating how many lines of code we should be cranking out per month either - while that did not cripple our output, it certainly could have helped tighten our brains to keep schedule.
Bottom line: for a project like my last one in college, documentation is life. It is the building block of understanding, and you need that when you are designing a program. How much of a role, then, does documentation, requirements analysis, and project planning play in planning a console game?
Thanks for your time.
-slippers2k
When participating in my senior design class''s programming project, I was basically the project''s paperwork manager. I had designed presentations which discussed architecture and process flow for the program we were working on, a securities program under a GNU license. Some of the things we did in terms of paperwork involved keeping project minutes, creating presentations, and maintaining a website with the current updates of our situation. In terms of actual project management, we divided sections of the project up and communicated via email to keep on track of what was necessary. We convened in class to update ourselves as to what we were doing.
Looking back, a more vigorous manual documentation procedure would have at least given us a guide to accompany our program. The program was really designed with an experienced system admin in mind, but still - I suppose it would have given us more clarity while we were designing it too. We did not spend too much time calculating how many lines of code we should be cranking out per month either - while that did not cripple our output, it certainly could have helped tighten our brains to keep schedule.
Bottom line: for a project like my last one in college, documentation is life. It is the building block of understanding, and you need that when you are designing a program. How much of a role, then, does documentation, requirements analysis, and project planning play in planning a console game?
Thanks for your time.
-slippers2k
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
