I'm not very good at this... -- part II
In this post I'll talk about how things have been going with regards to Allacrost. In short: pretty darn good. If you keep up with Allacrost news at all you'll know that we made our third demo release around December 10th. Probably the best part about reaching that milestone is how much more mature the game engine code is now. Particularly the video and audio engines are pretty darn solid. We didn't intend to work on the engine so much for this release (and its a large part of the reason why the release happened much later than we were hoping for). It just sort of happened.....mostly because I started mucking around in the video engine and ended up re-writing half of it, and then someone else took our new audio engine code with an OpenAL back end and integrated it into the main SVN trunk. I'd like to get a bit technical with what exactly was done in this area for a bit, so if you don't care about that kind of stuff then skip it :)
First the video engine. The main problem with it was that when the first full version of it was completed long ago (I think over 2 years ago actually), it was not done very well. Some parts of the design were very clever, but others were more dirty hacks than anything. The major problems I had to rectify were as follows below. Keep in mind that I have virtually no experience with graphics programming or OpenGL, so this was very much a learning experience for me.
1) Sparse comments -- a lot of things were ill-explained, or not explained at all. Other places had comments that were just plain confusing.
2) Code standard -- a large part of the code did not conform to our code standard. To give the original programmer credit, we hadn't really finalized our code standard by the time he was mostly finished with this. I asked him to go back and make it conform to the standard after his work was finished, but he left before even starting on that.
3) Bad design -- some parts were absolutely horrible. For example, the code to draw an image was implemented in the GameVideo class (the main singleton class for the engine) rather than the image classes themselves. Another example (which was incredibly difficult for me to rectify) was that all image classes were designed to contain 1-n "image elements" to support creating composite images (ie, representing an image formed from multiple images in the game). This really, really complicated the image code far more than it should have been. My solution to this was to allow our abstract "ImageDescriptor" class (which is our most basic type of image class in the engine) to represent an image element for the new CompositeImage class that I wrote, which is what is now used to support those types of images.
It was that third point that really took the most work to fix. I think I spent something like 6-8 weeks working on the video engine, and I didn't even finish working on all of it. I worked the most in the image and texture management code, which is really the "core" of the engine and what all the other parts of the engine build upon. Thus, it was the most painful to revamp. I also did some work in the text rendering code and GUI code, but those areas still need some additional work. I'm glad that all of this is behind us now, because it really was something that needed to be done (because the old design made expanding upon the engine insanely more difficult), but I got really aggravated at some points and focused my anger towards the person who originally wrote it. This person (who I shall not name) came on the team about two years ago, when we had an OpenGL graphics engine that was extremely rudimentary and could barely do anything. He really did an awesome job at providing us a full-featured engine at a record pace (around two months) so we were extremely grateful to him. I now realize the reason he was able to do it so fast is that he really skipped out on commenting, design, extendability, etc. I had originally told this person to focus on providing a really solid core for the engine (ie images and texture management, which is what I re-wrote), but he ignored my plea and went right into producing particle engines, distortion meshes, and all kinds of advanced graphics which we have not even been able to make use of yet. Worse still, a lot of those advanced features depended on the existing state of the graphics engine to work, so they will pretty much have to be scrapped now since I'm sure they don't work. After this person had finished all their work on the graphics engine, I asked him to go back and make it conform to the code standard, add comments, etc. and he left the team shortly after that (coincidence? maybe...). Anyway, the lesson I learned from all this: don't allow our programmers to do quick-and-dirty jobs because it takes such a large amount of time and effort to clean up their mess later.
Now the audio engine was also a bit of a pain in the ass, but it didn't absorb as much time as the video engine did. A completely new audio engine was written by one of our top programmers (who unfortunately had to move out of the country and left the team as a result). This version utilized OpenAL as our audio library, instead of the SDL_mixer library that was used for our 0.2.0 release. I had written an OpenAL library myself about two years ago, but there were a ton of problems with it because OpenAL is.....not very nice in many ways. For example, the code base for Windows, OS X, and Linux versions of this library are all entirely different...there's no common code! As you can imagine, this leads to quite a few problems in providing a cross-platform solution. We didn't have too many problems with that this time because we chose not to use ALUT (an OpenAL utility toolkit library) and instead implemented our own WAV and Vorbis file loaders directly. I think this engine is pretty solid now. In the near future we'll be adding distance attenuation (audio sources that get louder the closer you are to them) and customized looping playback of specified sections. This is actually the *fourth* rewrite of the audio engine. The first one I wrote with SDL_mixer, then wrote one using OpenAL, another SDL_mixer one when OpenAL was too buggy, and finally back to OpenAL again. I actually wanted to avoid using OpenAL again, but we can't implement the features we require with SDL_mixer, and there doesn't seem to be any better free audio library out there (we looked hard...couldn't find anything that seemed better than OpenAL). So I guess we're stuck with it.
Looking to the future, if you've read the main site at www.allacrost.org you'll notice that we're now working on demo 1.0.0. I'm really excited about this release (much more so than our other three releases). This is going to be the original demo that I wanted to have as our first release, but we weren't anywhere near ready for something like this 18 months ago and we needed to get an initial release out, so 0.1.0 was very under featured. The part I think I'm most excited about is that this demo will actually have a story and a plot to follow. With regards to most games, what motivates me to continue playing the game is to find out what happens next. I'm all about the story, and likewise Allacrost will have a strong emphasis on the story as well. Most of the programming work for this release is going to be in the actual game code, and only a small amount in the engine. I find writing game code to be more fun, because its easier to see the results of your work and get instant gratification for it. I'm really concerned about the artwork demand for this release though; I have a feeling that artwork might be the bottleneck for this particular release.
Anyway, that's all I have to comment on about Allacrost for now. Next week I'll talk about how my life in general has been going.
First the video engine. The main problem with it was that when the first full version of it was completed long ago (I think over 2 years ago actually), it was not done very well. Some parts of the design were very clever, but others were more dirty hacks than anything. The major problems I had to rectify were as follows below. Keep in mind that I have virtually no experience with graphics programming or OpenGL, so this was very much a learning experience for me.
1) Sparse comments -- a lot of things were ill-explained, or not explained at all. Other places had comments that were just plain confusing.
2) Code standard -- a large part of the code did not conform to our code standard. To give the original programmer credit, we hadn't really finalized our code standard by the time he was mostly finished with this. I asked him to go back and make it conform to the standard after his work was finished, but he left before even starting on that.
3) Bad design -- some parts were absolutely horrible. For example, the code to draw an image was implemented in the GameVideo class (the main singleton class for the engine) rather than the image classes themselves. Another example (which was incredibly difficult for me to rectify) was that all image classes were designed to contain 1-n "image elements" to support creating composite images (ie, representing an image formed from multiple images in the game). This really, really complicated the image code far more than it should have been. My solution to this was to allow our abstract "ImageDescriptor" class (which is our most basic type of image class in the engine) to represent an image element for the new CompositeImage class that I wrote, which is what is now used to support those types of images.
It was that third point that really took the most work to fix. I think I spent something like 6-8 weeks working on the video engine, and I didn't even finish working on all of it. I worked the most in the image and texture management code, which is really the "core" of the engine and what all the other parts of the engine build upon. Thus, it was the most painful to revamp. I also did some work in the text rendering code and GUI code, but those areas still need some additional work. I'm glad that all of this is behind us now, because it really was something that needed to be done (because the old design made expanding upon the engine insanely more difficult), but I got really aggravated at some points and focused my anger towards the person who originally wrote it. This person (who I shall not name) came on the team about two years ago, when we had an OpenGL graphics engine that was extremely rudimentary and could barely do anything. He really did an awesome job at providing us a full-featured engine at a record pace (around two months) so we were extremely grateful to him. I now realize the reason he was able to do it so fast is that he really skipped out on commenting, design, extendability, etc. I had originally told this person to focus on providing a really solid core for the engine (ie images and texture management, which is what I re-wrote), but he ignored my plea and went right into producing particle engines, distortion meshes, and all kinds of advanced graphics which we have not even been able to make use of yet. Worse still, a lot of those advanced features depended on the existing state of the graphics engine to work, so they will pretty much have to be scrapped now since I'm sure they don't work. After this person had finished all their work on the graphics engine, I asked him to go back and make it conform to the code standard, add comments, etc. and he left the team shortly after that (coincidence? maybe...). Anyway, the lesson I learned from all this: don't allow our programmers to do quick-and-dirty jobs because it takes such a large amount of time and effort to clean up their mess later.
Now the audio engine was also a bit of a pain in the ass, but it didn't absorb as much time as the video engine did. A completely new audio engine was written by one of our top programmers (who unfortunately had to move out of the country and left the team as a result). This version utilized OpenAL as our audio library, instead of the SDL_mixer library that was used for our 0.2.0 release. I had written an OpenAL library myself about two years ago, but there were a ton of problems with it because OpenAL is.....not very nice in many ways. For example, the code base for Windows, OS X, and Linux versions of this library are all entirely different...there's no common code! As you can imagine, this leads to quite a few problems in providing a cross-platform solution. We didn't have too many problems with that this time because we chose not to use ALUT (an OpenAL utility toolkit library) and instead implemented our own WAV and Vorbis file loaders directly. I think this engine is pretty solid now. In the near future we'll be adding distance attenuation (audio sources that get louder the closer you are to them) and customized looping playback of specified sections. This is actually the *fourth* rewrite of the audio engine. The first one I wrote with SDL_mixer, then wrote one using OpenAL, another SDL_mixer one when OpenAL was too buggy, and finally back to OpenAL again. I actually wanted to avoid using OpenAL again, but we can't implement the features we require with SDL_mixer, and there doesn't seem to be any better free audio library out there (we looked hard...couldn't find anything that seemed better than OpenAL). So I guess we're stuck with it.
Looking to the future, if you've read the main site at www.allacrost.org you'll notice that we're now working on demo 1.0.0. I'm really excited about this release (much more so than our other three releases). This is going to be the original demo that I wanted to have as our first release, but we weren't anywhere near ready for something like this 18 months ago and we needed to get an initial release out, so 0.1.0 was very under featured. The part I think I'm most excited about is that this demo will actually have a story and a plot to follow. With regards to most games, what motivates me to continue playing the game is to find out what happens next. I'm all about the story, and likewise Allacrost will have a strong emphasis on the story as well. Most of the programming work for this release is going to be in the actual game code, and only a small amount in the engine. I find writing game code to be more fun, because its easier to see the results of your work and get instant gratification for it. I'm really concerned about the artwork demand for this release though; I have a feeling that artwork might be the bottleneck for this particular release.
Anyway, that's all I have to comment on about Allacrost for now. Next week I'll talk about how my life in general has been going.
posted by Tyler Olsen at 10:23 PM
0 Comments:
Post a Comment
<< Home