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.
Sunday, March 30, 2008
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:
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:
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.
- I will alternate each month.
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.
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.
Subscribe to:
Posts (Atom)