by date
Plan for Jay Barnson
Plan for Jay Barnson
| Name: | Jay Barnson |  |
|---|---|---|
| Date Posted: | May 02, 2005 | |
| Rating: |  Not Rated | |
| Public: | YES | |
| Comments: | YES | |
| RSS Feed: |  or Subscribe with  . | |
| Profile Page: | View profile page for Jay Barnson |
Blog post
A day in the life of a part-time game programmer
This weekend was pretty typical (i.e. frustrating) for game development. In case anyone is unfamiliar with the process (or feels like empathizing), here's how things go far too often.
I was whipping together a new special-effect type object with some rather unusual behavior. I had the basic design "in my head," and it was time to code it up. What happened was, unfortunately, pretty typical.
First, I created a prototype object in the modeler, wiring it up with animation nodes, and exporting it into Torque. I created a new class for this object - a derivative of ShapeBase. Fortunately I have LOTS of ShapeBase derivatives at this point, some with similar behavior, so there's a lot of cut & pasting I can do to speed things up. In all, creating the object and coding it up with simplified "stand-in" behavior takes all of a couple of hours. I'm almost done, right? How hard can it be?
* I spend almost an hour trying to find out why it's not appearing at all, only to realize I forgot to initialize the correct matrix.
* I found out I named the joints incorrectly in the modeler, so the dynamically generated animation behavior isn't working right.
* I make two changes at once (rarely a good idea) - both to make the code more generic instead of a special-case "demo" of behavior. Somehow, this breaks the whole object, and I have to roll back BOTH changes to get things back to where they were before, and re-implement the behaviors step-by-step.
* I break something else, which wasn't noticeable before because I was still testing a single-specific situation. Turns out it's a problem with the server and client being out-of-sync, and the client is missing crucial bits of data to display the model's animation correctly.
* Math still isn't working - I realize that the model is STILL modeled incorrectly, and needs to be re-done. Again.
* Math still isn't working. I realize there's a problem with MathUtils::getAnglesFromVector - it's not calculating the pitch correctly for my purposes. I replace that code, and test it to make sure it's right. I can now guarantee it's returning the correct Euler angles - but the math is STILL not working out correctly, and I'm getting some wonky visuals.
* I try to avoid the problem entirely by creating three entirely new functions to skin the cat a whole different way. None of them work, and I've wasted a good three hours fussing on them. (Note: They still may be used, because they allow new general-purpose effects... which was the whole point).
* I finally realize that the weird, wonky behavior is something I've dealt with MANY times in the past (so I should REALLY KNOW BETTER), and it's related to the non-commutative properties of matrix multiplication. I've been using the default matrix-creation routine for so long I forgot that it might not work for some situations. I fix that, and finally everything comes together and the code appears pretty solid. Not pretty and polished, but solid.
One of the jokes of managing software development is that you should take your estimates, and then double them. And then double them again. Then you won't be too far behind schedule. It's very true - I had everything "basically" working in two hours, but the whole project actually took around eight. And I haven't done any polishing yet.
But hey, polishing shouldn't take too long. After all, I'm almost there... how much time could it take? :)
Jay Barnson
Rampant Games
I was whipping together a new special-effect type object with some rather unusual behavior. I had the basic design "in my head," and it was time to code it up. What happened was, unfortunately, pretty typical.
First, I created a prototype object in the modeler, wiring it up with animation nodes, and exporting it into Torque. I created a new class for this object - a derivative of ShapeBase. Fortunately I have LOTS of ShapeBase derivatives at this point, some with similar behavior, so there's a lot of cut & pasting I can do to speed things up. In all, creating the object and coding it up with simplified "stand-in" behavior takes all of a couple of hours. I'm almost done, right? How hard can it be?
* I spend almost an hour trying to find out why it's not appearing at all, only to realize I forgot to initialize the correct matrix.
* I found out I named the joints incorrectly in the modeler, so the dynamically generated animation behavior isn't working right.
* I make two changes at once (rarely a good idea) - both to make the code more generic instead of a special-case "demo" of behavior. Somehow, this breaks the whole object, and I have to roll back BOTH changes to get things back to where they were before, and re-implement the behaviors step-by-step.
* I break something else, which wasn't noticeable before because I was still testing a single-specific situation. Turns out it's a problem with the server and client being out-of-sync, and the client is missing crucial bits of data to display the model's animation correctly.
* Math still isn't working - I realize that the model is STILL modeled incorrectly, and needs to be re-done. Again.
* Math still isn't working. I realize there's a problem with MathUtils::getAnglesFromVector - it's not calculating the pitch correctly for my purposes. I replace that code, and test it to make sure it's right. I can now guarantee it's returning the correct Euler angles - but the math is STILL not working out correctly, and I'm getting some wonky visuals.
* I try to avoid the problem entirely by creating three entirely new functions to skin the cat a whole different way. None of them work, and I've wasted a good three hours fussing on them. (Note: They still may be used, because they allow new general-purpose effects... which was the whole point).
* I finally realize that the weird, wonky behavior is something I've dealt with MANY times in the past (so I should REALLY KNOW BETTER), and it's related to the non-commutative properties of matrix multiplication. I've been using the default matrix-creation routine for so long I forgot that it might not work for some situations. I fix that, and finally everything comes together and the code appears pretty solid. Not pretty and polished, but solid.
One of the jokes of managing software development is that you should take your estimates, and then double them. And then double them again. Then you won't be too far behind schedule. It's very true - I had everything "basically" working in two hours, but the whole project actually took around eight. And I haven't done any polishing yet.
But hey, polishing shouldn't take too long. After all, I'm almost there... how much time could it take? :)
Jay Barnson
Rampant Games
Recent Blog Posts
| List: | 04/30/08 - Frayed Knights Pilot Episode Now Available 03/28/08 - Frayed Knights - The Interview! 03/17/08 - The Future of Indie RPGs 02/27/08 - Frayed Knights, Late Nights 02/11/08 - Why Indie RPGs? Indies of the Round Table #1 01/30/08 - Frayed Knights: Beware the Priests of the Pus God! 12/31/07 - Frayed Knights Development - Frayed Nerves! 12/13/07 - Indie RPG News Roundup - December 13th |
|---|
Submit your own resources!| Jeremy Alessi (May 02, 2005 at 08:09 GMT) |
| Davis Ray Sickmon, Jr (May 02, 2005 at 08:12 GMT) |
| Drew Parker (May 02, 2005 at 12:21 GMT) |
Lately, in my planning I'm assuming implementing any small feature will take a day. If all goes well, it might take 2 hours, but if I have one of the moments like your plan, it could take way longer. So I just tell myself it will take a day (and sometimes it can when things DO go well, with debugging, multiplayer testing, and CVS). That way, if I finish it sooner, I'll be ahead of the game. :) Of course, some days I knock out lots of things, which is also good! But sometimes you just get stumped.
And it can be especially hard to know how long something takes when you haven't done it before. If it's something you've done lots of times before, it's easier to say it won't take as long.
I spent about a day trying to get a new mode for the Advanced Camera interpolating smoothly, and it all boiled down to the fact that I thought the interpolateTick () dt var was similiar to the advanceTime () dt. After tracing through tons of code and documenting it all, I can now declare they are not, and needless to say I'll never make that mistake again. :)
| Tom Bampton (May 02, 2005 at 13:24 GMT) |
Quote:
One of the jokes of managing software development is that you should take your estimates, and then double them. And then double them again. Then you won't be too far behind schedule. It's very true - I had everything "basically" working in two hours, but the whole project actually took around eight. And I haven't done any polishing yet.
Damn right! My last estimate was about 2 weeks, which I doubled to a month. Forgot to double again, though, and it's been about 5 months so far ;-) OK, so a large part of that time I was totally burnt out else it would of been quicker, but still, I completely suck at estimating time ;-)
In the past couple of years I've taken to spending as much time as neccessary just thinking about the code before I even touch a computer. Sometimes this process takes a couple of weeks but it's always worth it ... the end result is always so much better.
Other good "tricks" are to write the code that uses the new API before writing the API itself and documenting it before writing it. A combination of the two helps me think through the code and where the issues are going to lay, as well as better solutions to the problem.
Quote:
But hey, polishing shouldn't take too long. Afte all, I'm almost there... how much time could it take? :)
Four months minimum. Then another couple of months to actually ship it. Last 10%, etc ;-)
T.
| Martin Mc (May 03, 2005 at 23:50 GMT) |
Never quote your boss less than a day for any task. No matter how trivial. You will need the time later
I learned this one early on and it's seen me in good stead
:->
You must be a member and be logged in to either append comments or rate this resource.
