So B-Term ends with Obscura somewhere between alpha and beta. While the mechanics and main level design are in place there is still quite a bit of work to do and nearly all of the art to get in. I still feel though that we’re in a good place for 2/3 of the way done and I am confident we can have a fully playable game by March, with a more finely tuned game released to the public sometime in May (Post Project Due Date).

That isn’t to say there haven’t been some issues surrounding development. We had originally planned to implement shaders in our mod, for use in 3 separate effects; however it would appear compiling shaders is a really tricky problem in the Source Engine. Despite communication on the forums it would appear only a lucky few can get shaders to work on their systems. Despite trying various different methods and tutorials we could only get shaders to compile on one of our systems yet they never worked.

We had originally planned on using the L4D glow effect in our game to differentiate selected objects, but were unable to due to missing files. Thankfully as we gave up on shaders working the files were restored and we decided that using this glow effect for different aspects of our game would be able to replace the work shaders would have accomplished.

While this wasn’t our initial idea the effect works well within our design, and considering how much time was wasted on shaders it’s better to go with what works rather than timesinks. Beyond that though developing the levels in hammer and testing/fixing/modifying the puzzles worked well, and we got a lot of work on the game done. We’ll have a little bit of time next term to work on a few things, but then we get down to playtesting sessions. One of the benefits of working in our game design class was how much we learned by having playtesting sessions. It really tells you a lot about your game that you would have never found out.

Again it’s comforting to see how far our come, and I really enjoy how it’s coming along.

Over the past 6 weeks we’ve developed 5 short games using a lua based engine called Perlenspiel. Perlenspiel was designed to give you the bare-bones needed to create a game, but allow you to use scripting to shorten development time. All you get is a grid, 1 line of text at the top, the ability to change the color/glyph of a pixel in the grid, keyboard/mouse inputs, and a time function. It doesn’t allow for any real art so developing the game is creating the code, but most importantly design.

The schedule for the course was you would A. Given some parameters, B. 4 Days to design and build a prototype, C. A playtesting session to show you any errors/needed changes, and finally D. 3 Days to polish he game and turn it in. Limited time made us be very conscious of the scope of what we could build and most of the parameters were restrictions on what we could/couldn’t do. This really focused all of us in the class on design, and allowed for some very different and creative games to be created. You can find the games made during this time in the Games section.

This course was definitely my favorite course I’ve taken at WPI, and I truly miss the time when I was able to quickly design and develop games like I did in this course. I’ve been unfortunate that I haven’t been able to go to Game Jams (I always have a fair amount of work, most of the time developing another game), but I understand the allure of such events. It’s said that every person in the game industry has a few ideas for the “perfect game” that they want to make. While I do enjoy game development and programming, the freedom of game design was a truly fantastic experience.

So A-Term is over and thus 1/3 of the project. We got all the basic mechanics done, and most of the bugs worked out. If everything goes nicely we’re basically done coding, and everything else will be scripting and stuff in Hammer.

We had quite a few ups and downs during development. Everything from the storyline rapidly changing, or retooling the mechanics to work as puzzle elements without breaking the puzzles changed the way we had originally envisioned the game. While the mechanics were developed, we’ve still has some issues with shaders and the art pipeline but overall I feel that we should overcome these in the following seven weeks.

Still though even if it’s just some skeleton rooms and it’s puzzleless it’s nice to have something I can show off to people. Responses have mostly been favorable and I can’t wait to start the testing of the puzzles. Even though we’re only 1/3 of the way done it really feels like a game.

Rawshark was the first game I truly worked on. I had worked on Dead to Lights 2, but most of my work was done on developing the hardware using the arduino, and interfacing it with XNA. Rawshark was created using C4 a game engine that while not fantastic is great for teaching. The original concept behind Rawshark was to create a game that used a grappling hook, and could still attack enemies. Rawshark was very short lasting just a small level with some minor items, and a giant boss. Created within the confines of 3 weeks it was very unpolished, and had quite a few problems. Overall though I’m glad with how Rawshark turned out, and I’d be willing to use C4 again if not for the horrendous issues with the art pipeline.

Dead to Lights 2 was created for a course with the aim to make a game using a hardware input that we ourselves designed and implemented. This was done using a chipset called the Arduino a device that allows for circuit input and transfers it to usb. Our game idea was to use a flashlight and create a survival horror. Obviously again limited by less than 2 weeks or so of time we decided to use XNA and create a top down arcade style game. The player would use his flashlight to ward off and kill zombies; also included was the functionality to shake the flashlight to reload batteries so that the flashlight could remain lit (in game). Movement was controlled by interfacing the Arduino with a Wii Nunchuck, and if the flashlight was dead moving the nunchuck would use a melee attack. Turning and directing the in-game flashlight was controlled by shining a real flashlight at sensors placed around the screen.

Most of my work was done on creating and building the circuits needed to make the hardware work and writing the code to interface with XNA. Aside from hardware I worked on designing how the game worked, and creating all the art for the game (You can tell it’s programmer art, but alas). I like how Dead to Lights 2 turned out and considering it’s released with a keyboard ver. It’s still a nice little game. Below is a video my partner and I made discussing the development of D2L2 as well as video from the game, and playtesting sessions.