Sunday, March 30, 2008

Scene graph! Of course!

I've been so blind. The idea of using a scene graph for two-dimensional graphics never got into my skull until earlier this month. It's been around for quite some time, but I never made the connection myself. Scene graphs are used all the time in three-dimensional gaming, but for 2D apps, it looks like it is used, but not as much as it can be.

This Scene graph article on GameDev does a pretty good job at explaining why they are so cool.

I was originally going to put a long paragraph here on all the examples of how it could benefit us, but I've forgotten what they were. Just remember that at one time I thought they were really useful.

The End.

Thursday, March 27, 2008

Ubuntu 8.04 and Eclipse something

So as summer comes I don't know what I will be doing but I do know some nice releases are on the way. Ubuntu 8.04 is almost out and the eclipse platform comes in June. Both these projects are on a regular release schedule. I like that. I don't know how they pull it off because it seems like my projects don't ever get done on time. Anyway if the openGL 3.0 standard came out this summer to life would be great. I don't know if I will ever use it but I would like to think I will.

Wednesday, March 19, 2008

A Postmortem of Game Programming with Digital Mars’ D Programming Language

http://www.gamedev.net/reference/programming/features/dmarsd/default.asp has many useful links relating to the Digital Mars D Programming Language. It outlines his experience with it, some features he liked, and some problems he ran into. One thing I didn't know about, for example, was that the documentation generator was built right into the compiler itself. Good to know!

Sunday, March 16, 2008

My New Time Management Plan

For the past two months I've been involved with the two prime games at Pezad: Entrippy and unnamed platformer. Here is how I will devote my time between both now:
  • I will alternate each month.
It might be too convoluted for me to attempt comprehension of this plan though, but as long as I remember that unnamed platformer will take my "hobby programming time" every January, March, May, July, September, and November, and Entrippy will take February, April, June, August, October, December, I'll be fine. I decided upon months as the time frame because months are coarse enough that I can create a deadline for at least one or two components at a time, but not so coarse, I hope, that it wouldn't feel like I was abandoning one project over another, and not so fine that I wouldn't be able to get anything useful done.

There are bound to be a few "thought overruns" where I need to finish up a few loose ends in one project but the month is over. To mitigate this, a secondary part of the plan is this:
  • I will not schedule any programming tasks to initially take more than two weeks.
  • Each programming task must be broken down into sub-tasks which take no longer than two days each.
The scheduling problem will still occur, no doubt, but as long as it can prevent some train wreck of a schedule overrun that spans two months or more, I'll consider it a success.

But why two weeks, you ask? Well, I think I read it in Rapid Development somewhere. It is also brought up in Game Coding Complete, probably (I read the first edition though) . The same goes for the two days thing. The idea being, if I wasn't able to break the task into such small parts, then I probably didn't have it well-defined to begin with.

However, one of the benefits of the two-day maximum rule doesn't apply in the hobby off-hours work I'm doing at Pezad. With a two-day maximum specified for each task, the programmer can easily see if he was falling behind schedule, and could work some overtime to bring it back in line. If this wouldn't be enough time, the programmer would re-adjust the schedule (probably no more than a few days) and notify the manager. The estimate would be brought back in line, communication takes place, and all interested parties stay informed.

...The beauty part of the "one-or-two day sub-tasks" plan is that if the programmer finished early for the day, he goes home early. Why start on a sub-task when he wouldn't be able to finish it in the couple of hours he had? It all balances out: a little overtime here, a little relaxation time there. At least in theory.

I can't do that here though. If I drift into overtime working on these games, I drift into interfering with my sleeping goodness, and I need sleep so I can operate at work the next day. So, that's why the "initially take two weeks" is phrased the way it is, and it can extend into later the month if need be.