DirectX Project: Post Mortem

Good: My first attempt at using DirectX, though by this point I had a bit of experience with C and C++ which helped get me into the coding behind. Then the DirectX components such as DirectDraw, and DirectSound I didn’t seem to have too much trouble implementing. With all that, I was able to quickly implemented some basic game features, for the core mechanics. Plus this was also my frist attempt at drawing a level, completely from a single sprite file, and in the end I was able to implement that with little trouble to a decent effect.

Bad: I had a few issues with the initial set up, of my window for the game. I had to do a lot of reading to figure out what each of the requirements were, and how they would effect the users experience. After I learned how to correctly create a blank window for the game, I went ahead, and tried to start implementing a simple version of what I had planned. However, I run into the problem of memory leak and management. This was causing errors with the spawning, and removal, of enemies for the player. In the end I had to try different approaches to this, which ate more time then I was able to afford. In the end, I was unable to replace the place holder art, and get pass the very simple game play that is there.

Overall: Even though I managed to get something playable, I would have to say that this project was a failure. I was unable to get the game to the level that I wanted, as I had trouble getting through the initial complexity, followed by dealing with memory on this level. Though I am not happy with the game, I can look back on it and see where I went wrong with managing my time and lack of planning, and learn from that for future endeavours.

Advertisements

Alien Swarm Level Development

Awhile ago, I had my first chance to experience the Hammer Editor and the Alien Swarm SDK. My classmates and I were tasked to create a level each, while at the same time learning the in and outs of this tool. After planning the layout of my level, I jumped into the editor to see what it was capable of, before planning the various events and obstacles that the players would encounter. Using the provided tools, I made a rough version of my layout and tried to test it. This was were I encountered the first of the various requires that this game required to run, this being the camera and unsealed geometry.

Reading through the documentation, found on the Alien Swarm wiki, I was quickly able to seal my level to let it compile, finally allowing to test my level. However, because of how the camera is designed to work in Alien Swarm, I found that a few of the rooms I designed, where hidden by their very own walls. A section of the building caused to camera to start cutting through geometry, because of the players descent. As such, I had to go back to my plans, and start removing sections, and editing others, to allow the player’s view to go unhindered. After a few runs of the level, and several trips to the drawing board, I was finally able to get acceptable layout, for the levels alpha.

My next task, was to work with the various Aliens that the player would have to face. Getting the Aliens into the level was easy enough, however getting to work and avoid pop in proved a different matter. I made getting the aliens to behave as I wanted, my first objective. Thankfully the documentation, along with trail and error, I was able to create the proper amount of info nodes and object tags to get the Aliens to behave. The problem with popping in, took a more hands on approach then reading. As I had to work with their borrowing and jumping animations, along with various models and invisible walls, to assure that the aliens didn’t just appear out of thin air and prevent the player from falling through any holes for the aliens.

With both layout, and Aliens taken care off. I took a more general approached, and starting working on the features that the game had to offer. Such as hackable doors, mission objectives, and scenery. Following what I learned from dealing with setting up the behaviour of the Aliens, I was able to apply to most of the remaining features and get them work after a bit of tweaking. As such, I went back to the drawing board one last time, and planned for the events for the players. Then after a few days of play testing, and tweaking, I was finally able to finish my first attempt at creating a level for Alien Swarm.

Good: I was more or less happy with my level’s initial layout, and having the level drawn on paper before hand-made creating the basic shape of it a simple matter. Plus the editor provided all the games models and scripting, so that allowed me to focus more on designing the level, then creating a game from the ground up.

Bad: Hammer is rather buggy, and I had to deal with crashes quite a bit. Combined with the fact that their no official documentation, I had to spend time either testing or searching for any info that was either vague or not truly covered on the wiki that has been set up.

Overall: This was a learning experience, as this was my first attempt with a studio’s actual Editor and SDK. I had to learn how to deal with the inherent restrictions, limitations, and lack of info, that comes with dealing with in-house development software. Due to the short amount of time I had to deal with, I had to learn to manage my time between planning, researching, working, and tweaking. In the end, I was able to create a level that I happy with as a first try. Below I have included a link to download the VMF file of the level, if anyone wants to see what I have done.

Alien Swarm Level: Download Link

Hammer Pinball: Post Mortem

Good: This was my first collaborative effort, though with the group brainstorming and setting out individual duties early made the process pretty painless. Once we started the coding, it was agreed upon in my three man group, that I would be in charge of making sure the various forms of collision to work. This included the ball/paddle collision, ball/ball collision, and ball/brick collision. Getting the first two forms of collisions to work went pretty smoothly, though the brick came around eventually. After collision I also had to work on redrawing the bricks to the score when a point was scored, which after I got used to the custom library by one of my colleagues, came a simple task.

Bad: The brick/ball collision and redrawing took too much time to figure out, and made testing a rush job. Because these crucial parts were delayed, we didn’t have much time to improve the game by adding difficulties and different features like that. Then the collision code was also passed around, during the trouble with the brick/ball collision, as such a bit of confusion arrived with slight changes to code until the finished version which is now being presented. Plus several strange glitches, such as the ball catching on the other ball, the paddle, or not changing direction after hitting the brick, also reduced the amount of time we had to improve the game.

Overall: I feel that project went pretty good overall, the communication was there and everyone stuck with their assigned tasks. Though we didn’t mind giving advice or aid to each other, when it was needed. Though we all ran into our own problems, we manage to overcome them and make a pretty enjoyable game.

Text Adventure Post-Mortem

C++ Text Adventure

Good: The project went pretty smoothly, a lot of the code was easily reusable with very little tweaking. The pre-programming planning really helped speed things up, I’ll get the plan scanned and loaded up to the site

Bad: I ended up running into a few problems with the while loops I originally had implemented, to try and control what the user’s could input. Because of the amount of time I spent, unsuccessfully, trying to fix the problem, caused my testing of the project as a whole to be limited. In such, the various bits of grammar and some spelling could have been improved.

Overall: Other then the problem with the while loops, the project went quite smoothly and didn’t need any other fixes.