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/

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.

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?

A Blog Post of Almost Zero Content

Hey, cool, a completely unproductive day! Well, in regards to Reconstructing S31, anyways. It is summer and need time to do other things. This will be a sad excuse for a blog post, but there are always going to be a few of those here and there. I did mess around with textures and player types in ZDoom, which is probably the only development related thing I did all day.

The History Of Reconstructing S31's Game Design

Recently I have been thinking hard about what to do with the gameplay of Reconstructing S31. This whole entire time my thoughts regarding such have been gradually evolving. Originally, I was planning on the game to be a cross between an on-rails shooter and an adventure-y puzzle game. This gameplay concept would take a lot of its inspiration from the earlier Zelda games, having a non-linear world for the player to explore but a set progression through abilities towards an ending. However, when I started to think about the actually context of the game's world, it take several boring contrivances to explain why the player had to fight enemies. From here, I was left with just the adventure-y puzzle game part.

This meant the focus would have to completely turn to puzzles. Now the term "puzzle" is applied to a great many game designs that can vary significantly from each other. For instance, consider just how different the designs of Tetris and Sokoban are. Or an even large gap would be between something like Bejeweled and an inventory puzzle found within the typical point and click adventure. I wanted to create something as unique as Sokoban, with one specific mechanic that could be applied to multiple elements in different ways. It would be in the combinations of these different interactions where the interesting could occur.

So came the concept of "tiles," the different elements that could be manipulated by the single mechanic of clicking (innovation!). First I introduced sliding tiles, not my own puzzle design but with an imaginative assortment of tile variations I hoped there would be something worthwhile to find. I also worked on the idea of two other tile types, place tiles and rail tiles. Now two new problems revealed themselves to me. While I had shifted the design over to a more linear, puzzle oriented approach, the world was still designed for a more adventure like experience, forcing me to consider the way the game was structured overall. Having a large focus on the player movement amongst rails also challenged what I was trying to accomplish with the puzzle elements. I also found that I had made a common mistake with my three tile types. Yes, they were manipulated by the same mechanic, but mixing them together did not reveal anything really interesting or new in the context of getting the player from point to point. I think there still is potential in them, but I am considering moving them into another project.

I am still considering where to move on to now with Reconstructing S31 and I have an idea I would like to prototype; it is very unique and definitely closer to what I have been looking for.

The Contributions of Details Towards Cohesion

Sometimes I spend my time doing things that I probably should not be focusing on. I have been working on the title scene of the game and its title logo for duration of today, two things that are usually handled at the end of a project. However, I felt like doing this and I was inspired, so I do not feel too terrible about indulging myself. It does help to further establish the visual style of the game (again, this should not be done at the beginning of the process, but whatever). The thing I am really looking for in Reconstructing S31 is a cohesive experience and so while my thoughts are dedicated to how the gameplay will operate, I feel that working on these details as well can help me to establish that cohesion as soon as possible in the development process.

Anyways, enough babbling here is the result of my recent efforts:

Tedious Work With Rooms and Moody Backgrounds

Half of the process of creating a game is the busy work. Whether it is tediously shading of complex animated sprites or transferring certain files into another format, there can be aspects to game creation that are not so fun. Today I created each of the rooms for the game in Game Maker, setting the correct values for each and fixing some issues that arose regarding properly displaying the smaller rooms. While there are many tools out there that are built to make hard and long tasks easier, sometimes the effort spent building the proper tool does not make up for the time spent on the task.

I also got around to working more on the sky background. There is only one sky seen throughout the entire game, so I have been putting effort into making it really great and effective. When making a background, the designer needs to distinguish it from the foreground and gameplay elements visually. I have been doing this by drawing the background with cool, mellow colors and not adding in shading and details. With the background the power should be found in the silhouettes and the colors, each helping to establish a mood and tone. While what I have right now is not quite what I want, I am definitely closer than I was with my last revision. Originally I was using a bright orange and red color palette to depict a thick atmosphere of a gas planet, but now I have shifted towards a reserved grayish blue coupled with a calm peach color. This reflects the dormancy of S31 in a way that the bright, cheerful colors never could.