Monday, July 11, 2011

A Short Return to Sonic Robo Blast 2

Sonic Robo Blast 2 is a Sonic the Hedgehog fangame; a bizarre and brilliant attempt to take 3D Sonic games in a different direction using the Doom engine. It really succeeds with its momentum based platforming, levels ripe for exploration, and unique and fresh multiplayer. The game has a surprisingly solid community that supports it with custom levels, characters, and entire mods. Seven or eight years ago I used to play the multiplayer quite often and I got into making some of my own levels for the game. Recently I had just released a level that I had made several years ago that I never got around to distributing. Here is what I had to say on the SRB2 forum:

It has been a while since I have posted on here...

This is an older level of mine that I had recently stumbled upon again. I always meant to release it, but for some reason which I can not remember at the moment, I did not (maybe I thought it was terrible, though I would actually say it is just average). Marine Court Zone was basically an experiment map for me, as I used it to learn how to implement custom textures into SRB2. The plan was to use what I had learned for a single player map with the same theme as this one, but nothing really came out of that due to that horrific combination of the forces known as laziness and frustration.

So anyways, enough with the history, here is the map. It is small, given no playtesting, and contains some rather bland textures now that I look back in hindsight (I was using MSPaint at the time). I do like the general style I was going for though; definitely unique for SRB2.

Enjoy!





The download link for the map can be found in the forum thread here:
http://mb.srb2.org/showthread.php?t=36160

To find out more and download SRB2, visit the official website here:
http://www.srb2.org/

Wednesday, July 6, 2011

One Prototype in Particular

At the current moment I am screwing around in regards to my work in game design. Playing with ideas; seeing where they go and what they can do. Sometimes I will take the next step and quickly whip together a rough prototype that allows me to get a more clear perspective on how the systems work. This is one thing that I have found Game Maker very useful for; I can have a working prototype within a few hours.

Much of this work is really just practice for myself. I am a far better programmer than I used to be (I now use my own collision system in Game Maker that gives me the flexibility I want) because of sitting down and rapidly prototyping my ideas. One prototype dealt with the AI of enemies who existed in a top down environment. This allowed me to utilize and see the advantages and disadvantages of the tricks used by game designers in the past to create AI monsters who are interesting and reasonable to fight. There has to be certain amount of an organic quality to any AI enemies in a game; they must make mistakes and have victories just like the player.

There is a particular prototype I worked on that basically was about expanding the mechanics of the top down combat found in the original Legend of Zelda and moving them into an arcade-y, randomly generated dungeon crawler structure to allow for more replayability. The intricacies of player movement and action are not usually considered by the player (rightfully so, for they should not be), but as a designer it is surprising to find how many decisions are made just regarding how a player should use their sword. Do they stab with their sword or do they swing it? How long does they sword attack last? How much time is there between sword attacks? Does the player come to a stop when attacking with their sword or do they keep in motion? What visual aids should be used to help the player understand the way their sword acts and how it affects the game world? How much damage does the sword do? Does it knock enemies back when it hits them? Can it be used for non-combative purposes such as cutting grass or rope?

These are all questions whose answers can be found in experimentation, one of the greatest assets of a game designer. Test the systems with different people to discover entirely new results, bad or good. If the same system delivers the same results with each unique player, something is wrong. There is no room for play, an essential component of games that is commonly left out of a lot of the more modern designs focused around attaining some sort of narrative quality.

Friday, July 1, 2011

Further Evaluation of this Blog's Function and the Fate of Reconstructing S31

It has been a little over a week since I posted on this blog and since I have quite a bit to say, this will be a rather long post.

First, I am going to write about what I am interested in doing with this blog next. The original idea was to write a medium sized post every day, talking about something I had done related to game development or whatever else that was on my mind that was on the subject. Basically, it was to hold me accountable to pursue my interests more seriously and to train myself to write things down instead of keeping everything held up in my mind. Also, writing is an excellent intellectual exercise and I can honestly say that I do not do enough of it for fun. The purpose of the blog was for me to have a solidified place where I could write about one of my interests. Though I am pretty sure no one else has read this blog, theoretically anyone can, so by making my writing available to the public I am forced to hold up some sort of standard of quality, which I am not sure I have done well. It is almost always a useful method: quality of quantity. Yet my focus was on a post a day, which is not itself an impractical goal, but after a while a mentality of, "Well, I guess I have to write about something today," arises and the fatigue sets in. It is probably because I am extremely lazy and I am a really amateur writer that this is the trap which I found myself captured by.

I now want to shift the emphasis from a post a day to writing when I have enough content to make a quality post. There is still an urgency in my mind to keep myself continually writing, so this nine day break will probably be an uncommon occurrence still (hopefully). The blog is still only about game development, since that is the most productive and interesting thing I will usually want to write about. Plus, I am an aspiring game developer and, well, who knows where this thing can eventually go? So here is to the hope that "The Edifice of Enterprise" continues onward!

Let me change the topic to where I last left off: Reconstructing S31. This is probably going to turn in to a scrapped project unfortunately, joining my collection of fifty something other failed attempts to make a complete game. Why? Well, I said that I had an idea for a new approach to the gameplay of the game. That concept was to have make the game more like an adventure game in mechanics and to basically make the who shipyard a large collection of systems that the player would have to mess around with in order to rebuild the huge robot controlled factory. The shipyard itself would become the main character, having a mind of its own that control the probe that rode along the rails fixing everything. However, there ended up being two problems with this idea that led to me not even investing much time in a prototype. First, Game Maker is not really good when it comes to handling complex, dynamic systems like this that are made of many unique, but often times similar parts. This is because of the way Game Maker handles instances and objects (classes). I can't have instances of an object have different initial values (as far as I am aware of). Each element would have to be coded individually, and while Game Maker has parenting, the pipeline of creating new objects in Game Maker eventually becomes really bogged down and inefficient if one has too many.

Second, the idea never proved itself to be fun. Of course it is different and sort of unique, but it never allowed for the player to be, well, playful. They would click in all the right spots, move to all the right areas, and then at the end they get a pat on the back for winning. There was no room for strategy, improvisation, and imagination in the world I was creating, which was a deep flaw. Making video games is really, really, really hard. This is not hyperbole; it is the honest truth. This difficulty increases when it is a solo project (though some things are actually easier by oneself). I need a strong passion for and belief in my vision of the final product in order to set forth and create a game. I did not have that for Reconstructing S31 once it reached this point.

 And thus Reconstructing S31 is hereby to dropped into the folder on my computer labeled "Failed Projects," joining a large company of friends. On each project I learn something new, so I never have any regrets and it is the same case here. I became a significantly better spriter, programmer, and designer by focusing on this project. I also learned more about myself as a developer and what I should and should not do. It wasn't huge, but Reconstructing S31 was still too big. I didn't have a fun or complete playable prototype at the beginning and I focused to much on the fiction of the game (which still boggles my mind since I am so anti-story in games). These lessons and experiences allow me to grow and gain experience, the most important things for someone who some day wants to make games for a living must do.

So, what will I do next?