Game Designers are all on Steroids

Original Author: Claire Blackshaw

Video Presentation: http://www.youtube.com/watch?v=TApXDMckdH0

Capture

Game Designers around the world are addicted to performance enhancing drugs and many of them don’t know it. They are addicted to progression and escalation.

As game designers we are often playing with human psychology and tapping into the various triggers and ticks of human behaviour; our reasons are varied. Some of us want to give the player a roller coaster ride, to make them feel, to make them pay, to get our message burned across the heart but almost all of us want them to keep on playing.

Hiding Shitty Design behind Progression

Capture

Progression, like most drugs, feels really good. It fuels us in a way few other things do. Like a strong sauce or sugar we can use these drugs to hide our less than adequate game design. The game lacks a sense of flow? Make the explosions get bigger and the monsters change colour.

If the moment to moment play isn’t satisfying then often we hide it in the guise of grinding or progression. Playing pointless mini-games, or fighting the same old bosses for the sake of progression. If the only reason your player is doing something is so they can unlock something else, then you have failed.

Use Case: Fixed Narrative

For the discussion I want to separate play into two distinct areas: fixed narrative and free play. The line can be blurred but I will give the definition that a fixed narrative is a authored narrative experience short enough that most players will experience the ending. Two good examples of this are Gone Home and the Call of Duty Campaign.

Pacing, escalation and moments of spectacle are critical limited tools applied with editorial precision to give structure and climax to the authored story. Medical Steroids have a valid use, but it is always short term boost, in a controlled setting and the same is true of progression. In this setting progression is used with a focused purpose and limited span. We do not want to lock the player into a cycle of drug use but instead fuel their single session.

Every challenge should be skippable upon failure, see GTA V as a great example. If the only valid action upon failure is to revert to an earlier portion of the narrative or freeze the narrative then you are only frustrating the player. You are delivering a narrative and you want them to see the ending.

Free Play?

Chess, Spelunky, Starcraft Multiplayer are some great pure examples of freeplay. Every session starts on a level footing, with as a self contained game loop with no acknowledgement of previous time spent playing. Within a single session of play, always complete in one sitting, there is escalation and progression. It is self contained and fuelled by the game loop. Nothing is a grind or progression fueled.

The Many Excuses of an Addict

We want the player to see the content they paid for

Great! If you are a story based game then give them the option to skip, after failure. If you’re a skill based game then your core mechanics and gameplay loop should be exposed from the start with no artificial gating of content. You’re either selling a strong game loop or content, decide which is your focus.

We need to teach the player

Narrative games require only basic instruction and guidance. For challenge driven games teaching can be done in a separate mode which can be skipped or is outside the core experience. Go players are taught the game on a smaller board, with all the same rules. Starcraft has a series of training challenges to teach the core skills required in multiplayer.

We want to acknowledge the players efforts

This is probably the most dangerous and hardest to invalidate excuse. If you reward effort rather than success you are training people NOT to succeed. Worse you are crippling them for the real challenges life will throw at them. Games are as much about enriching the participants as entertaining them. This behaviour leads to stunted individuals who will retreat from reality into endless nights in a fantasy world that is easy, one core facet of MMO addiction.

Stop setting unrealistic goals for the player. Acknowledge the things they DO achieve. The level they did reach, the score they did get, the faster time or other skill based challenge.

Top of Class: Spelunky

I wanted to give this to Starcraft but the laddering aspect gives it a slight taint. Spelunky is pure self contained joy. Unlike a narrative game it does not expect most players to see the end. In fact I would not be surprised if the bulk of the players only glimpsed the second zone, the jungle. It provides an interesting but self-contained escalation of threat both in zone progress and mechanics such as ghost arrival or shop keeper agro. While most sessions are under 5 minutes, a full clear can be about 30 minutes, but doable in under 5 minutes.

Spelunky is a game of challenge with every new play being a fresh but familiar challenge. Experienced players are as familiar with the level generator as the monster patterns. The skill level is immensely deep, after many hours on PC & XBLA I still have not defeated the end boss, let alone the secret hell boss. It is an almost daily ritual for me to log in and do the daily challenge.

I examined the pattern wondering if I was addicted, stopped for a few days and felt no yearning to play. Much like a morning run it had become part of routine which I immensely enjoy, provided mental workout and healthy outlet. After many thousand deaths it still treats me the same as my first attempt, harsh but fair.

Trigger: Desktop Dungeons

Capture

The trigger for this article. I highly recommend you play this frankly amazing game which I can highly recommend. Though after 80+ hours I realised I hated the game, I instantly recognised the symptoms of drug addiction.

I hesitate to write this, because this is an excellent game and the worst drug addicts are AAA studios. I strongly suggest you buy this classic and support this independent developer, but it is a perfect case study having both a drug free and addicted version and is the trigger for this article.

The original desktop dungeons was a freeware game in which each session was a self contained loop. The only hint of progression being the unlocking of more options and play styles. A single session being under 15 minutes typically.

QCF did a wonderful revamp, reskin and general polish of their gem adding a central town, campaign, progression and frankly a drug habit. Now I hasten to add that there is a hat tip to the original in the form of Random Adventures. Though after 80+ hours quests are still dangled in front of me in further ridiculously overpowered dungeon runs with an escalation in monsters, items and complexity.

With no end in sight I’ve now put this game on my no play list. Despite playing the original for much longer because I recognise the unhealthy aspects of the new version.

Original Addict: Dungeons and Dragons

Possible one of the strongest influences on modern gaming DnD has long been a dealer of loot, xp and levels. I’ve ran many a campaign, written self contained convention modules and run many flavours and cousins to the old dragon. A conclusion I reached long ago with many others is that levelling is broken.

GMs will disagree about the sweet spot for characters but most agree somewhere between 5-10 level. Low level characters are underpowered and high level characters are difficulty to contain. The systems and world just cannot contain both extremes sensibly and acknowledge progression at the rate players’ addictions demand it.

The true power of DnD and roleplaying when you speak to long time players though is that one EPIC moment or that amazing story where the game expressed either a true test of skill or a brilliant contained narrative. Both of these are expressed now at conventions as self contained modules which are played in a ~4hr session with no acknowledgement of previous play often with pre-constructed characters or ones generated on a fixed point system, providing either a test of combat skill or a fixed narrative which plays on character and story.

I highly encourage game designers to take a long look at Convention Modules and the design issues they have fixed in the old crack addict that is roleplaying.

Drug Addict: Tony Hawk Pro Skater

Tony Hawk Pro Skater series has some fabulous gameplay which feels great and can have an amazing flow. The balance and longevity of this game is broken by the skater progression mechanic. An entry level skater is woefully underpowered, while a maxed out skater is overpowered negating challenge and breaking the flow. This mechanic is in place so the player regardless of skill will eventually see every level and beat most challenges.

This breaks the level design in many ways and removes what could be a deep skill progression with a highly competitive leaderboard, into something rather absurd with a very thin slice of competition the top 1% of the leaderboard. Think instead how powerful the game could be if there was no progression and every part of the level was balanced for a narrow band of values with skaters providing variety.

Another Topic: MMO & Skyrim

I briefly want to mention the biggest progression addicts in the form of long style roleplaying games and MMOs. They are complicated by the online element and massive scale. This is potentially another article entirely to write. I acknowledge they do not fit well into the current discussion, but I would point to some of the elements discussed in regards to Dungeons and Dragons.

The Exception to the Rule: XCom

These discussion are complex and to acknowledge this I want to talk about one game which seems like an exception Xcom: Enemy Unknown by Firaxis, though most of this logic is valid for the original classic.

  • First campaign is likely a failure in a few hours
  • A single campaign averages around 20 hours to completion
  • Every mission is critical and very few are “easy” or “grinding”
  • No previous campaigns are acknowledged*
  • Campaign is self contained loop designed for multiple plays
  • Progression can be lost with a single bad choice

The last two points are the most critical, and what separates them from a fixed narrative or a game of addiction. The core systems are in play from the start, and the permadeath and consequence make each action significant. This game blends a fixed narrative into its contained loop but I would argue for most players it is a closed loop of free play.

Conclusion

Stop using progression and escalation as a crutch and instead use it as the limited resource it is with respect towards your player. Everything discussed here is guideline, obviously things are complex and multifaceted and I welcome discussion in the comments.

“Unearthed: Trail of Ibn Battuta” game development analysis

Original Author: Ameen Altajer

SPOILER ALERT!!

This game development review has many spoilers on the game, if you didn’t play the game yet and you’re intending to play it soon, then you may want to skip reading this until you play it.

 

 

Prologue:

“Unearthed: Trail of Ibn Battuta” is a game that has been developed in the Middle East, I go on and analyze everything about it from a game development point of view, criticizing storyline, game design, implementation and few other elements. This game tends to be one of the very first games to come out from the region so I wanted to go and state my findings in a very detailed manner, this article is taken from my website http://www.ps3code.com.

 

1. Introduction:

“Unearthed: Trail of Ibn Battuta” is a 3D adventure platformer game developed by the Saudi company Semaphore, the game is probably one of the very first games to be published on major networks like Steam, Playstation Network (PSN) and the like. The game was promised to support a variety of platforms ranging from mobile to consoles, the game has been delivered on some platforms and failed on some, the game also supports many languages, but noticeably Arabic text and dialogue.

Now as a game developer from the Middle East, I truly respect the endeavour, it’s a good opportunity for us – game developers of living in this region – to go and analyze what Unearthed has done wrong and – rarely – done right. I’m a game developer myself, and this game development analysis reflects my thoughts and comments of the game according to the humble experience I had in making games and in using the decent Unity game engine for quite sometime.

I want to clarify that I’m not criticizing the game because I want to, but I had to, all along from the time the game has been disclosed to the public, to the time it was published on Steam and other platforms, I just had to state many comments regarding many aspects ranging from story, game design, and implementation details. I wanted to share them here because I so believe that reiteration and taking constructive criticism is the best way to achieve accomplishments. I’m sure that the guys at Semaphore will be benefited from this detailed analysis, as I cover almost every important game developments aspect.

 

2. Story, dialogue and the musical score:

The main character in the game is Faris Jawad who is the protagonist of the game, along with his sister Dania they go ahead and try to follow Ibn Battuta’s trails to find out the secrets that he’s left behind, they travel to Morocco as well, where the story and some gameplay takes place too.

Now if you ask me, I would say that it’s from the first glimpse, I would definitely say it’s the Arabic version of the Uncharted franchise, more of a replica, and to your surprise that’s exactly what has been said all over the world, words of gamers and game developers.

Looking at the similarities between Unearthed and the Uncharted series – and there are many – you have to admit that the game has taken a huge chunk of ideas related to story, dialogue and game mechanics from the Uncharted masterpiece.

Treasure hunting is a good and – probably a very used – storyline idea for many games including Uncharted, Tomb Raider, but what makes those games so special is that they’ve taken the idea of “searching for a treasure” and twisted it a lot by utilizing fictional characters, theories and by encountering demons and extraordinary creatures along the way. Now the unique game mechanics in both of the previous games give them a different taste and an atmosphere even though in the end they’re both just adventure platformers.

Taking the short gameplay of “Unearthed: Episode 1″ into account, I don’t think that the game succeeded in delivering what you expect from an “Episode 1″ kind of a game. The beginning has used a very common storytelling method that – again – has been used by Uncharted, that is kickstarting the game with a scene that is almost near the ending while being narrated by the protagonist, then by getting to a critical scene in the game, suddenly you’re taken back to the very beginning portion of the story, where you try to figure out how you got to that critical scene of the story, pretty interesting story progress if you ask me.

One more similarity with Uncharted is a scene in the very beginning where you get to your treasure, and suddenly the place is filled with enemies and you have to make your way back to the entrance to save your sister, this is exactly what happens in Uncharted: Drake’s Fortune.

The car chase scene was a typical replica of Uncharted; I’ll just let you decide according to the image below:

Figure – vehicle-chasing level

Episode one didn’t deliver in terms of story, normally you want to be intrigued and excited about the ending so you would want to play the following episodes, Unearthed did the quite opposite, the ending was so normal that it has ended with a very short yet buggy car chase, I didn’t find the ending exciting, I honestly felt great that this was the end to a buggy game I was not satisfied paying five dollars on.

The dialogue is really horrible and was not to the level I was expecting at all, I’m talking about voice and acting quality, and what personally shocked me the most is when I read that the voice acting has been done in Hollywood! You would think that the name Hollywood would ring when quality is about to be seen, but hey that’s totally unlike what Unearthed has delivered. The Arabic voice acting is so bad that I thought it was done by a news anchor in the beginning, there is absolutely no immersion whatsoever in the voice act, the voice performance made me laugh many times, particularly when hanging on a bridge or climbing a platform, apart from that, the quality of the Arabic dialog is very low, material-wise and sound-wise, for a second it felt they were recording the act underwater.

Not only that, the content of the dialogue is really boring and was not immersive at all, I had the urge to skip most of the cut scenes, they were really “artificial”, I’m telling you no feelings at all. There were endeavours where they wanted to add a bit of comedy in the dialogue, but I personally felt it was vague and not funny, probably because the performance didn’t nail it, this also mimics Uncharted, where the protagonist Nathan Drake is a really funny guy in almost every situation, even risky ones, now if you compare Faris Jawad and Nathan Drake, you’ll tell for sure that there are very major similarities between the two, not only looks that are the same but even the sarcastic attitude is very similar – or at least it’s what Semaphore wanted to achieve.

Figure – lame jokes are not funny

Figure – Low quality cut scene and scattered colors

What was even more horrible is the pronunciation of the Arabic language is, it was really bad and had many mistakes, this gives you the idea that voice actors came unprepared and the director just wanted the session to finish, I can say it was done without even stressing on act quality.

I personally think that choosing native Arabic was a bad choice for the game, if this was an old-themed Arabian game then I would agree on the language choice, but since this game has taken place in the modern era, it’s totally not fit.

Language is not only the problem that I had but the sounds of weapons, explosions, enemies and almost every sound effect is low on quality, they felt really cheap as if they were extracted from old games like Counter Strike just to fill in.

Not everything was a downer for Unearthed, the musical score felt genuine and was a total fit especially when you visit Morocco in the game, but it was really bad when a specific scene comes up and you’re chase a thief, the score was cold and didn’t fit the atmosphere and the “intense” situation.

 

3. Game design:

Unearthed’s game design was a disaster from all angles. Character movement, combat, puzzles and almost every aspect was greatly flawed.

The camera system was an issue for me, controlling the player movement and the camera at the same time moves the character in a direction I never intended it to, this created a lot of issues while being in combat, especially where you needed to be quite fast in movement response. Even though it’s a platformer, platforming was not satisfying; your character doesn’t do the animation transition smoothly, especially on inclined surfaces and stairs.

Camera placement was just crazy, there is a point where you have to cross two points while hanging on a rope, the twist is to time the movement correctly so you don’t get hit by the shots, to my disappointment, the camera is placed in a position that you can’t determine how far you should advance in the rope to time your movements, I have no clue if this was intentional or not, but it was not a convenience nor a fair challenge. The camera system was really rigid, I didn’t like that the game didn’t switch camera positions smoothly, smooth transitions are definitely needed for such a platformer with a big environment where you have multiple points of focus.

Figure – bad camera angle placement

Figure – bad camera angle placement again

Traversing special objects like bridges, ledges and ropes while platforming just felt extremely unnatural and boring. Talking about boring, walking for a long time doesn’t sound very interesting when you realize you are forced to do it for almost ten minutes straight, and that’s the case for one of the level’s in Unearthed, it was really boring to keep my finger on the forward button all this time.

You can see a lot of enemies changing direction by a sudden animation and a direction change, this was really horrible to accept, because as a developer and a fan of this genre, it’s important to me that I get the platforming feel right in order to feel comfortable traversing the world, and so it’s really significant that you semi-perfect the very basic elements of platforming like movement and animation, and to my disappointment the guys at Semaphore didn’t share the same view, the platforming machinery was very bad for the experience and didn’t not bring joy. Character animations were poorly done, for more than a single moment I thought I was a playing a Playstation 1 (PSX) title. The way the protagonist throws grenades was very artificial and had little to no connection to being realistic.

Talking about the sound aspects of level design, I don’t really believe that the Semaphore team appreciates 3D sounds, the worst part of being in a combat is that you don’t know where the shots are coming from, the fire sound was implemented as a 2D stereo sound – or the 3D sound was mistakenly sat up, so when you’re in a combat there is no way to tell which direction the fire is coming from.

I do understand that the red arrow tells you the direction of the shots, but it’s normally not enough for players who are used to relying on sound feedback for combat movement, even if you’re a visual guy, the arrow tracking system – that is composed of pieces – is not helpful that much, just think about it, you as a player surrounded by a 360 angle, do you think that you would be able to tell where the enemy is by looking to one of the few direction arrows.

Figure – enemy directions

Figure – directions again

Sound was a big a problem here, especially that I was expecting some AAA quality work, few things would just frustrate you in just few minutes, there is a specific mini-mission where you have to break few jars to get something that is inside, now while breaking those jars, you can hear the protagonist making the same sound all over again, the lack of variety here really degrades the quality of the game and hits the experience hard.

This wasn’t the only flaw in sound; the looping of the musical score was bad as hell, ever imagined as if you’re playing a song on loop mode? That’s exactly what’s happening with the musical score, the score is being replayed directly, and you can hear the cut in between the end of the score and its beginning being played again, this gave me the impression that those little details didn’t matter that much to the game director, I don’t have to state how important music is, as it controls feelings and they should’ve at least done that right.

The checkpoint system was one of the most frustrating parts of the game, that is when you finish a very hard poorly designed place in the game, you expect the game to save your progress, but instead I doesn’t, in fact, checkpoints were poorly placed in the game in a way you as a player wouldn’t really care about the checkpoint saving system anymore because you already anticipate yourself restarting the checkpoint anytime soon.

There is a specific scene in the game where you have to use stealth to silently kill the enemies, I didn’t understand why the developer forced the movement mode to switch to stealth mode, to me there was no sense of challenge here, I was expecting the developer to ask the player to focus on his input to slowly use the controller to silently get to enemies and kill them quietly, but on contrast, you can push your controller all the way to the top and you’ll get to enemies quietly, which obviously killed the joy of the challenge in hand. Something similar happened when you get near ledges, you simply can’t fall and die, where is the fun of being careful around those then? Case closed.

Figure – movement forced to be in stealth mode in here

Collecting pieces was one of the very first game challenges, the placement was somehow wise, and I’m saying somehow because the placement of some collectibles was smart, in a sense the developer wanted to teach the player the basics of few platforming skills such as hanging on objects and jumping among ledges, as for the rest for collectibles, they were scattered in some weird places, and you get to see the location of the collectable when you ask for a hint, to me this was more than sufficient, probably ruined a bit of the scouting experience. I was not happy at all with object placement, especially that part where you pick up the fire to use it to light the way, the object was placed in a place that you as player can’t get on yet the space tell you to please get up so you can pick up the item.

Figure – bad object pick up location

Many elements were not realistic; shooting barriers doesn’t destroy them but hey look! Kicking them does the job, doesn’t sound reasonable to me.

There is a specific puzzle where you can use a remote control car to help you traverse into the level, that specific idea had no place within the context of the game, everything feels disconnected, I don’t even know how the protagonist got the car to the ground or how he picked it up again, these ideas which could’ve been iterated on to be acceptable somehow were very disconnected and didn’t really fit into the atmosphere of the game. Apart from the idea, controlling the car was just bad, it was more of moving a brick rather than a car, and these noticeable details were disregarded horribly.

Figure – remote control car

While in combat, aiming doesn’t feel natural, I was really expecting a decent firing system that includes good feedback support and some vibration. Control while aiming is not really that professional, every slight movement can take the aim crosshair away from the target, I played the game with the “manual aiming” system, I don’t really know if the automatic is much better in terms of providing those missing elements, but I don’t think so.

There were few useless game mechanics in the game, taking cover for example, when an enemy takes cover from the players, throwing a grenade in front of the barrier kills the enemy straight, I really don’t see the point getting behind a cover if it doesn’t – somehow – protect you, this worked fine against bullets but as mentioned didn’t work against grenades.

The “street fighter” combat mode doesn’t really serve the genre, more to that, it was broken. What happens is, there are specific key moments in the game where you have to fight few enemies in a hand-to-hand fight, you can punch and kick, but the problem is that you can’t block kicks, I’ve personally tried to use every single button on my controller but I failed to black kicks, this got me the impression that even those important game design details are not counted for.

Figure – street fighter shot 1

Figure – street fighter shot 2

Figure – can’t block kicks

There is a specific location in the level where you have sharp pieces swinging left and right, there were many issues with such a machinery, one is such a machinery didn’t match the environment it was placed in, you can clearly see that the corridor where this killing machinery was in is almost empty, apart from that the velocity of the sharp things being swinged was totally not natural, to me this was just cheap animation with no feel of physics to those objects being swinged.

If you’ve played “God of War” you probably remember a specific level where a lot of giant burning rocks are falling and coming your way and you have to tackle them to move forward. Guess what? Unearthed has the same game mechanic, just made me scream “God of War” at that specific moment.

I think Unearthed’s input could have been utilized much better, especially when you have a controller in your hand with quite many buttons, input was laggy a bit, I had to press and hold the button more than a single time to get the action I needed, and no my controller is not malfunctioning.

The adventure challenges were unacceptably short, an example is when you catch the thief you were after earlier, you are supposed to flee the scene before the cops catch you, and all it took me was just a jump to the next building, just a total of fifteen seconds!

 

4. Implementation:

The first thing that hit me bad when I played the game was the setting menu, I went there to change the resolution to a higher one, and whenever I chose the option next in line, the resolution changed directly and the game windows got reinitialized, this is just bad, switching resolution directly made me frustrated because I had to wait for my monitor to change its resolution almost ten times, traversing weird resolutions until I got to my desired one, and the worst thing happened when I passed a couple of unsupported resolutions, turning my screen to solid black. Not only that, when I got to my desired resolution, everything got reset when I wanted to reload the game for my second game session, this bothered me… a lot.

Rag doll physics was nice but was not done correctly, when you throw a grenade, you can see killed enemies landing in a weird shape like the screen below, setting environment’s colliders to be more tolerant to such physics behaviour, or tweaking the explosion force could have been potential workarounds for such issues.

Figure – bad rag doll landing

The reflection shader was noticeably incorrect, rotating the camera allows you to see the defect clearly, you would think it’s a shadow following you but it’s just your reflection on super clean surfaces!

Figure – reflection shader issue

Figure – reflection shader issue again

Coming back to Arabic, I do really respect the effort that Semaphore has put to incorporate Arabic text within their game, after all it was a must, but they’ve shipped the game with very noticeable hurdles nonetheless. Arabic subtitles were not synced with the dialogue, I’m not sure if it happens with other languages, what’s even worse is that Arabic was not correct syntax-wise in few scenes, look to the shot below:

Figure – wrong Arabic letters representation

And in few specific scenes, the Arabic subtitles went over and crossed the screen’s bottom, just like this one:

Figure – subtitles crossing the screen

I’m not sure how this bypassed the attention of quality assurance – if they had one!

I don’t know what the game is doing when you move to another screen or exit the game, but it’s too slow to react to my actions, choosing to exit the game or skip specific scenes takes a noticeable while, no clue about what this serves exactly, I can’t see any activity of deallocating resources or disk access throughout this process.

Along with scattered bugs here and there, like the one when you pause the game, the musical score being played stops unexpectedly, this is seriously one horrible bug, there was a moment where I was really tasting the music and for a reason I had to pause the game, suddenly no music for me.

Colliders are poorly done, there are moments when you get in a good position and you want to shoot enemies, but you can’t, the poorly placed invisible walls are to be blamed – and the level designer of course, I honestly think this killed the experience for me, there was no point of getting in a good cover.

Figure – invisible walls blocking my shots

Something almost serves this case happened to me when I was driving the car in the last scene, somehow the car got on top of the pavement and just stayed there without being able to come down, the colliders have been poorly place even in such a level where physics can take your objects somewhere you didn’t intend.

Figure – car-chasing level

Figure – car stuck bug

The GUI artwork is probably too raw and basic, I didn’t like it at all, as it was done really fast to cope with a deadline, it had the very same feel of Unity’s plain default settings.

Models were kind of not consistent in terms of size relative to the world, many objects we bigger or smaller to other objects, one noticeable sample was one of the submachine guns that you can use, the size of the gun was big that it felt so weird when you’re aiming down the sight.

I don’t have much to talk about the artificial intelligence (AI) of the game, it was basic and got the job done, most of the enemies were doing basic behaviours like wandering, shooting at me, but no sophisticated behaviours.

Semaphore couldn’t deliver to the other promised platforms, but nevertheless they had major problems on the platforms they managed to deploy to, such as Mac and iOS. I’ve tested the game on my friend’s iPad, and it was really slow, laggy and full of fatal errors that caused the application to exit unexpectedly after moments of inconsistent frame rate.

I was not impressed with this at all, because I do understand that running the game on a mobile device is a huge challenge, it requires fine performance tuning in order to have the same experience on such a low-speced device, other than this, other elements like input, GUI, Heads Up Display (HUD) and the akin must be suitable for such a platform. Publishing your game to platforms that your engine supports isn’t just enough for you to decide if you should consider porting your game to them.

I was really happy when I knew that Unearthed crew decided to go with the Unity engine to create their game, but after trying the game now, I can say that I’m not happy with what Semaphore has done technical-wise, allow me to explain more.

Unity is a mature 3D game engine, and there is no need for me to explain how mature Unity has come along the past years, there are decent titles that have been produced wit Unity, and so it’s proven to serve modern games and such a genre, but Semaphore begs to differ in this, why you ask? Well, apparently the Semaphore team is switching to Unreal’s UDK to create “Episode 2” of Unearthed; this was – to me – the worst decision ever made, why you ask again? Well, this means that whatever technology Semaphore has built has just became useless, and now they’ve got to rebuild the technology with a new toolchain, this is going to be a decision that they’ll be paying for a lot, in terms of duration and efforts.

As a Unity developer, I do believe that if Semaphore’s crew went back and reiterated on their Unity technology I’m sure they’ll enhance the look and feel of their game’s main strength points like platforming and combat, but instead, adopting a new technology means that this all has gone to waste.

Unearthed’s issue is not Unity; it’s the lack of ingenuity in game mechanics, and the horrible and buggy implementation. I’m not even sure if Semaphore has tested their product “Unearthed”, it’s full of obvious bugs.

 

5. Artwork and visuals

I was okay with the visuals of the game but not impressed, for a first title that was more than okay for me, the following snapshot that shows how beautifully the light penetrates the, and few cool additions to the scenery. Morocco level was very nice in visuals.

Figure – beautiful market scenery

Figure – cool environmental elements

The environment was nice, the first indoor level might not give you eye candy feel but visiting the temple definitely opens your eyes for what Unity and Semaphore are capable of, the shiny golden color was all over the place, gave me the feel that I was really in a place that held treasures, but most of the environment felt dry with very few objects, the game definitely lacked a lot of polish in terms of level design and object placement.

Figure – indoor level

Figure – cool environment in the temple

I’ve noticed that – as I said earlier – objects were slightly non-consistent in terms of size, objects were not following a specific scaling system. I really loved the taste of shaders being used in the game, even though as I mentioned earlier, the reflection shader had a noticeable problem, but all in all the shaders being used were cool. I honestly didn’t like the water system, seems very doll and superficial, didn’t look like a modern water system; Semaphore’s crew should’ve worked on it better, or at least got a plugin from the Unity Store.

Random people and characters share the same face most of the time, I’ve seen this guy like a million times across the level.

Figure – face redundancy

Figure – face redundancy again

Cut scenes were horrible and had very low quality to them, lips were not synced to dialogues and the low texture work gives you a terrible look on the materials being used on object are character characters, other than that, specific motions were more than just artificial, were really bad, like when a character picks up the phone, the way the character holds the phone is just awkward.

Figure – bad texturing

The artwork in Unearthed had a good start, but took a wrong direction with few incorrect decisions, but it was okay as a whole.

 

6. Cost, quality and gameplay time:

Normally when you’re spending five dollars – on Steam – on a game, you wouldn’t get a triple A title, but you at least would expect something with good quality.

This was probably the worst mistake Semaphore has done, pricing their game to five dollars, that was completely wrong, for such a buggy game, broken game mechanics, horrible sounds and dialogs, very unstructured ripped off story and game mechanics, short gameplay time of less than an hour… I’m really sad to say that this was the worst five dollars I’ve ever spent on a game, I really expected more from Semaphore after hearing so much about them. Especially the gameplay time, I don’t know why the developers priced such an uncomplete game for five dollars, and it’s only a single episode, that has no proper ending.

 

7. Notes and updates:

Now when I was about to finish this game development analysis, I was notified by the developers that they are releasing an update that would turn everything around in Unearthed to such a better game. Now while this is a very good move, I do disagree on few things.

Normally when you release updates, you don’t adjust game design elements like game mechanics and other intensive elements of your game, because this makes the experience different for your audience. I was going through the change list in the latest update, and I saw one change where they fixed the part where you can fall into a pit – as I talked about this in my analysis above, this ruins the experience for people, because this means you have to play the game again to experience more stuff on the actual game play, and yet it’s not new content. Updates are supposed to fix technical bugs and enhance content, not change the experience.

Again, I do respect the team’s efforts to follow up on their game by making it better, but planning beforehand would have definitely given it a better head start.

I’ll be back to update this game development analysis with more material when I have the chance to give the game another shot, and I’ll update the article with more findings.

 

8. Conclusion

“Unearthed: Trail of Ibn Battuta” didn’t deliver as I – and many others – expected, but I’m sure the team by now has a better understanding of game design and implementation, this will definitely give them the push they need to make better games, I’m sure that the Unearthed team are going to be so open to my criticism, coming from a game developer that belongs to same region.

I hope you found this article beneficial to you, in terms of game design, programming or whatever you relate to.

Make sure you contact me for any thing related to this on ameen [ @ ] ps3code.com.

Good luck in your future endeavours, Semaphore.

Ameen

How to Build an Indie Arcade Cabinet

Original Author: Ben Serviss

(This post was written by my Studio Mercato colleague Jon Stokes, and seemed like a great fit for something different!)

Back in July of last year, Studio Mercato was offered an opportunity to exhibit our game Crystal Brawl on an actual freaking arcade machine in a charming, tatted-up dive of a music venue in Brooklyn called Death By Audio. The one caveat: we had to build it ourselves. Obviously we jumped at the chance, and thanks to the excellent Mark Kleback of DBA, construction kicked off in August and was completed the following December.

On December 7, we held an opening party for the Crystal Brawl cabinet and another cabinet, built by Dylan McKenzie & Friends, for their awesome minimalist sports game Field-1. We dubbed the event Deathmatch by Audio, and there’s a heartwarming account of the event over at Indie Statik.

We’re planning a Deathmatch by Audio II on January 31st (be there!), but in any case, both games will be on display at Death By Audio until the end of January.

IMG_0907

In this post, I want to share with you my process of designing and building our arcade machine. This is a how-to, but I won’t be going into a ton of detail on every aspect of the build. Instead, I’ll share the wealth of super valuable links I amassed while building the cabinet.

If you have any specific questions, feel free to drop me a line at jon[at]studiomercato.com. Let’s get started!

Design

First off, let’s talk about the game. Crystal Brawl is a 2v2 local multiplayer action/sports capture-the-flag hybrid in the same-ish genre as Hokra and Slash Dash. We needed controls for four players, and I wanted to go with three buttons per player, even through Crystal Brawl only uses two. I told my teammates we should do this to make the cabinet reusable, but the truth is I just wanted to be able to emulate (and pay homage to) NFL Blitz ’99, the defining arcade machine of my youth.

The cabinet needed to be modular for ease of transport, as we didn’t want to have to rent a U-Haul every time we wanted to move it. To this end we split it into three parts: top, bottom and control board.

Making it modular like this allows it to fit easily in a small SUV, or even spread across two taxi trunks, and having a separate control board affords us the opportunity to bring it to meetups or game festivals. The control board connects via USB, so it will work on any ol’ computer.

Print
Having a general idea of what we wanted to create, I set out to look for similar cabinet builds. You can find a plethora of detailed build plans for popular arcade machines at Jakobud.com, including Donkey Kong, Pac-Man, Q*Bert, and The Simpsons, the last of which I used as a reference for the four player control board.

Jakobud’s plans were helpful for general dimensions of many a cabinet, but eventually I found the even more useful LuSiD’s Arcade Plans.

LuSid’s was a step up because they showed the layout of each piece on 4’x8′ sheets of plywood, which made it easier to conceptualize every piece of the machine and how they would come together.

In the black and white diagram below, you can see the final profile mockup for our machine. Its depth from front-to-back is about 10″ less than similar cabinets that use CRT monitors. And, as you can see, it splits into top and bottom components. The rest of the pieces (not shown here) were kind of measured as I built, by constantly referencing LuSiD’s plans.

Materials

The total cost of the machine came out to $665 smackers, which was more than I expected, but a reasonable price for your very own arcade machine. The most expensive parts were the joysticks, I-PAC control board, computer and wood. Luckily we didn’t have to drop money on an LCD monitor or speakers since I already had those.

We also dodged a bullet with the plexiglass, which I used to cover the control board and the screen, and to hold the marquee in place. It would’ve cost around $100 for a 4’x4′ sheet, but I found one at Film Biz Recycling and there was no price marked on it. When I took it to the checkout to ask the cost, to my surprise, the nice lady quoted me only $3. Even after her colleague and I realized that she had originally thought it was a piece of cardboard, they didn’t want to go back on their word, so $3 I paid. Below is a list of everything that went into our cabinet.

CBCabinet-03

The Electronics…

The Wood & Hardware…

  • 2 4’x8′ sheets 3/4″ plywood or MDF
  • 4’x4′ sheet 3/8″ plexiglass
  • Wood glue, wood filler
  • 1 1/4″ wood screws
  • T-Nuts, to bolt top and bottom pieces together
  • Zip ties
  • Gallon of latex paint
  • Quart of Kilz primer

The Tools…

  • Jigsaw
  • Cordless drill
  • Standard spiral wood bits
  • Forstner or Masonry bits, for drilling plexiglass
  • 1 1/4″ wood spade bit, for drilling button holes
  • Carpenter Square
  • Measuring Tape
  • Wood clamps (Irwin quick grip style are the best)

Construction

I won’t go into a lot of detail about wood cutting and assembly, as there are good accounts of the process here and here. Don’t be afraid of the master wood-working techniques in that second link, like lots of router work and fancy joints. If you have a steady hand and you take careful measurements, you can get by with just a jigsaw and a drill.

Crystal Brawl arcade cabinet

Plexiglass is a very fickle mistress and you’ll quickly find she’s much less forgiving than wood. Regular drill bits won’t work because their angles are too aggressive – they’ll push right through just when you start to drill, and crack or chip the plexi.

You want to pick up some Forstner bits, or if you can’t find those, masonry bits. Drill slow and put a couple drops of lubricant on the tip of the bit before you begin. I used bike chain oil.

Also, remember to never take the protective covering off of plexiglass until you are finished cutting. It prevents scratches and reduces the likelihood of cracks during cutting and drilling.

For a simply grand article on how to wrangle plexiglass, the scrupulousness of which gives me goosebumps, see this.

Control Board

This was the most fun part of the project, maybe because I was able to awaken my long-dormant inner electrical engineer (I did plenty of custom car audio installations in college, so I missed playing with wires).

The brains of the control board is Ultimarc’s I-PAC2 USB interface, which lets you turn button and joystick signals into key presses on a keyboard.

The I-PAC2 is really meant for a two player control board, but because we have so few inputs per player, we were able to stretch it to work with four. Once it’s set up, you can plug it into any computer via USB and simulate a standard keyboard. You can use Ultimarc’s Interactive Panel Designer to lay out your control board and program key assignments for each of your inputs.

whatever

Mounting the buttons and joysticks and wiring the control board will take way longer than you think, so pull up a chair, pour yourself a cup of coffee or beer and clear your docket for the next four or five hours.

IMG_0861

All of the buttons come with plastic nuts that tighten from the back and make easy work of mounting. The joysticks are tougher. Each joystick has six mounting holes, and most people drill down through the top of the control board and run carriage bolts (the ones with a smooth rounded top) through and secure them from the bottom. This is definitely the most reliable mounting method. Your joysticks won’t budge.

In my case, I wasn’t completely sure of the angles I had chosen for the two outer players’ sticks, as they seemed a little aggressive to me despite keeping in line with other builds. I wanted to be able to rotate them later if I decided they didn’t play right.

So on each corner, I used a flat washer, a lock washer, and a 3/4″ #8 screw, coming in from the bottom, that I knew wouldn’t penetrate the top of the surface. It turned out to be very sturdy, and my fingers are crossed that it stands up to heavy use.

arcade cabinet controller
For wiring, there are three terminals on the microswitches used for the arcade buttons and joysticks. On the I-PAC, there is a terminal for each assigned key press. You’ll want to run the Normally Open (NO) terminal on your button or joystick’s microswitch to its corresponding input on the I-PAC. Then you just daisy-chain all of your grounds together and connect them to the ground input on the I-PAC. You’ll never use the NC terminal on your buttons, so you can effectively ignore it. For more info on wiring, bada bing.

Creating a Self-Sustaining Machine

Any computer that’s going to be used as part of an exhibition needs to be able to handle tasks like automatically restarting once a day and rebooting if the game or program crashes. In our case, there also needed to be macros for restarting the game and restarting the computer itself that are accessible by button presses on the control board, so you can reboot the game without having to reach around behind the machine and access the computer.

IMG_0855
And so, on the Crystal Brawl cabinet, there are two super-user buttons hidden on the side of the control board. One is meant to restart the game, and one restarts the computer. Each one triggers a keyboard shortcut that activates a script to accomplish its task. I used AutoHotkey, an amazing piece of software for Windows that lets you automate all sorts of tasks like user input, opening and closing documents, file and folder manipulation etc.

Because Crystal Brawl is an HTML5 game, it runs in the browser. The script to restart the game also starts the game. In a nutshell, it closes Chrome, then reopens Chrome to a specified link where our game is publicly hosted, and then puts Chrome into full screen mode. This script is activated by pressing the restart game button on the control board.

Here’s what it looks like:

#SingleInstance Force
SetTitleMatchMode 2
WinClose Google Chrome

Run https://whereever-your-game-is-hosted-on-dropbox.com

WinWaitActive, Google Chrome
Send, {F11} 

A second script, which boots automatically when Windows starts, constantly checks to see if Chrome has crashed, and if it has, it runs the Restart script. Crystal Brawl crashes pretty infrequently, but when you have a game up and running 24/7, you need to have these kind of precautions to make sure it runs smoothly.

This script is a little hacky (in a fun way!) as I couldn’t access lower level info in Chrome via AutoHotkey to be notified when it crashed. It works by taking five color samples every three seconds. If they all match the background color of the famous “Aw, Snap” Chrome crash screen, it restarts the game.

Here’s a peek at the script:

#SingleInstance Force
CoordMode, Pixel, Screen

;;sample a few points on the screen to see if they match the color of the chrome crash screen
Loop {

	sleep, 3000

	Loop,5 {

		y := a_index * 100
		PixelGetColor, Color, 100, %y%
		;MsgBox Color: %color%.

		;;background color on chrome crash page - 0x403023
		if (Color != 0x403023) {
			break
		} 

		if (A_Index = 5) {
			sleep, 3000
			Run C:\Users\User\Desktop\restartCB.ahk
			sleep, 10000
			break
		}

	}

}

For more tips on how to keep your installation up and running around the clock, check out this guide for Windows, and this one for Mac.

And that’s about it! It took a lot of time, but the payoff was totally worth it.

If you are planning your own build and you want to have a chat, please shoot me an email at jon[at]studiomercato.com or hit us up on Twitter at @StudioMercato!

Building the arcade

How to Build an Indie Arcade Cabinet

Original Author: Ben Serviss

(This post was written by my Studio Mercato colleague Jon Stokes, and seemed like a great fit for something different!)

Back in July of last year, Studio Mercato was offered an opportunity to exhibit our game Crystal Brawl on an actual freaking arcade machine in a charming, tatted-up dive of a music venue in Brooklyn called Death By Audio. The one caveat: we had to build it ourselves. Obviously we jumped at the chance, and thanks to the excellent Mark Kleback of DBA, construction kicked off in August and was completed the following December.

On December 7, we held an opening party for the Crystal Brawl cabinet and another cabinet, built by Dylan McKenzie & Friends, for their awesome minimalist sports game heartwarming account of the event over at Indie Statik.

We’re planning a Deathmatch by Audio II on January 31st (be there!), but in any case, both games will be on display at Death By Audio until the end of January.

In this post, I want to share with you my process of designing and building our arcade machine. This is a how-to, but I won’t be going into a ton of detail on every aspect of the build. Instead, I’ll share the wealth of super valuable links I amassed while building the cabinet.

If you have any specific questions, feel free to drop me a line at jon[at]studiomercato.com. Let’s get started!

Design

First off, let’s talk about the game. Crystal Brawl is a 2v2 local multiplayer action/sports capture-the-flag hybrid in the same-ish genre as Slash DashWe needed controls for four players, and I wanted to go with three buttons per player, even through Crystal Brawl only uses two. I told my teammates we should do this to make the cabinet reusable, but the truth is I just wanted to be able to emulate (and pay homage to) NFL Blitz ’99, the defining arcade machine of my youth.

The cabinet needed to be modular for ease of transport, as we didn’t want to have to rent a U-Haul every time we wanted to move it. To this end we split it into three parts: top, bottom and control board.

Making it modular like this allows it to fit easily in a small SUV, or even spread across two taxi trunks, and having a separate control board affords us the opportunity to bring it to meetups or game festivals. The control board connects via USB, so it will work on any ol’ computer.

Jakobud.com, including Donkey KongPac-ManQ*Bert, and The Simpsons, the last of which I used as a reference for the four player control board.

Jakobud’s plans were helpful for general dimensions of many a cabinet, but eventually I found the even more useful LuSiD’s Arcade Plans.

LuSid’s was a step up because they showed the layout of each piece on 4′x8′ sheets of plywood, which made it easier to conceptualize every piece of the machine and how they would come together.

In the black and white diagram below, you can see the final profile mockup for our machine. Its depth from front-to-back is about 10″ less than similar cabinets that use CRT monitors. And, as you can see, it splits into top and bottom components. The rest of the pieces (not shown here) were kind of measured as I built, by constantly referencing LuSiD’s plans.

Materials

The total cost of the machine came out to $665 smackers, which was more than I expected, but a reasonable price for your very own arcade machine. The most expensive parts were the joysticks, I-PAC control board, computer and wood. Luckily we didn’t have to drop money on an LCD monitor or speakers since I already had those.

We also dodged a bullet with the plexiglass, which I used to cover the control board and the screen, and to hold the marquee in place. It would’ve cost around $100 for a 4′x4′ sheet, but I found one at Film Biz Recycling and there was no price marked on it. When I took it to the checkout to ask the cost, to my surprise, the nice lady quoted me only $3. Even after her colleague and I realized that she had originally thought it was a piece of cardboard, they didn’t want to go back on their word, so $3 I paid. Below is a list of everything that went into our cabinet.

The Electronics…

The Wood & Hardware…

  • 2 4′x8′ sheets 3/4″ plywood or MDF
  • 4′x4′ sheet 3/8″ plexiglass
  • Wood glue, wood filler
  • 1 1/4″ wood screws
  • T-Nuts, to bolt top and bottom pieces together
  • Zip ties
  • Gallon of latex paint
  • Quart of Kilz primer

The Tools…

  • Jigsaw
  • Cordless drill
  • Standard spiral wood bits
  • Forstner or Masonry bits, for drilling plexiglass
  • 1 1/4″ wood spade bit, for drilling button holes
  • Carpenter Square
  • Measuring Tape
  • Wood clamps (Irwin quick grip style are the best)

Construction

I won’t go into a lot of detail about wood cutting and assembly, as there are good accounts of the process here. Don’t be afraid of the master wood-working techniques in that second link, like lots of router work and fancy joints. If you have a steady hand and you take careful measurements, you can get by with just a jigsaw and a drill.

Plexiglass is a very fickle mistress and you’ll quickly find she’s much less forgiving than wood. Regular drill bits won’t work because their angles are too aggressive – they’ll push right through just when you start to drill, and crack or chip the plexi.

You want to pick up some Forstner bits, or if you can’t find those, masonry bits. Drill slow and put a couple drops of lubricant on the tip of the bit before you begin. I used bike chain oil.

Also, remember to never take the protective covering off of plexiglass until you are finished cutting. It prevents scratches and reduces the likelihood of cracks during cutting and drilling.

For a simply grand article on how to wrangle plexiglass, the scrupulousness of which gives me goosebumps, see this.

Control Board

This was the most fun part of the project, maybe because I was able to awaken my long-dormant inner electrical engineer (I did plenty of custom car audio installations in college, so I missed playing with wires).

The brains of the control board is Ultimarc’s I-PAC2 USB interface, which lets you turn button and joystick signals into key presses on a keyboard.

The I-PAC2 is really meant for a two player control board, but because we have so few inputs per player, we were able to stretch it to work with four. Once it’s set up, you can plug it into any computer via USB and simulate a standard keyboard. You can use Ultimarc’s Interactive Panel Designer to lay out your control board and program key assignments for each of your inputs.

Mounting the buttons and joysticks and wiring the control board will take way longer than you think, so pull up a chair, pour yourself a cup of coffee or beer and clear your docket for the next four or five hours.

All of the buttons come with plastic nuts that tighten from the back and make easy work of mounting. The joysticks are tougher. Each joystick has six mounting holes, and most people drill down through the top of the control board and run carriage bolts (the ones with a smooth rounded top) through and secure them from the bottom. This is definitely the most reliable mounting method. Your joysticks won’t budge.

In my case, I wasn’t completely sure of the angles I had chosen for the two outer players’ sticks, as they seemed a little aggressive to me despite keeping in line with other builds. I wanted to be able to rotate them later if I decided they didn’t play right.

So on each corner, I used a flat washer, a lock washer, and a 3/4″ #8 screw, coming in from the bottom, that I knew wouldn’t penetrate the top of the surface. It turned out to be very sturdy, and my fingers are crossed that it stands up to heavy use.

bada bing.

Creating a Self-Sustaining Machine

Any computer that’s going to be used as part of an exhibition needs to be able to handle tasks like automatically restarting once a day and rebooting if the game or program crashes. In our case, there also needed to be macros for restarting the game and restarting the computer itself that are accessible by button presses on the control board, so you can reboot the game without having to reach around behind the machine and access the computer.

AutoHotkey, an amazing piece of software for Windows that lets you automate all sorts of tasks like user input, opening and closing documents, file and folder manipulation etc.

Because Crystal Brawl is an HTML5 game, it runs in the browser. The script to restart the game also starts the game. In a nutshell, it closes Chrome, then reopens Chrome to a specified link where our game is publicly hosted, and then puts Chrome into full screen mode. This script is activated by pressing the restart game button on the control board.

Here’s what it looks like:

#SingleInstance Force
 
  SetTitleMatchMode 2
 
  WinClose Google Chrome
 
  
 
  Run https://whereever-your-game-is-hosted-on-dropbox.com
 
  
 
  WinWaitActive, Google Chrome
 
  Send, {F11} 
 
  

A second script, which boots automatically when Windows starts, constantly checks to see if Chrome has crashed, and if it has, it runs the Restart script. Crystal Brawl crashes pretty infrequently, but when you have a game up and running 24/7, you need to have these kind of precautions to make sure it runs smoothly.

This script is a little hacky (in a fun way!) as I couldn’t access lower level info in Chrome via AutoHotkey to be notified when it crashed. It works by taking five color samples every three seconds. If they all match the background color of the famous “Aw, Snap” Chrome crash screen, it restarts the game.

Here’s a peek at the script:

#SingleInstance Force
 
  CoordMode, Pixel, Screen
 
  
 
  ;;sample a few points on the screen to see if they match the color of the chrome crash screen
 
  Loop {
 
  
 
  	sleep, 3000
 
  
 
  	Loop,5 {
 
  
 
  		y := a_index * 100
 
  		PixelGetColor, Color, 100, %y%
 
  		;MsgBox Color: %color%.
 
  
 
  		;;background color on chrome crash page - 0x403023
 
  		if (Color != 0x403023) {
 
  			break
 
  		} 
 
  
 
  		if (A_Index = 5) {
 
  			sleep, 3000
 
  			Run C:UsersUserDesktoprestartCB.ahk
 
  			sleep, 10000
 
  			break
 
  		}
 
  
 
  	}
 
  
 
  }

For more tips on how to keep your installation up and running around the clock, check out this one for Mac.

And that’s about it! It took a lot of time, but the payoff was totally worth it.

If you are planning your own build and you want to have a chat, please shoot me an email at jon[at]studiomercato.com or hit us up on Twitter at @StudioMercato!

Reading The Papers: Ludus Ex Machina

Original Author: Michael Cook

I haven’t discussed my own research in this column yet, but you may know that I’m interested in automating the process of game design in its entirety. At the highest level, game designers produce mechanics that connect to our understanding of reality – gravity makes you fall, projectiles hurt things they hit, touching food heals you – and through this convey meaning that can be anything from representational to metaphorical and artistic. Can machines do this? This week on Reading The Papers: a system that tries to connect the real world to game mechanics.

We’re reading read Mark’s excellent summary of some elements of the work here). The paper contains a lot of interesting discussion about game generation and the nature of game design – and I recommend flicking through the whole thing as a result – but we’ll be focusing on a section describing a simple system for generating WarioWare-like minigames from open-ended textual inputs. We’ll look at the kinds of resources leveraged to make this happen, the pitfalls of the approach, and what other resources developers might find useful.

The system described in the paper takes a verb and a noun as input, such as shooting ducks and then attempts to generate a short, simple minigame based on the input. The minigames are inspired by the game WarioWare, which tasked players with completing a series of quickfire minigames that all lasted just a few seconds each. Each one has a simple core action the player has to complete, and a strong theme for each one that relates to the mechanic somehow. In the example at the top of the article, the player must press an action button repeatedly to make the athlete squat a certain number of times within a short time limit.

The main focus for this system is not generating the game mechanics themselves. Instead, it relies on a small collection of existing game mechanics, and focus on intelligently relating the noun/verb pair with one of the mechanics that already exist. They identify a few abstract game ideas:

  • Avoid games, where one object must avoid colliding with a group of other objects (the player can control either side) for a time period.
  • Acquire games, where the player must find an object within a time limit.
  • Fill games, where the player must fill a progress bar within a time limit.

These abstracts are implemented through a few concrete game templates, with specific roles that the player can take on, starting configurations of objects (such as an Avoid game with one avoider and three dangers to avoid) and so on. So you give your input phrase – shoot ducks – and the system now has to decide two things: which mechanic is most appropriate, and what objects are included in the game in which roles?

In order to start solving these problems, the authors call on two great resources for this kind of thing: Ask it about ducks, for instance, and it’ll tell you that they can quack, that they have feathers, and that they can be shot.

How does this help us? Well, the system the authors write about in the paper associates a set of verbs with each mechanic and game template. So an Avoid game where the player is the attacker might be related to verbs like injure, or attack. If any of these verbs match, it’s easy to make the connection between the input data, and a particular game mechanic.

The chances are it won’t match exactly, however, and when that happens the system tries to calculate the distance between the input verbs and nouns and each type of game template it has in its database. It does this using both WordNet and ConceptNet. WordNet can help make connections between similar nouns, thanks to its data on synonyms and hypernyms, and ConceptNet can make connections between verbs by examining links in the graph, in a similar manner to how Argument Champion worked.. From shoot pheasant the system makes the connection with the Avoid mechanic, where the player tries to target a pheasant.

This is something of an ideal example, of course, but if you’re concerned that a completely open input might be too unpredictable, you can always try and restrict inputs, or only generate games when you have a minimum level of confidence in your results. A game like Scribblenauts doesn’t claim to be able to show you everything – but what it can do is incredibly entertaining. A simple implementation of this minigame generator with a restricted input language (instead of all nouns, maybe restrict it to jobs? Animals?) could add a lot of interesting content to the right kind of game.

One of the reasons I wanted to discuss this work is because it’s a very clean example of how to use ConceptNet in a procedural generation system, and tools like ConceptNet have a huge potential to generate interesting content for games. As a footnote here, I’d like to mention Threatened. Disturbed.

It’s not a perfect tool. It has some crazy potential outputs. But there’s a lot of data tucked away in there, and a lot can be done with it. I prototyped a very silly demo in half an hour that uses Metaphor Magnet to generate patron animals for RPG heroes. It does this through a very straightforward lookup of a noun and returns metaphorical interpretations, but also takes advantage of Metaphor Magnet’s positive/negative spin to provide different angles on a particular noun.

WordNet, it’s hip cousin Wordnik, ConceptNet and Metaphor Magnet are just a few examples of amazing web resources that can be leveraged for new and unusual procedural content generation – content that isn’t abstract levels or weapons, but content that is based on knowledge of the real world and the culture we live in. That’s the kind of off-the-wall procedural generation I want to see more of.

Where to Find More

Michael Mateas is Associate Professor at the equally legendary UC Santa Cruz. Both are very approachable chaps and doing extremely interesting research right now. Get in touch with them if you want to know more!

A little announcement besides: I’m going to be talking at Indievelopment in Utrecht this April. I’m probably going to be talking about some of the things in this week’s column, as well as general things I’ve learned through ANGELINA that might be useful to people making games today. It’s going to be a lot of fun – please say hi if you see me there!

Reading The Papers: Exhausting

Original Author: Michael Cook

When programming systems it makes sense to keep complexity and scale in mind. Don’t try and render 400,000 sprites all at once. Don’t try and send the entire world state to every player on the server. What about our design tools, though? Are we being too cautious when it comes to coding, and what riches might we be able to access if we jumped in the deep end from time to time? This week on Reading The Papers: the power (and responsibility) of computing everything at once.

We’re reading Nathan Sturtevant. In it, Nathan describes a system he built for exploring the mechanics and levels of an iOS puzzle game called Fling! Unlike most tools that might be used for solving or assisting in the design of puzzles, Nathan’s approach uses brute force search and parallelisation to explore the space of possible puzzles. He raises some intriguing points about brute force approaches and their application to procedural content generation – something I think could be really relevant to a lot of developers right now.

Let’s start by talking about Fling! The screenshot above is from the game – an 7×8 grid on which balls are placed. You can swipe a ball in a direction, and it will move until it collides with another ball, which will be pushed in that direction while the original ball stops moving. The objective is to push all but one of the balls off the screen. In the game the number of balls in a single level goes as high as 14, but as Nathan points out this is a fairly arbitrary limit. In theory, there are over 5.8 trillion potential ways of arranging balls on that 7×8 grid – just storing a single bit to record if each level was solvable would take 675GB of space. Of course, we’re not interested in all of the possible combinations, just ones which are solvable. Still, that must be a huge number, right?

Beginning at boards with just one ball in (all of which are successful game states by definition) Nathan wrote a program that built up a database of solvable Fling! levels. In order to generate solvable levels containing n balls, you can start with all solvable levels containing (n-1) balls and add a single extra piece to them, then check if they can be reduced to solvable levels in a single move. This elegant bit of calculation means that Nathan’s code took just two hours to calculate all solvable levels of 10 pieces or less – faster than it took to write the code in the first place, as he points out. This forms an endgame database, which is a key part of the tool described in the remainder of the paper.

By loading the endgame database directly into memory (the work described in this paper uses the 9-piece database for speed, but there’s no reason why larger numbers of pieces wouldn’t work) Nathan was able to develop a tool that could represent Fling! game states and then answer the following questions:

  • How many states can I reach from this game state? That is, how many different moves can I make in total in this level, exploring all the way through to all failed and success states. We’ll come onto why this is useful later, but this can be a big number as the levels get bigger.
  • How many starting moves lead to a solution? This can be calculated with help from the endgame database. The tool annotates the level with little white arrows showing these starting moves – incredibly helpful for a designer wanting to visualise the solution space.
  • What effect would single changes have on the board? When you present a Fling! level to the tool, it checks each of the 56 tiles on the board and either adds or removes a ball to it, then rechecks the board. Using this data, it can shade tiles that would either make a solvable level unsolvable if it were changed, or vice versa.

What you end up with is a tool that can show you how many potential starting moves a puzzle has, how to fix (or break) a puzzle, and also tell you how big this puzzle is in terms of possible moves. Why is that last point a big deal? Here’s a graph showing the level number (on the X-axis) versus the total number of states (on the Y-axis, logarithmic) in the original Fling! game:

  In other words, the number of states in this level’s search tree seems very closely related to what the game’s designer thought of as difficulty. Which makes sense – the more wrong alleys there are to go down, the more potential there is for a player to trip up. What if they aren’t all wrong alleys? Nathan’s already ahead of you there. By analysing Fling!’s levels, he found that every level was designed to have a single valid solution path. That is, there is only ever one right move to make on the board (Nathan tells me there are some interesting conclusions you can draw from this about certain kinds of moves, given that there’s only ever one correct move – he’s looking into these at the moment).

What’s important to take away here is that both the endgame database and the tool’s analysis of level designs is done more or less exhaustively – there are no search heuristics guiding the tool towards finding levels it’s been told might be good, or moves it’s been told might be productive. Instead, it searches all possible moves, it explores all possible routes through the search space, and as a result you find that actually that space wasn’t so scary after all. And once you have that complete archive of every possible level in memory, a human designer can sit down and really get to grips with a level design.

You might think that this is all well and good for grid-based games with small state spaces. And it absolutely is. There are plenty of people working on incredible grid-based games with small state spaces, and even when that state space increases just a little bit we may still find it tractable to store endgame databases and exhaustively explore the design space.

All the work described in the paper uses parallel processing wherever it can, since individual game states are unrelated to each other (there’s no data to bear in mind like health). Even this could be added to the state representation rather than holding it in data. A game like Corrypt has very few resources – each level could be processed a few times with differing resource levels embedded in the game state.

The real importance of the paper is not the specific problem the tool solves, though. It’s the rewards that Nathan found by attempting to exhaustively solve a problem instead of tiptoeing through it with the usual applications of A* search and optimisation techniques. Vast memory reserves, multithreading, cloud computing – we have a lot of resources at our fingertips these days, and that should make us reconsider the use of brute force techniques. What was once a one-way ticket to slowdown and memory overflows could now be a powerful new way of looking at game design.

Where To Find More

Nathan is currently an Assistant Professor at the University of Denver. He presented this work in a fantastic talk at the AI in the Design Process workshop at AIIDE 2013, and really impressed me with the results in the paper. I hope I got some of it across! Do get in touch with him if you want to talk more. If you’re at the AI Summit at GDC this year, Nathan will be talking about Monte Carlo search – he’s a great speaker who’s done a terrifying wealth of work on search techniques, so I recommend checking the talk out! If you’re interested in the work in relation to Fling! then apparently Nathan’s working on a new level pack for Fling! based on some of the ideas this tool started from, and mixing in some automated design as well. I’m really excited to see more about this – perhaps another Reading The Papers in the future…

As ever, you can get in touch with me my site for updates on how ANGELINA performed in its very first game jam.

Avoid Resize()?

Original Author: Thomas Young

(Also posted to series of posts about Vectors and Vector based containers.)

This post is essentially a response to feedback to this previous post.

In that post I talked about a change we made to the initialisation semantics for PathEngine’s custom vector class, and described a specific use case where this can make a difference, with that use case involving calls to the vector resize() method.

In the comments for that post, Herb Sutter says:

Thomas, I think the point is that “reserve + push_back/emplace_back” is the recommended style and the one people do use. Really resize() is not used often in the code I’ve seen; you use resize() only when you want that many extra default-constructed elements, since that’s what it’s for.

In this post I’ll be looking into our use case in a bit more detail, and in particular whether or not a resize() call is actually required.

Avoiding unnecessary initialisation

As a result of writing reader feedback to previous posts (including Herb’s comments) I’ve realised that I’ve got a bit of a bad habit of sizing vectors directly, either in the vector constructor, or with calls to vector resize(), where in many cases it’s actually more efficient (or better coding style) to use reserve().

We can see an example of this in the first post in this series, where I posted some code that constructs a vector with a fixed size and then immediately clears the vector, as a way of avoiding memory allocations:

    std::vector<cFace> openQueueBuffer(20);
 
      openQueueBuffer.clear();

Memory allocations are bad news for performance, and avoiding unecessary allocations should be the first priority in many situations, but there’s also a secondary semantic issue here related to element initialisation and it’s better general purpose vector code to use the resize() method for this, as follows:

    std::vector<cFace> openQueueBuffer;
 
      openQueueBuffer.reserve(20);

The difference is that the first version asks for initialisation of 20 cFace objects (with what actually happens depending on the way cFace constructors are set up), whereas the second version doesn’t require any initialisation (independantly of how cFace is defined).

Note that this issue doesn’t just apply to vector construction – exactly the same issue applies to vector resize() operations where vector size is increasing.

In PathEngine, because cFace is a POD class, but also because of the way initialisation is implemented in PathEngine’s vector class, both versions actually work out as doing the same thing, i.e. no initialisation is performed in either case. But could we change the PathEngine source code to avoid calling resize() and so avoid the need for non-standard vector initialisation semantics?

Resize benchmark

In my previous post I posted the following minimal benchmark to shows how initialisation semantics can make a difference to timings.

template <class tVector> static int
 
  ResizeBenchmark()
 
  {
 
      int sum = 0;
 
      for(int i = 0; i != 400; ++i)
 
      {
 
          tVector v;
 
          v.resize(100000);
 
          v.back() += 1;
 
          sum += v.back();
 
      }
 
      return sum;
 
  }

In the comments Herb points out that we shouldn’t actually use code like this in many situations, but rather something like the following (avoiding the resize call and resulting element initialisation):

template <class tVector>
 
  int RealResizeBenchmark()
 
  {
 
      int sum = 0;
 
      for(int i = 0; i != 400; ++i)
 
      {
 
          tVector v;
 
          v.reserve(100000);
 
  
 
          for( int j = 0; j <100000; ++j )
 
              v.emplace_back( GetNextInt() );
 
          // or replace above loop with "v.assign( src, src+srclen );"
 
          // if your cVector code would do a bulk memcpy
 
  
 
          v.back() += 1;
 
          sum += v.back();
 
      }
 
      return sum;
 
  }

Lets look at the buffer copy version, specifically (i.e. with the call to v.assign()), and set up an updated version of our benchmark to use this construction method.

We’ll use std::vector to set up some source data, initially, for the buffer copy:

    int sourceDataLength = 100000;
 
      std::vector<int> source;
 
      source.reserve(sourceDataLength);
 
      for(int i = 0; i != sourceDataLength; ++i)
 
      {
 
          source.push_back(i);
 
      }

And then the benchmark can be rewritten as follows:

template <class tVector> static int
 
  ResizeBenchmark(const int* sourceData, int sourceDataLength)
 
  {
 
      int sum = 0;
 
      for(int i = 0; i != 1000; ++i)
 
      {
 
          tVector v;
 
          v.reserve(sourceDataLength);
 
          v.assign(sourceData, sourceData + sourceDataLength);
 
          sum += v.back();
 
      }
 
      return sum;
 
  }

This could be written more concisely with direct construction from iterators but reserve and assign are closer to what we would do in our original use case where we’re actually reusing an existing vector.

There’s a problem, however, when we try and apply this benchmark to PathEngine’s cVector. cVector only provides a subset of the std::vector interface, and doesn’t provide an assign() method, or construction from iterators, (illustrating one of the potential disadvantages of rolling your own vector, btw!), so we end up putting resize() back in for the cVector version of the benchmark:

template <class tVector> static int
 
  ResizeBenchmark_NoAssign(const int* sourceData, int sourceDataLength)
 
  {
 
      int sum = 0;
 
      for(int i = 0; i != 1000; ++i)
 
      {
 
          tVector v;
 
          v.resize(sourceDataLength);
 
          memcpy(&v[0], sourceData, sourceDataLength * sizeof(v[0]));
 
          sum += v.back();
 
      }
 
      return sum;
 
  }

I ran this quickly on my main desktop machine (Linux, Clang 3.0, libstdc++ 6) and got the following results:

container type build time sum
std::vector release 0.0246 seconds 99999000
cVector (default initialisation) release 0.0237 seconds 99999000

I’m not going to go into more benchmarking specifics because (as with the original benchmark) the point is just to show whether or not there is an issue, and the exact timings values obtainer aren’t really very meaningful.

But, yes, with this version of the benchmark (construction as buffer copy), and with std::vector used in this way it’s fairly clear that there’s basically nothing in it, and therefore no longer any advantage to modified initialisation semantics.

But what if..

But what if we want to load this data directly from a file?

With resize(), we can do something like the following (with good old low level file IO):

void
 
  LoadFromFile(const char* fileName, cVector<char>& buffer)
 
  {
 
      FILE* fp = fopen(fileName, "rb");
 
      // error checking ommitted for simplicity
 
      fseek(fp, 0, SEEK_END);
 
      buffer.resize(ftell(fp));
 
      if(!buffer.empty())
 
      {
 
          fseek(fp, 0, SEEK_SET);
 
          fread(&buffer.front(), 1, buffer.size(), fp);
 
      }
 
      fclose(fp);
 
  }

At first glance this seems a bit harder to rewrite ‘the right way’ (i.e. with reserve() instead of resize()), without doing something like loading each individual element separately, and without explicitly creating a separate buffer to load into. After a short search, however, it turns out we can do this by using stream iterators, as described in this answer on stackoverflow.

Let’s implement another version of LoadFromFile() then, without resize(), as follows:

void
 
  LoadFromFile(const char* fileName, std::vector<char>& buffer)
 
  {
 
      std::ifstream source(fileName, std::ios::binary);
 
      std::vector<char> toSwap((std::istreambuf_iterator<char>(source)), std::istreambuf_iterator<char>());
 
      buffer.swap(toSwap);
 
  }

I used the following code to knock up a quick benchmark for this:

template <class tVector> int
 
  FileSum(const char* fileName)
 
  {
 
      tVector buffer;
 
      LoadFromFile(fileName, buffer);
 
      int sum = 0;
 
      for(int i = 0; i != buffer.size(); ++i)
 
      {
 
          sum += buffer[i];
 
      }
 
      return sum;
 
  }

Calling this for a largish file (on my main desktop with Linux, Clang 3.0, libstdc++ 6, release build) gave me the following:

container type Method time
std::vector iterators 0.1231 seconds
std::vector resize+fread 0.0273 seconds
cVector resize+fread 0.0241 seconds

So, on this machine (and build etc.) stream iterators work out to be a lot more expensive than ‘simple’ direct file IO to a buffer.

Note that I threw in a call to the old style file IO version for std::vector as well, for completeness, and it looks like the overhead for extra buffer initialisation in resize() is actually insignificant in comparison to the cost of using these stream iterators.

I guess this could depend on a lot of things, and I haven’t checked this across different machines, different standard library implementations, and so on, and I don’t have any practical experience to draw on with optimising C++ stream iterator use, but this does show quite clearly that it’s nice to have an option for direct low level buffer access for some situations where performance is critical.

Full disclosure

In fact, for portability reasons, the PathEngine runtime doesn’t actually include any direct filesystem accesses like those shown in the code above. Loading from persistence is handled by client side code loading data into a buffer in memory (using the relevant operating system file loading methods) and then passing this buffer into PathEngine load calls.

So we could theoretically switch to using std::vector assign() and get rid of this specific use case for changing vector initialisation semantics.

But there are some other reasons why I prefer not to do this.

Dependencies and low level interfaces

The use case I showed in my last post involved the following methods on a custom PathEngine stream object:

    void openNextElementAsArray_GetSize(tUnsigned32& arraySize);
 
      void finishReadElementAsArray(char* destinationBuffer);

This is low level, works with raw pointers, and is not really modern c++ coding style, but I actually prefer this in many ways to passing in a std::vector reference or templated iterator arguments. It’s nice to avoid dependencies on a vector class, for example, or the additional complexity of templating, and it’s nice to be able to use these methods with buffers that are not managed as vectors.

Some of PathEngine is written as quite low level code, and I think that one of the great things about the STL is how easy it is to interface STL components with lower level code. Being able to taking pointers into the buffer of an STL vector for low level buffer access is one example of this, but sometimes this kind of low level buffer access implies direct vector resizing, and resizing vectors without element initialisation can then often be desirable.

Working with partially initialised buffers

Another use case we come across sometimes in PathEngine is when we want a buffer to store some kind of data corresponding with a given set of index values, but don’t need to set values for all elements, and we have information available somewhere else which tells us which elements have actually got meaningful values set.

One example could be where we want to form a sequence of elements from a large set of potential elements, and so we set ‘next’ values for each element currently included in our sequence, but we don’t need to initialise next values for elements not included in the sequence at all.

This is perhaps a less common use case, however, and I’m not sure how much difference this actually makes to timings in practice.

Wrapping up

It’s good to know the right way to do things in modern c++. With vectors the right way usually means preferring reserve() over resize(), and this will avoid unnecessary initialisation in many cases (and the need to worry about details of vector initialisation semantics).

In the case of PathEngine however, I quite like being able to mix low and high level code. We still find it useful in some cases to resize() vectors without explicit element initialisation and changing the initialisation semantics in our custom vector class helps to ensure this is as efficient as possible!

** Comments: Please check the existing comment thread for this post before commenting. **