Some quick thoughts before bed...
by Jon Frisby · 04/18/2006 (12:34 am) · 0 comments
Most of this weekend and today was spent taking care of my injured girlfriend, but inbetween dealing with incompetent revolving-door healthcare companies I did get some time to work on my game.
Forgive me for rambling incoherently but I'm sleep-deprived and just felt the need to yammer on a bit.
"Premature optimization is the root of all evil."
-Prof. Emeritus Donald Knuth (Basically the father of computer science)
I spent the weekend refactoring code aggressively. My game logic got rewritten in C++ from TorqueScript, which facilitated a separation of model and view. This came with an impressive 50% improvement in framerate for most skins (except the one skin that currently uses an Ogg Theora background -- that saw only a minor improvement). This is a sign that my code is doing TOO MUCH WORK.
Optimization, fundamentally is NOT about making code faster. It is about making code do *less work*. In my case, there are several opportunities for optimization available to me. I could have it work only on the section of the board that's changed. It would probably bee easily to map out which sections of the board are "dirty" and operate only on them. Join painted* segments using an associative map of some sort, instead of repainting the board. The list goes on and on. I could probably decrease the amount of work my code has to do by more than HALF. But I'm not going to.
Why? Two reasons: 1) The game is, generally speaking, fast enough on my target machine (excluding Ogg Theora support which I'm still tuning). 2) It introduces the likelihood that I will introduce (more) bugs into my game.
More complexity leads to more bugs. Simpler is better. Get the logic working, get the game implemented, THEN make it *fast enough* and begin the QA.
Contrary to what you may be thinking, my switch to C++ wasn't motivated by a desire to make the code faster. On the contrary, it was strictly to make it simpler to separate the "model" (game state) from the "view" (the skin(s) that are currently active). The framerate boost was a pleasant little extra but was not a factor in the decision-making process.
You see, the next step technologically is for me to: 1) Fix a couple annoying bugs that are presently outstanding in the game. 2) Make the process of switching skins smooth, and seamless.
The first one is tricky because the bugs are all timing related. Doing certain things at very specific times produces bizarre results. In this *particular* case, the easiest way for me to address this is to manage the game state synchronously from the main game loop rather then scheduling half a dozen different things and trying to keep them from stepping on each other. This is just a function of my programming background -- there may be a way to do this all easily from TorqueScript but my brain does NOT mesh well with the TorqueScript Way.
The second one becomes easier because now my Skin classes don't need to know about how to display the state of the universe AND maintain the state of the universe -- they simply display the state of the universe as instructed by the engine. Then I use script code to manage which skin(s) are active, whether they are fading in or out, and so forth.
Speaking of bugs... Ever since updating to Beta2 of TGB, I have been leaking t2dParticleEffect objects like a SIEVE. Most of the problem turns out to be an engine bug which Melv has kindly posted a fix for but a good amount is still unexplained and I cannot for the life of me figure it out. Fortunately Melv's fix takes it from being a complete show-stopper to being fix-some-time-before-shipping. That leaves me free to work on skins, and visual presentation, and audio code. Speaking of which: I FINALLY have audio code in place that the game's composers can WORK with! Yay! I still need to track down whether the annoying click I'm hearing at the end of my sound effects is because I did something wrong in producing the sound effects (placeholder stuff) or rather because of an OpenAL/Mac bug, but now they have no excuses -- they can proceed!
I don't recall if I mentioned it before or not, but I finally sat down with "Jane" and went over the Level Builder. She seemed quite eager to try it out. In the process of demoing it to her I managed to put together a skin that I'd been putting off actually implementing for some time because of the difficulty of implementing it. Nifty. The level builder is a very handy tool, despite the rough edges. Now I just need to help "Jane" get comfortable enough with it that she can actually use it. I have a tendency to give five minute guided tours of things to people and assume they picked up enough to be productive. "Ok, here's the general layout of our 50,000 line Java codebase, and our 3,000 JSPs. Our build system is very complex. This command lets you do X, that command lets you do Y, now get to work." To which I get: "Uh yes, but how do I log into the dev server?" I really must stop doing that.
* - The term "painted segment" here refers to an internal data structure in my game used to determine when the game can actually remove tiles that it has flagged for removal based on the position of the sweeper. It has nothing to do with visuals, or paint, or any such thing.
Forgive me for rambling incoherently but I'm sleep-deprived and just felt the need to yammer on a bit.
"Premature optimization is the root of all evil."
-Prof. Emeritus Donald Knuth (Basically the father of computer science)
I spent the weekend refactoring code aggressively. My game logic got rewritten in C++ from TorqueScript, which facilitated a separation of model and view. This came with an impressive 50% improvement in framerate for most skins (except the one skin that currently uses an Ogg Theora background -- that saw only a minor improvement). This is a sign that my code is doing TOO MUCH WORK.
Optimization, fundamentally is NOT about making code faster. It is about making code do *less work*. In my case, there are several opportunities for optimization available to me. I could have it work only on the section of the board that's changed. It would probably bee easily to map out which sections of the board are "dirty" and operate only on them. Join painted* segments using an associative map of some sort, instead of repainting the board. The list goes on and on. I could probably decrease the amount of work my code has to do by more than HALF. But I'm not going to.
Why? Two reasons: 1) The game is, generally speaking, fast enough on my target machine (excluding Ogg Theora support which I'm still tuning). 2) It introduces the likelihood that I will introduce (more) bugs into my game.
More complexity leads to more bugs. Simpler is better. Get the logic working, get the game implemented, THEN make it *fast enough* and begin the QA.
Contrary to what you may be thinking, my switch to C++ wasn't motivated by a desire to make the code faster. On the contrary, it was strictly to make it simpler to separate the "model" (game state) from the "view" (the skin(s) that are currently active). The framerate boost was a pleasant little extra but was not a factor in the decision-making process.
You see, the next step technologically is for me to: 1) Fix a couple annoying bugs that are presently outstanding in the game. 2) Make the process of switching skins smooth, and seamless.
The first one is tricky because the bugs are all timing related. Doing certain things at very specific times produces bizarre results. In this *particular* case, the easiest way for me to address this is to manage the game state synchronously from the main game loop rather then scheduling half a dozen different things and trying to keep them from stepping on each other. This is just a function of my programming background -- there may be a way to do this all easily from TorqueScript but my brain does NOT mesh well with the TorqueScript Way.
The second one becomes easier because now my Skin classes don't need to know about how to display the state of the universe AND maintain the state of the universe -- they simply display the state of the universe as instructed by the engine. Then I use script code to manage which skin(s) are active, whether they are fading in or out, and so forth.
Speaking of bugs... Ever since updating to Beta2 of TGB, I have been leaking t2dParticleEffect objects like a SIEVE. Most of the problem turns out to be an engine bug which Melv has kindly posted a fix for but a good amount is still unexplained and I cannot for the life of me figure it out. Fortunately Melv's fix takes it from being a complete show-stopper to being fix-some-time-before-shipping. That leaves me free to work on skins, and visual presentation, and audio code. Speaking of which: I FINALLY have audio code in place that the game's composers can WORK with! Yay! I still need to track down whether the annoying click I'm hearing at the end of my sound effects is because I did something wrong in producing the sound effects (placeholder stuff) or rather because of an OpenAL/Mac bug, but now they have no excuses -- they can proceed!
I don't recall if I mentioned it before or not, but I finally sat down with "Jane" and went over the Level Builder. She seemed quite eager to try it out. In the process of demoing it to her I managed to put together a skin that I'd been putting off actually implementing for some time because of the difficulty of implementing it. Nifty. The level builder is a very handy tool, despite the rough edges. Now I just need to help "Jane" get comfortable enough with it that she can actually use it. I have a tendency to give five minute guided tours of things to people and assume they picked up enough to be productive. "Ok, here's the general layout of our 50,000 line Java codebase, and our 3,000 JSPs. Our build system is very complex. This command lets you do X, that command lets you do Y, now get to work." To which I get: "Uh yes, but how do I log into the dev server?" I really must stop doing that.
* - The term "painted segment" here refers to an internal data structure in my game used to determine when the game can actually remove tiles that it has flagged for removal based on the position of the sweeper. It has nothing to do with visuals, or paint, or any such thing.
