#17864 - xadeu - Tue Mar 16, 2004 5:00 am
Hello all,
I am just getting started with GBA Programming (and game programming in general) although I have several years of C++ coding under my belt.
I need advice as to how to accomplish my goals as a game developer. I am going to start out with small demos and work my way up to games like Pong then Tetris then Breakout then Pac Man and so on in complexity.
Should I set time goals on getting these projects done? For instance, should I code 2 hours a day at least on this stuff. (I am a busy person and have other stuff to do too...so I can't code all day long)
What techniques do those of you that have completed a game or two have in mind?
Any Suggestions?
Thanks,
Xadeu
#17866 - ScottLininger - Tue Mar 16, 2004 5:12 am
Xadeu,
I recommend getting obsessed with your GB project until you're done with it. Work whenever you can until it's done, then relax and take a few weeks off until the next project tickles your fancy. ;)
Seriously, if you accidentally wait too long between programming sessions, you may find it harder to pick up where you dropped it. Much better to finish a game in a quick and dirty manner than go after that perfect game that never gets finished. You can always release version 2.0 with all the bells and whistles.
I'm also super-busy with work and family and friends and freelance jobs, but I find that obsession works great for me. :)
Of course, none of us are you. Sounds like you have a perfect strategy... It's now up to you to figure out the tactics...
Welcome aboard! I look forward to seeing your games as you finish them.
#17868 - poslundc - Tue Mar 16, 2004 5:56 am
| ScottLininger wrote: |
| Seriously, if you accidentally wait too long between programming sessions, you may find it harder to pick up where you dropped it. |
This is where a clean, consistent coding style and proper documentation can make all of the difference. I've been able to easily pick up on projects that have been dormant for months (or even longer) when I've properly documented my work.
| Quote: |
| Much better to finish a game in a quick and dirty manner than go after that perfect game that never gets finished. |
While I agree that achievable goals are definitely the way to go, I object to the notion of it being a better thing to finish a game in a "quick and dirty manner". It maybe takes 10% longer to write a clean and organized program instead of a quick hack, and the more often you do it this way the less time and effort it takes in future project. Furthermore, you'll save tons of time when it comes around to creating v2.0 with all of the bells and whistles if you made v1.0 properly. Otherwise, you may find yourself spending 90% of your time remaking 1.0 into what it should have been in the first place.
Dan.
#17872 - ScottLininger - Tue Mar 16, 2004 7:52 am
| Quote: |
| This is where a clean, consistent coding style and proper documentation can make all of the difference. I've been able to easily pick up on projects that have been dormant for months (or even longer) when I've properly documented my work. |
I agree. Absolutely.
| Quote: |
| While I agree that achievable goals are definitely the way to go, I object to the notion of it being a better thing to finish a game in a "quick and dirty manner". |
When you're learning a totally new technology, you're NOT going to get it right the first time. I say code away! When we're talking Pong, we're talking a hundred lines of code. The danger in waiting too long between programming sessions isn't that your code will be illegible, it's that you'll get bored and never pick it up to finish it.
Dan, I see your point about proper code hygeine, but I contend that it is better to finish a project sloppily than to finish it never. Especially when you're just starting out, and especially when it's a hobby project where you are the only developer. For your first game, I say "if it works, it's coded properly."
Or to put it another way, it is better to be imperfectly successful than perfectly unsuccessful. ;)
#17881 - poslundc - Tue Mar 16, 2004 2:50 pm
| ScottLininger wrote: |
| Dan, I see your point about proper code hygeine, but I contend that it is better to finish a project sloppily than to finish it never. |
You don't necessarily need to know the "correct" way to do everything. When I started out GBA programming, I was putting all of my ROM data in header files. And why not? Pern told me to do so, as well as virtually every other source on GBA programming. But my code was clean, consistent and modular, so when the header files started to create problems I was able to switch over to using proper object files infinitely easier than if I had been spaghetti-coding.
| Quote: |
| Or to put it another way, it is better to be imperfectly successful than perfectly unsuccessful. ;) |
It is naive to believe that sloppy coding will lead you to any level of success that you can't just as easily achieve with clean, careful, well-thought-out coding. More often than not, sloppy coding leads people to writing code with bugs in it that they cannot track down, especially when they are new to the GBA. (Which they then post on the forum with complaints that it doesn't work and they don't know why.)
Dan.
#17889 - sajiimori - Tue Mar 16, 2004 6:09 pm
I agree with Scott in theory, and with Dan in practice. (You'd think it would be the other way around...)
As a natural perfectionist, it takes dicipline to not get overly attached to my code. I'd actually like to be able to write more throw-away code, because I know I won't get it right on the first attempt, but I spend a lot of time trying anyway. Sometimes it seems like the time it takes to make one version of a program could have been used to make two versions, with one to throw away (and possibly a better finished product).
For many people, it takes dicipline to spend enough time on making good code. Bad code in a growing project is like mud in a swimming pool. The going gets more and more difficult, until you can hardly trudge to the other side, for all the muck you have to wade through just to do the simplest tasks.
Where to focus your attention depends on what your weaknesses are. Mine is overattachment, but for some it's impatience.
#17941 - johnny_north - Wed Mar 17, 2004 9:14 pm
It is always possible to jam a square peg through a round hole given a large enough hammer.
Round hole = a well intergrated solution.
Square peg = code gone bad.
Large hammer = your time, frustration, money.
Starting out, you'll often not know the fastest / neatest / cleverest way to do something and you'll often settle for the first thing that comes to mind (which i find to almost never be the best way - see here for a perfect example set by yours truly:
http://forum.gbadev.org/viewtopic.php?t=2729&start=0&postdays=0&postorder=asc&highlight=).
When you get to creating function/struct/class that you know plays an important roll, it's a good time to spend more time planning, asking questions, exploring all the possible needs etc. Same applies if you find yourself bandaging a piece of code that needs to take on more functionallity - probably a good time to rethink you original approach and rewrite. Continuing to patch code can create a mess.
#17965 - sajiimori - Wed Mar 17, 2004 11:12 pm
Shouldn't "round hole" = "the problem to be solved"? :-P
#17966 - Miked0801 - Wed Mar 17, 2004 11:13 pm
Coding. Pay a little now to keep things readable, legible, and nice looking - or give your soul to your job at Alpha/Beta/Final trying to find that last little crash bug that only happens 1 in 10,000 times.
I prefer the former as I've had too much experience with the latter... :)