How Socketeer's Level Design Evolved

Its been a long journey from inception to completion, where the game design twisted and mutated into something quite different from the original concept. Although, in terms of delivering what I laid out in the original game design document (which, to be fair, came a fair bit after I started the project) the final game is actually pretty close.

From a pure game design point of view, Socketeer was an interesting challenge. The most dramatic design revisions came from the level generation system. Originally the levels were preset shapes that were supposed to represent the inside of a spaceship. But because of the camera placement being so close, you could never really tell you were navigating inside the shape of a spaceship. Also, the levels were open and lacked any structure, making them boring to navigate.

After watching the excellent youtube series presented by Mark Brown on how Zelda's dungeon's worked, I started to try and unpick how these levels were constructed and pondered if there was a replicate the hand authored level designs in zelda with procedural generation. I started by studying Mark's dungeon graphs, which he would use to describe how interesting each level was, and why some dungeons were harder or more interesting.

As you can see from this sample graph above, every zelda dungeon has a route which branches off at various points, and at the end of each branch there was a reward, which was either a key, an item or something else. Some of these branches were also locked, sometimes by keys, sometimes by items and sometimes by puzzles.

The first problem with my current level generation system was that if it locked off a single route it couldn't guarantee that would block off all paths to the reward. What I needed was a maze generation algorithm. Using an excellent book on coding mazes, I adapted the random level generation system to use layouts created by the newly implemented maze algorithm. This meant, because the system generated the "perfect" maze, there was only one route to each dead-end. Exactly what I needed.

After I had written the maze generation system and after studying the graphs further (and watched more of Mark's excellent videos) I managed to come up with a simple graph-generating system. The way the system works is that it finds and stores every dead-end (being a single cell or maze square, that has only one connection to another cell) and junction point (being a cell with three or more connections) in the maze. The system then randomly assigned "rewards" at each dead-end and in turn blocks that reward at the nearest junction point it can find, locked using a key which then can be placed as a new reward at a another randomly selected dead-end. The system keeps looping through all dead-ends, assigning rewards, and then locking them off, until there are none left.

The new system gave the levels a much more interesting structure. Suddenly, you had to think about where you were in the level, remember locked doors and rewards you found previously so you could navigate to them once you had found the appropriate key. Also, the system sometimes wouldn't block the reward off, or generate multiple blocked routes, helping give each level a more individual feel.

On the whole I am happy with how the graph generating system came out. I also think I've only scratched the surface of what is possible, and want to explore the idea further, perhaps in a future update to Socketeer, or perhaps in a sequel. We shall see...

Announcing SOCKETEER

Very please to (finally) announce our first game release SOCKETEER.

Firstly, I'd like to thank my publisher Alliance Digital Media for believing in me and my game. Also, my wife Linsey and my six year old boy Leo, who have been extremely patient with me while I work all hours to bring this game to launch.

I am looking forward to everyone finally being able to play it!

Tom.

New Logo, Pre-Alpha Trailer & Very Early Demo

Hey people, we've been quite busy creating some promotional materials for Remote. Firstly, we've just made a new trailer and our logo for the game:

Pre-Alpha Teaser Trailer

Also, I've uploaded an early playable demo onto itch.io. Please head there and download the demo, which is either for PC or Mac, and see what you think.

itch.io link

Finally, I'm going to start updating my new devlog on the tigsource forums. Please head there for more granular updates about the game's development.

TIGSource Devlog

Thanks people! I'm keen on hearing what you guys think about the game...

One (Art) Direction

Firstly, I am a terrible person for not updating this blog sooner, but we've been working hard here at Ice BEAM to get the new look into our first game, Remote. I've collaborated with Momo and Sprits  to produce artwork for the main character, backgrounds and evil robot bad guys! Here is the original mock-up that Ruud did after some discussions and some initial mood boards were drawn up.

And here is an in game gif after importing the graphics and getting it all working.

The scale had to change, so that movement felt better, but I think it very much captures the original style. I love it!

This is patrol guy, looking around the ship. I really like the depressed expression the robot has, like he is fed up to the back teeth about working this shift.

Here is an action shot of our main character hacking into a bad guy and taking him over, and one more with the poor guy being ejected into outer space.

I think that Momo and Sprits have done an exceptional job here in giving a fresh look and feel to the game while still retaining all the core gameplay values the original prototype had. Visually, the gameplay rules are easy to parse because of the clean vector graphics and now the game has a ton of charm my original art style never had. I think you'll agree it looks the bees knees!

Are Retro Sports Games Better Than Modern Sports Games?

I've got back into retro gaming in a big way after buying a framemeister. Me and a friend have been heavily playing Super Tennis on the SNES, amongst other games, and this got me thinking about the idea that retro sports games are (generally) much better than modern sports games. I'm trying not to be nostalgic here. I think it very easy to fall into old codger mindset that 'things were better in my day' but I genuinely believe this to be true. There are  plenty of reasons why I think this, including the fact that retro sports games usually have simpler controls, more iconic representation and a larger focus on the single screen multiplayer experience but I think that it comes down to the simple fact that modern sports titles have an endless obsession with realism.

I think the pursuit of realism  is one of the most detrimental forces in MODERN game design.

I've also never really understood the motivation behind our industries obsession with it. Ok, I get the idea that some people want graphics to look as close to real-life as possible, and it is a laudable goal which I admire (even if it doesn't float my boat)  but I never fully bought into the idea that the game design itself should also pursue this goal.

A retro sports classic. Super Tennis!

To paraphrase Roger Caillois games are separate and closed off from real life. Unlike life, the very best games are simple, clean, easy to understand. You know who was the winner, you understood everything that took place and can easily comprehend exactly why it had that outcome. So I do find it so perplexing that some designers insist on putting these opaque rules inside the game to better simulate stress levels, concentration or fatigue.

I mean, what does the "vision" stat actually do in Fifa 15?

I go back and play EA Hockey, Irem Skins Golf or Super Tennis and there is an elegant simplicity to the gameplay that makes for a wholly more satisfying experience. I think this is one of the main reasons that Rocket League is getting so much attention.  It taps into that more simple retro sports game design philosophy (that and it was free to PlayStation Plus subscribers!). The game becomes about players pitting against each other real-time competition where the only difference between them is their dexterity and skill.

This is an argument that I've had many MANY times with friends when talking about Fifa Soccer (or why I don't like playing football games any more). I can easily understand why a company like EA would push for more and more realism, but why is it that, on the whole, this is the only type of sports game available? There are realistic and unrealistic racing games, realistic and unrealistic first person shooters and realistic and unrealistic third person action games in the triple a space and yet the only unrealistic sports game of note in the last ten years (that isn't some sort of future sport) is Wii Sports!

Wii Sports Tennis. Good, but its no Super Tennis!

It is interesting that Wii Sports is also the second best selling video game of all time. So perhaps there is a market for a unrealistic football game after all..?

This Is A Call

I am currently on the lookout for an artist to help me with Salvage! I've given some of the details of of Salvage before, but to give a quick (and very reductive) elevator pitch, the game is basically Spelunky meets Hotline Miami meets Paradroid.

You play as an unarmed robot named "Rootkit". The main aim is to navigate randomly generated spaceship interiors, collective salvage and avoiding trouble. Although Rootkit cannot fire, the robot has the ability to hack and take over any other robot sentry and use them as tools to defend yourself. Here is a gif showing you how it works:

As you can see here, the robot sentry is patrolling the ship, minding its own business, before the player character (the small blue tv faced thing) hacks the AI (by ramming it) and takes it over.

Each of the robots will have different strengths and weaknesses. The player must look for opportunities and take advantage of unique abilities to survive. Here is Rootkit hacked into a different robot type, the Silverback, and using its shield to block an attack.

Finally, the player eliminates the threat using Silverback's rocket fist! As you can see, Salvage only contains place-holder art at the moment. It has a top down view and some terrible perspective art done by yours truly. The initial art direction I was thinking was pixel art with a tone similar to Neill Blomkamp's movies. It can be 2d or 3d, but 3d would take more implementation time which would have to be taken into consideration.

So, if any of you actually interested in working with me, then please contact me at here. I will be asking you to submit an art sample. Also, I can only offer either a percentage of the game profits (if there are any) or pay you a small (negotiable) fee, if things goes well, so keep that in mind before getting in touch.

I'm looking forward to hearing from you all!

So Random...

It seems like I've finished the basics of the my random dungeon generator for Salvage.  The system is super simple but it gives me the sort of control I want out of a spaceship level generation system. As I've covered in more detail in my game design document, the levels are created using 9 x 9 tile sets which are created by hand, that are then translated into tile props unity game objects when generating the level. Here is a sample tile set script. (The 'W's are the wall tiles, the 'F's are floor tiles, the 'P' is a patrol point for the AI system).

The prefab tile sets that are hand crafted in script is a very similar system to the Spelunky method of randomly generating the world, but this system use the drilling method to cut a path to the exit because the system might cut into outer space!

As you can see from the tile set above, it has one single corridor entrance on the right. Essentially the system reads in each tile set edge and then tries to match with any other tile set that has the same edge so they can connect together perfectly, like a jigsaw. Simple really. There are several benefits to this method. It gives me very fine control over the content and also automatically guarantees that the entire ship is reachable without doing any sort of search algorithm. Also, the system allows me to create ship silhouettes:

I've only made a handful of ship layouts (and will probably make a few more before release) but already each of which give me a generated dungeon layout in the silhouette design that I wanted. This is the Freighter layout (above) which is currently my favourite. As you can see, the large main body is separated from the two parallel "engine" tile sets, connected with corridor tiles.

This is the Shuttle layout. It is smaller, and has double wing tips that will have weapons mounted on them. (Each layout with have a ship outline that will be hand drawn by an artists, when I managed to find one, which will help sell the idea that it is a ship). Also, those tiny black squares are actually crates which are laid down as the ship is build.

These warship layouts also show the region system I have implemented. Each part of the craft is given a region number, or code, which the AI use when patrolling, so they stick to their area and don't just wander the entire ship.

I'm very happy with how its all turned out so far. I hope you also like it....

The Designer's Model Versus the Player's Model

There is a simple principle that I discovered in the classic industrial design text "The Design of Everyday Things" about the conversation any designer has with the user (or in our case, the player). This conversation happens through the piece of design being used and is called the "affordance". Quoted from Wikipedia:

"An affordance is often taken as a relation between an object or an environment and an organism, that affords the opportunity for that organism to perform an action. For example, a knob affords twisting, and perhaps pushing, while a cord affords pulling. As a relation, an affordance exhibits the possibility of some action, and is not a property of either an organism or its environment alone."

I'm not sure my knob affords twisting, but anyway, in relating to video games, affordance is the conversation every game has with the player. Lets look at spiny from Super Mario as an example...

In Mario the player quickly learns the main verbs that the chubby plumber can perform (i.e. jumping and running), from initial experimentation with the controls. When looking at spiny for the first time, the spikes placed on the enemy turtle's back informs the player that the base strategy of jumping onto an enemy's head to squash them won't work for this opponent.

Simple right?

This elegant principle is very powerful but rarely actually consciously discussed by development teams when making games (in my experience). I think this is partly due to the fact that making games from well established genres come with certain assumptions about how the player's avatar, opponents and environment will behave. Also (dare I say it?) I think there is a certain amount of reluctance to admit that a piece of art actually has more of a role to play than just to look nice.

Problem arise when certain misconceptions about the rules of the game communicated through the affordance of the enemy characters and environmental layout go on to build a model of the system image that is incorrect:

The player's understanding of how the game's rules function can only be built from playing the game (yes, the player could build a better model by reading the instruction manual, but who actually reads instruction manuals any more) so games have to be careful about what they are saying to the player at all times and not supply misinformation that could cause frustration.

The additional difficulty with this design principle that is unique to game design is that games are supposed to be a challenge. To quote Bernard Suits, playing a game is: 

"To engage in activity directed towards bringing about a specific state of affairs, using only means permitted by rules, where the rules prohibit more efficient in favour of less efficient means."

'Less efficient means' is the important part of that quote in the context of this conversation. The easiest way to win at golf would be to carry the ball and place it in the little hole using our hands, not to walk 500 yards in the opposite direction and attempt to get it in only using long metal sticks. We instinctively understand that if winning at the game is trivial then it becomes boring. So, as designers, we deliberately put rules in place to make achieving the goal of the game more difficult using these 'less efficient means'.

But I think that designers can get 'trying to communicate the rules of the game clearly' and 'creating an interesting challenge for the player to overcome' mixed up and start to obscure how the game's rules work in order to create challenge, which I think is a mistake. (Lets be clear, I mean rules and not information. Hiding information about the game's state is a completely valid design technique, with hidden playing cards in a poker game and a strategy game's 'fog of war' being two great examples of this).

I will always maintain that the player having a misunderstanding about how the internal rules work will always result in a less satisfying experience. I would be happy to be proved wrong on this point, though...

Remember, you are always in conversation with your player, so just be careful out what you say....

Brutal DOOM

So, in-between game development and other things taking up my time I've been spending the occasional lunch (when I can) to play Brutal DOOM. Brutal DOOM is a mod for the original DOOM and DOOM II that takes the original game and adds a host of graphical and gameplay improvements. Check this out:

It's a fantastic mod that adds meaningful additions like the ability to aim vertically and reload. (There are other actions, including a "duck" and "jump" which I have chosen to ignore because they weren't considered when designing the levels) These changes, along with much nicer lighting and some of the most violent and over-the-top gory game permanence (that even puts Hotline Miami to shame) makes this version easily the definitive version of Doom.

The most interest part of this mod is that it actually makes Doom's core gameplay even better. Most pc mods either add graphical enhancements, streamline UI elements, or add new gameplay features, but very few (with the exception of minecraft) revise the core gameplay to such a degree as this. The Brutal mod improves moving, aiming and shooting, adding kickback to the shotgun and reloading to the plasma rifle. Also although reloading and head-shots are a staple of modern fps design, I still find it fascinating that these gameplay elements enhance an older game which was never designed to include them.

DOOM is one of the best first person shooters of all time, I mean, it goes without saying. But one of the key strengths of the game that seems either downplayed or downright ignored by modern game design trends is that its completely abstract with the enemy design. Each monster type serves a gameplay purpose first and foremost. What I find most interesting is that nearly all modern first person shooter studios do not design the game working from these simple principles. Why not? Haven't we already seem enough humanoids carrying semi-automatic weapons?

Anyway, download the mod here. Remember to buy the game first.

Salvage - The GDD

So, I thought I would try something different with my actual current design document, or GDD as the industry likes to call it (bleh). My new game is designed, sort of, and I thought I'd perhaps share this document online so people can get an early insight into the type of game I'm making and I myself can be held accountable to something.

So, check the document out here: Salvage GDD

It should be said that some of the concept art I've used is used without permission from the original artists. In my defence, I have contacted them about using their cool piccies but haven't heard anything back from most of them in over two weeks.

Now, just to be clear, this document isn't finished. Also, this wouldn't be something I'd actually write when working as a designer for a big company, as none of the areas designed really drill down into enough detail to give any programmer a proper specification to work from. But it doesn't need to. I can fill in any blanks while I'm working on it. I think the important thing here is that I have something to work from and to work towards. The game feels more real now I have actually made some decisions about how the game will work and what the vague back-story is. 

I also apologise if its full of typos, but I haven't even proof read it. I can't be bothered.

Oh, and the game is currently called "Salvage".

About My New Game...

Have you ever played Space Hulk: Vengeance of the Blood Angles? It was a great squad based first person shooter which I owned (and still own) on the 3DO, a CD based console from the mid nineties.

This is the cover art for Space Hulk: Vengeance of the Blood Angels. The cover art copyright is believed to belong to Electronic Arts. 

The game was similar to the board game of the same name, but played out in real-time. The player controlled any single solider, from a first person perspective, and would have to pause the game to give orders to other squad members or change which space marine they controlled.

The thing was, this "pause" was actually a limited resource. Time drained away as you frantically scrambled to assign everyone an order before the genestealers started moving on your position again. I always loved this idea (and the game in general) and thought the game was ripe for a re-imagining on a new platform.

So, this was the basic idea for my new game when I first started working on the idea sometime last year. Take the core gameplay of Space Hulk, where you control all squad members by pausing the game and assigning them orders, and mix it with modern rogue-likes like Spelunky or Nuclear Throne.

Things have changed a bit since then....

The game is now more Paradroid than Space Hulk. You now play a robot that can hack other robots. I've ditched the pausing time mechanic, and controlling other squad members. This is one of the luxuries that I can now afford working for myself. I can change the ideas as I see fit without huge repercussions. I can also remain startlingly ambiguous about certain features, because I just don't need to design them yet.

Working as a lead designer on a big project at a big studio in the games industry you kinda have to know all of the answers, or at least come off like you know all the answers, without knowing any of the answers. Making interactive software is always risky and the outcome of any game's design is always unknown. Being able to predict the outcome of a mix of different real-time gameplay systems is like trying to predict when it is going to rain. It becomes very complex very quickly. This is one of the main reasons why innovation is quite scarce in big budget development: It's harder to predict.

So, with my new game I'm trying something a little different. I'm trying to be more flexible about the game design. I am going to make a bit of the game, then play it to see what it's like, and then make a bit more. Hopefully this methodology will make it easier to react to change, and to double down on the bits of the game that actually work. Whether this development model is successful or not will be documented on this website, I guess.

That's all for now, folks. I'm sure my next blog post will actually tell you about my new game...