The incredible art of over-engineering: Everybody Plays Golf Post-Mortem

August 9, 2017August 9, 2017 | Taro Omiya

Over-engineering: a plan where one adds unnecessary complexity in implementing a simple feature for a technical project. In the same way it’s dangerous to plan a game with too many features in a game jam, over-engineering sinks a lot of projects, personal or otherwise. While we’ve set out to make a satirical game about energy systems, thus providing us an excuse to make a terrible game, we admit that over-engineering has made our latest Ludum Dare game worse than we originally planned. Here’s our post-mortem of Everybody Plays Golf, an overly complex game with an ironically simple premise.

What is Everybody Plays Golf?

Everybody Plays Golf is a tongue-in-cheek riff on the Twitch Plays genre. In this online game, anyone with an internet connection fights over the control of a single golf ball, as they attempt to putt it into the hole at the upper-right hand corner of the stage. The catch is that there is an energy system, à la Farmville and other free-to-play social games, that prevents the player from putting more than 7 times. While the game claims one can recover energy over time, this is actually a bit of a white lie: every player’s energy does not recover until the golf ball falls into the hole. Once it does, everyone recovers all 7 units of energy, and the ball resets its position back to the bottom-left corner of the map.

It’s simultaneously an experimental game about cooperation, a satire on social games, and a technical nightmare for the sole programmer who put all the pieces together.

What went right

Using game jams as an opportunity to learn something new

We’ve always used game jams to learn something new, such as Blender modifiers, Unity path-finding, story-writing, procedural generation, and so forth. This time was no different: we decided to take what we learned on hack.source.net to make a networked game where everyone controls the same object. In this case, we’ve taken the time to learn all the moving parts necessary to create an asynchronous networked system: making a server that simulates the physics of the golf ball, using a free trial of Google Cloud to host said server, creating a client that calculates the direction the user wants to putt the golf ball, setting up a MySQL database to store all the players’ putting directions, and code a few PHP scripts to get access to MySQL databases. It’s a strange framework that gets the job done and forces us to learn and re-learn some critical professional skills, such as SQL, Get and Post requests, networking, etc.

A goofy tutorial

We also took a stab at looking into TextMesh Pro assets from the Unity asset store. While playing around with it, it came to us this asset can be used to create a 90s advert like tutorial. Thus, our cheesy tutorial was born: a ridiculously positive and verbose set of instructions on how to play the game…even though the game is simple enough for one to figure out how to play with enough experimentation. Putting this tutorial in was a bit of a risk at the time because the server wasn’t working. We’re glad we put the time in to improve the presentation of the game.

Making incremental builds

As usual, we started with building the basic models and scripts to create a prototype where one controls a golf ball with a mouse click. By starting very small, it was easy for us to detect problems early before building new features on top of this game. This vital process kept all the moving parts manageable by keeping the project simple and stable.

Not letting non-working parts prevent us from progressing

For the longest time, the server part of the game was not working: despite having it uploaded and running on a static IP address to a Google Cloud virtual machine, the server would not start listening to a port. While this did delay the development by a significant factor, it didn’t keep us from improving other parts of the game that needed attention, including graphics and information sent and stored into the database. Even though the game was unplayable for the grand majority of the development (at least in the way that was intended), we’ve still managed to find workarounds or working on portions of the game we’re more well-informed of while we’re trying to figure out what went wrong.

What needs improvement

Overly complex design

The full details of how Everybody Plays Golf works goes as follows:

The client: the PC/Mac/Linux build that the user downloads. It does the following:
1. Connect to the server. Once connected…
2. Sync the position of the golf ball in real-time,
3. Syncs and stores how many times the server has recorded the golf ball fell into the hole. This is used to check if the player’s energy needs to be refilled when they open the application again.
4. Locally how much energy the player has. A unit of energy is depleted each time the player clicks.
5. Send a Post request to a PHP script, sending information about the name of the player, and the direction they’ve putted.
The server: a Unity headless Linux build running in a Google Cloud server. It does the following:
1. Spawn the golf ball, and monitor its movement and physics.
2. Send a Get request every 0.2 seconds to a PHP script, receiving information on the last set of putts it hasn’t read yet.
3. Uses all the putt directions it receives, and applies them to the golf ball. That’s right: only the server moves the golf ball directly!
4. Sends a Post request once the golf ball has been putted to indicate which directions should be marked as read.
The database: a MySQL database and a set of PHP scripts hosted off of our own website. It does the following:
1. Store a list of directions, names, and a flag on whether the entry has been read or not.
2. Provide 3 PHP scripts:
  1. One for recording directions into the database, and automatically flagging them as unread.
  2. One for retrieving all the directions that are flagged as unread from the database.
  3. And one for marking specific directions to mark as read (each direction has a unique ID).

To be clear, each of these parts were either a separate build of the game, or using a completely different scripting language. That meant that often, there were many portions of the code that only applied to one part of the game. Making sure each of these parts were working in harmony took the most amount of time and energy.

Naturally, there are way too many parts for a game jam game, and one that in hindsight, could have been simplified even further had we known how Unity’s UNET networking framework worked better.

RemoteSettings not working

The dreaded, “it works on my computer” occurred when we tried to make a server build of our game, and hosted it up to the Google Cloud server. The client would not connect to the server, even through it worked fine in our local setup. After a ton of online research, we soon realized the server simply wasn’t listening to the port it was programmed to. For the longest time, we could not figure out why; we’ve instead moved on to other parts of the game while mulling over it. It was only when we were nearing the submission deadline did we realize through logs that Unity’s RemoteSettings, which we were checking its status before retrieving a port number, was not working. Baffled, we’ve removed the status check before grabbing the port-number (i.e. the equivalent of hardcoding the port number), and the server finally worked. After that, we only had minor bugs to fix on the client before submission. Still, it was very stressful during the time we had no idea what was broken with the server.

Poor feedback

The game provides no feedback on how many people are playing, making it incredibly confusing to figure out why the golf ball may be moving on its own. Additionally, since the server receives from the database every 0.2 seconds and is the only part responsible for moving the golf ball, there is almost always delay between clicking the mouse and observing the golf ball moving. And for additional pain, the client could fail to send to the database the direction the player putted for any technical reason, yet they’ll still lose energy for it. All of this leads to poor feedback to the player, providing some confusing information as to why the ball might be moving on its own, or conversely, why it’s not moving when the player clicked.

Legacy UI

There was a pause screen we left in the game, in case we added any audio to the game, so that one can use it to access the options screen as well as the credits. Unfortunately, we didn’t have time to fix the text labels on that screen, or had the time to test whether options or credits worked. With such broken features left in the game, it might have been better to remove it entirely.

No audio

If it wasn’t obvious, we ran out of time adding audio. Sigh.

What to do next

From the beginning, we knew we were taking major risks working on this game within the Ludum Dare deadline. That said, we probably could have taken a refresher, or made a simple library of codes that would help us accelerate the development than the approach we took for this jam. We should also strive to make a simpler model, removing the database portion entirely. Finally, never use RemoteSettings until we know how it works.

Combining the unusual with the familiar: The Recursive Dollhouse Post-Mortem

December 23, 2016December 26, 2016 | Taro Omiya

“I have a present for you,” announced the father as he walks into his family home with a big wrapped package. Excited, his daughter hastily unwraps the box. Her face opens into a big smile: it’s a dollhouse. “Take a look inside,” encourages the father. The small girl lifts the roof of the dollhouse to reveal its content. From the single doll sitting next to the tea table, to the miniature tea-set set on top of it, the detailed content made the girl ecstatic. “Wow, it’s beautiful,” she exclaims.

Suddenly, their house rumbles. Startled, both the father and the daughter looks up to the ceiling. Or the sudden disappearance of it. Instead, as the sunlight seeps into their living room, a girl taller than skyscrapers looks down with a big grin. Holding their house’s now-detached rooftop while looking down on the family, she booms, “Wow, this is beautiful!”

The commercial-length episode described above from the Japanese TV show, Tales of the Unusual (which is basically the Twilight Zone) became the main inspiration for our Ludum Dare 37 entry, The Recursive Dollhouse. Like most game jams, the development process of this game was a stressful experience perfecting the core mechanic of the game: traveling into and out of smaller dollhouses. Despite having a relatively unexplored central mechanic, though, it’s quite surprising to realize how much of the game is derived from previous conventions.

What is The Recursive Dollhouse?

The Recursive Dollhouse is a first-person puzzle game that involves jumping into and out of dollhouses, shrinking or expanding the player to fit into the dollhouse comfortably. The game utilizes various different methods to provide unusual puzzles, such as ones that involves changing the sizes of objects, or using the recursive nature of the dollhouses to repeat rooms without backtracking.

What went right

Getting the “jump”right

Initially when we pitched the game, all we had as a game design document was these scribbled notes on our list of many game ideas based in one-room:

Dollhouse -> reflective of actual room -> recursive

To translate this in proper English, we had a game idea about a house you can enter that’s already in another house, which in turn is in another house. Needless to say, we really haven’t thought through this idea at all, which made us fairly cautious of whether it’ll work or not. Still, we took a couple hours to make this idea and see what it feels like:

At the point we made this GIF, it was clear to us this was all we needed to continue with this idea to a full game. It felt pretty magical at the time, and opened to a lot of detail-hunting gameplay opportunities.

Building the puzzle components first

We tend to follow the Nintendo mentality of designing games around mechanics. Once we had the prototype ready, a lot of important questions emerged, such as: why would one want to dive into a house? Once they dived into a house, do they want to return back to the house they were in before? If so, why? And what makes diving into a house unique, that can’t be done with mere doors and switches like in Zelda games?

The solutions we came up with were, while not extensive at addressing all these questions, attempts to solve some of them. For having a reason in diving into a house, we resolved it with the classic key-door mechanic; it gates your progress, thus incentivizing your exploration. Since at least one path is going to be blocked by the locked door meant that the game would need split paths and recursive loops for creating complexity.

The emphasis on exploration inevitably answers the question of whether we want to return to our previous residence: yes! While a few different ideas were offered to to us by other jammers on returning the player, the method we chose was a spring to reverse the diving action. This decision was made largely out of practicality: it was the easiest action to implement, since it didn’t require creating a new model and animations.

Finally, what makes this mechanic unique from normal dungeons? After all, the act of diving into a house is a lot like entering a puzzle room from the middle. To differentiate this game, we went to our favorite surrealist artist for reference:

“The Listening Room,” by René Magritte was what inspired us to design puzzles that involves dropping a variety of items into smaller dollhouses (though only keys made it in due to lack of time). From there, we had a new question: why would one want to drop anything in the house? We resolved this by adding a code on the items that are initially too small to read. By using this mechanic to make the item larger, they can make the code legible, and thus, progress in the game. Clearly, this meant we needed to create coded doors, and that’s what we did.

Thanks to the initial prototype, it helped us summarize our thoughts on which puzzles were needed in the game to make it stand out, and which weren’t. We didn’t add any block puzzles, for example, since those puzzles are often self-contained in a single room, and do not provide a good reason to hop between different rooms. With these tools available, we were able to start constructing levels that helped emphasize the core mechanic of the game.

Easy level design interface

Incidentally, a lot of features listed above required re-writing the first prototype on how the player shrinking and growing was achieved. Originally, we had just 3 dollhouses–each smaller than the other–embedded into each other. When the player jumped within the trigger area of each dollhouse, all the houses will grow in size. This rather round-about method of creating an illusion that the player was growing or shrinking was due to keeping the physics consistent, as larger objects fall slower in the Unity game engine, and faster for smaller objects.

While growing and shrinking the visible houses remains the same, the new version of the game required dynamically embedding and removing the dollhouse from the grow/shrink list so that recursion and split paths can be achieved. This was quite a significant effort to keep the illusion of houses being embedded into one another intact. A subtle fog was added to create a logical reason as to why larger houses disappears from view as they’re being removed from the list and being cleaned up. Springs had to now retain a history of dollhouses you’ve traveled in, so it knows which house to return the player to. And each table that held a dollhouse now merely holds a reference to it. When they’re needed, the table dynamically resize and position the dollhouse on top of itself.

This costed a lot of time, but it had a huge plus side beyond making many of the mechanics listed in the previous section above possible: the new change made it a lot easier to design levels. The original prototype required shrinking the embedded houses smaller and smaller, which which already tested Unity’s ability to be able to render the dollhouse and their content. Since the tables now dynamically resize the houses to the proper size, every dollhouse can be designed with exactly the same size. No need to tediously resize each gameplay element to the proper size!

This also helped create a visually more understandable level design diagram in Unity itself. As seen in the screenshot below, dollhouse-holding tables are connected to their respective house with a magenta-colored line. With this visual, it helped us create a graph-like diagram that indicated how each house is connected with each other. As a consequence, it made it easy to verify that our development matched our own level design sketches.

Always testing your own puzzle designs

Fun fact: while designing the last few stages, one thing that became clear was that a sketched puzzle had a hole in it, causing the player to go through a loop of houses infinitely. Our regular habit of testing what’s been implemented as early as possible helped us discover these kind of problems sooner, allowing us to quickly correct mistakes. In this case, we created a shortcut to the proper solution so that the player would not be stuck in an infinite loop. While this unfortunately made the last part filled with switches that served no purpose, we were still able to provide a solvable experience.

Practicing Blender

In every game jam game, we try to learn a new technique. This is largely so that we end the game jam with at least something new in our hands, preferably a good game, but at minimum with a new skill. This Ludum Dare helped us improve our Blender skill by utilizing the boolean modifier. While we probably abused this feature when simpler methods existed for combining or subtracting meshes, it helped us create a lot of low-poly models quickly enough for our beginner skills to create the elements in the game.

What needs improvement

Too many codes!

In The Recursive Dollhouse, nearly everything has a code associated with it. From the key doors that has a code matching keys to the corresponding door, to the switches that has a code matching the doors it opens or closes. While these identifications adds complexity for keys-only or switches-only puzzles, they become a huge source of confusion when code doors are involved. Are the codes written on the key doors the answer to the code doors? This ambiguity forced us to make passcodes appear nearby the door they correspond to.

In fact, code doors themselves probably needs to be revisited. They’re currently implemented quite poorly: in a game that locks and hides the cursor, the only way we could get the Unity GUI system to allow button pushing was to unlock and expose the cursor. This means the player’s position is locked, and unable to move while entering the code, sometimes leaving the player in camera angles that doesn’t expose the entire keypad (this can be escaped with ESC pause menu, but it’s a work-around). Besides, codes requires significant memorization, creating a rather immersion-breaking experience.

Linear puzzle design

Despite having the name, “recursion” in the title, there’s only one part in the game where the dollhouses actually loop into each other. There are also very few places that the paths split in the game. This resulted in creating a rather linear experience with little room for experimentation. Every puzzle has only one solution, and backtracking is kept to a minimum. Part of the reason we didn’t add much complexity in our game had to do with the lack of time and how the current gameplay elements were implemented made it difficult to create these puzzles, but another part had to do with our lack of sleep. At one point while designing the puzzles, we were so confused with our own levels, we couldn’t solve it while testing. While it made sense at the time to implement more linear puzzles during the jam, in hindsight, it felt like we cheapened the experience.

Larger houses are under-utilized

Currently, after diving into an embedded dollhouse, the previous house is visible through the windows. The now-large dollhouse, however, serves no purpose outside of visuals. This did feel like an underutilized feature, but we never found a good use of it until recently. While creating a shortcut to the last few puzzles, it just hit us while looking out the window that we could have hid a super-small code in the larger dollhouse that would only be legible through the window of an embedded dollhouse.

At one point while brainstorming on different gameplay elements into the game, an idea we had was to be able to carry and place dollhouses themselves. We didn’t pursue this, however, due to the lack of puzzles that would justify such a mechanic, and the difficulty of resolving what should happen if the user clicked at a carry-able dollhouse with an item already in the house. The previous small-code hunting mechanic would have resolved the former problem, along with making it the primary method to carry levers. We just feel bad we weren’t able to come up with these ideas sooner.

No visual variety

Since we were only beginners with 3D modelling in general, we were not very quick a creating models, let alone UV-mapping and texturing them. Seeing that justifying the core mechanic was our strength, we decided on focusing that aspect. This unfortunately meant that the graphics suffered: while we had plans on creating dollhouses with different shapes and window sizes, we did not have the time to make any of them. The textures on the dollhouses and the springs are actually just us color-coding which segment of the texture corresponds to which part of the model. The dollhouse’s toy-like appearance is entirely coincidental. For a puzzle game that involves some back-tracking, a variety in graphics would have helped the player navigate the game by making it easier for them to memorize where each dollhouse is.

What to do next

A lot of the bad parts in our design can be easily attributed to our lack of sleep, and poor pacing. Taking that into account, it might have been a good idea for us to scale back a bit and implement what is only necessary. Next time when we design a puzzle game, we should probably avoid numbers and/or code-based puzzles. If we want to add level designs that requires memorization we should make it more universal by relying on easy-to-recognize shapes and colors. Finally, we should emphasize more on exploration by adding multiple paths and hopefully multiple solutions to each puzzle, to create the appearance of complexity in each level.

Not a Clone Post-Mortem: Live!

November 2, 2016 | Taro Omiya

We’re live-streaming our post-mortem of our mobile game, Not a Clone, live at IGDA Albany (11/2/2016, 7:00 PM EST)! Check it out on our stream below.

Watch live video from AlbanyIGDA on www.twitch.tv

Stop Asking Me Unity VR questions! The Hidden in Plain Sight Post-Mortem

May 5, 2016May 6, 2016 | Taro Omiya

In-between making a game for Ludum Dare game jam, we were also responsible for organizing the Tech Valley Game Space Ludum Dare real-world meeting, and acting as a tutor for the Unity application in a VR Hackathon at Tech Valley Center of Gravity. While we have dealt with being an organizer and making a game at the same time in the past, it turns out being also a tutor for this jam proved to be a difficult task to juggle. Looking back, it feels like a miracle that a decently popular puzzle would come out of this hectic and stressful schedule. Here is the Hidden in Plain Sight post-mortem!

What is Hidden in Plain Sight

Hidden in Plain Sight is a 3D puzzle-platformer where the player character is, by default, invisible. Her silhouette, however, reveals an invisible dimension (similar to the Lens of Truth from the Legend of Zelda: Ocarina of Time) that she can interact with. Most puzzles rely on using the proper camera angles and character placement to simultaneously reveal the character, and navigate and/or use invisible elements in the game.

What went right

Taking inspirations outside of video games

Perhaps unsurprisingly, Hidden in Plain Sight‘s visuals are strongly inspired by René Magritte’s paintings, such as La Grande Famille:

While the visuals themselves may be well-trodden ground for the art world, putting them into a game form created an innovative experience for many players, such as the Let’s Play posted above.

Using built-in Unity features to implement the visuals

More surprisingly, putting together this “cut-out” visual effect was actually quite easy. The result is from a clever combination of using multiple cameras, render textures, and UI mask element, as revealed in this Twitch video: twitch.tv/japtar10101/v/63371555.

We did try to create a set of shaders for better performance, but quickly abandoned it when realizing we were neither knowledgeable nor quick enough to put it together in a short time frame.

Experiment early, experiment often

During the second of the four-day development, we spent an ample amount of time experimenting with this visual effect. Those following our Twitter account may recall this animated GIF below:

At this time, we discovered a number of important attributes with our game:

Polishing the visual language

The most basic rule in the game, “only objects you see through your character can be interacted,” was actually not finalized until the third day of development. Originally, any object regardless of how it was made visible could be material…or not. After a lot of experimentation, we realized that we ourselves couldn’t figure out what was interactive, and what wasn’t. To fix this, we implemented the rule above to create a more consistent visual-to-interaction language.

We also experimented with creating other methods of figuring out where your character was, such as creating a small cloud wherever she stood. We removed those details, however, when one of our play-testers pointed out that not being able to know where your character is all the time felt like a vital aspect of the game’s experience. Instead, we made interactive objects large and obvious from a distance, especially if they’re invisible.

We wanted to make sure the effort of finding that one switch was as fair as possible, so on top of making them large, we added a line that connects them to the door they activate, allowing the player to trace back the switch’s place.

Keeping platforming to a minimum

Having an invisible character poses a number of challenges that we had to work within. For example, we kept the platforming easy and to a minimum. Since your character is invisible in most locations, it’s difficult to gauge her position, and thus making the platforming difficult. Even with easy platforming, we went an extra mile to add mid-air controls that were missing in Unity’s Standard Asset 3rd-person controller script, so jumping would feel more natural.

What needs improvement

Less volunteering, more time to work

Those who saw our time-lapse video may have found the introduction to it really strange: instead of showing our brainstorming or development process, it shows a bunch of slides on how to create Unity VR applications.

In fact, we had volunteered to teach how to make VR applications to a hackathon occurring at the same place and time as our game jam. Fortunately for everyone involved in both events, the organizers were able to manage ourselves to different rooms, minimizing any possible annoyances. Unfortunately for volunteers such as ourselves, some of our time were taken helping both events, even if we were also working on a submission for either events. In our case, this manifested in answering any Unity VR questions, including giving a presentation at the beginning of the second day of Ludum Dare. The time loss wouldn’t have been such a big issue if we’ve allocated our time and efforts accordingly. Sadly we did not. Instead we were hit with the dreaded…

Feature creep

By the third day of development, we started adding multiple different invisible characters.

Originally, the game was meant to be about making human connections. In that sense, the non-interactive NPCs in the final game was a deliberate mechanic to emphasize how lonely your character is. To counteract this rather depressing fact, we tried to create Pikmin-like helpers that followed your character around. This feature, as with many other ideas such as switches that requires more than one person to hold down and an actual storyline had to be scrapped, despite a ton of time being spent on each of those features. This was easily the biggest time loss, and one we’re guilty of not-quite-learning.

Unclear visual cues

Notice the weird off-color floor in the screenshot below? That’s the area the movable block can be moved around.

Practically no one understood that’s what the off-color floor stood for. For all the effort we’ve put into polishing the presentation and readability of the game, there are many places where we failed to portray what the visuals meant effectively. And that’s before we get into the (very few) platforming sections in the game. While the screenshot above provides a near-perfect solution to make it clear your character is walking on top of the block, we don’t use the same solution for the platforms themselves. Instead, the platforms in the final game looks exactly the same regardless of whether you’re looking through the character or not, resulting in this monstrosity:

Leaving level and audio design to the last day

Due to all the feature creep, we’ve left level construction and audio polish to the very last day of development. This lead to a very short and unpolished game, such as blocks being pushed not necessarily playing the push sound effect, or the gap in the last level that makes the world beyond the walls in plain sight. Given how rushed the level design was, it sometimes surprises us when someone compliments how they liked the game.

Edit: Research the title before posting

As many people have notified us, there is already another game named Hidden in Plain Sight by Adam Spragg (note: it plays nothing like our game). Obviously, we should have researched the title properly before posting it on various web portals.

What to do next

Like most game jammers, time wasted in things that does not show up in the final product has been our biggest stumble block. We definitely need to divide our volunteering time more smartly so it would not conflict with a game jam, or else we’ll leave more than one person disgruntled. We should also be quicker at abandoning time-consuming tasks, and design around the lack of that feature.

While our experimentation time is serving us well in identifying some issues early, it failed to find other problems that became more obvious once the levels were laid out. As such, we should allocate more play-testing sessions to find them more easily, especially after some of the levels are constructed.

hack.source.net’s Ludum Dare results analysis

January 11, 2016January 9, 2016 | Taro Omiya

Our fifth Ludum Dare was our first attempt at making a simple online multiplayer games. How did we do?

hack.source.net (Ludum Dare 34)

Above average. Fun, innovation, and overall stands above the 20% standing. Innovation in particular stands at the 5% mark, and we certainly ranked within the top 100 in that category, so we’re very proud of that. Our score stands smack in-between 3 and 4 stars out of 5, so it could have been improved. Still, considering what a mess it was trying to develop this game, we’d say it’s pretty good.

How does this compare to our other Ludum Dare games? Let’s check them out in reverse order.

Can I Haz Monsters? (Ludum Dare 33)

Can I Haz Monsters? did do better than hack.source.net in comparison. Seeing that development went much more smoothly for this game, this isn’t a major surprise. A lot of players commended the dialog system in the game, explaining the rather high mood rating.

Star Driller Ultra (Ludum Dare 32)

Star Driller Ultra is easily the highest ranking game we’ve developed. The graphics above should make that pretty obvious. This is also the second Compo game (solo-only), so perhaps the ratings are more reflective of the impressiveness of that accomplishment.

Unconventional Stick Swinging Simulator (Ludum Dare 32)

Joke entry Unconventional Stick Swinging Simulator is naturally the lowest ranking game. No surprises here: it’s made within 12 hours, with a portion of that time devoted in light-baking.

Laundry Day (Ludum Dare 32)

Our attempt to make fun of free-to-play games with Laundry Day is…well, reflective of exactly what we expected people would react to the game. It’s not surprising a deliberately badly made game would get some mild scores.

The Sentient Cube (Ludum Dare 26)

And the first Ludum Dare game has…no ratings, so there’s not much to talk about here.

Removing The Sentient Cube and Unconventional Stick Swinging Simulator, score progression for each game looks like this:

Overall has been dropping since Star Driller Ultra, since we admit being more interested in experimenting in Ludum Dare than making a polished experiment. Still, innovation and fun remains very high, which is fantastic. The rest…well, hasn’t been our focus, really. The same trends can be found in the rankings progression as well:

I hate my popular game: Star Driller Ultra post-mortem

April 24, 2015 | Taro Omiya

This is amazing. the flair and style is insane, whilst the theme is a lil weak (it’s still unconventional, so that’s fine by me) the rest of this is absolutely amazing in terms of presentation and style. One of my favourites so far. Incredible stuff for 48 hours.
-Neonlare

Well done! Just well done!
I could never even begin to possibly dream of making something like this.

Very challenging on trying to focus on where everything’s coming from, where I’m supposed to go. A mini-map might help that.

Just…just…just… wow.
-Lynx

Love the feel of movement so much! Great job maximizing a beautiful art style with minimalist shapes also! This game makes me want to move on to 3D more than any other this LD 😀
-01010111

In less than a week of submission, my third Ludum Dare entry, Star Driller Ultra has 76 votes. This is easily the most popular entry I’ve put up, compared to the 2 weeks it took for The Sentient Cube to get 100 votes, and the entire 3 weeks to get 60 votes for Laundry Day. Clearly, a lot of people liked the game, with the comment section on the site being largely positive. But I have a major confession to make about the game: I hate it. Here’s the post-mortem to Star Driller Ultra:

What is Star Driller Ultra

Star Driller Ultra is a Star Fox inspired space combat game where you play as a neon-colored drill. The entire game revolves around defeating enemy ships by drilling into them using limited fuel supplies.

The idea was born from an one-hour long brainstorming session where I written down 61 short game descriptions. The one that caught my interest the most was this one:

Game about ramming into things. Think, Star Fox.

There was a video of an obscure Playstation 2 game I had in mind when planning on this game. You would always be moving towards an enemy ship, and the majority of the gameplay revolves around dodging bullet formations. Only when you’re close enough to the enemy would you have the chance to attack, via a drill.

What went right

Early prototype identified several problems

By noon on the second day of development, I had a prototype ready to test the idea. This prototype only had a cube to represent the player’s ship, and a few static enemy spheres that shoot bullets. This product helped find some problems I needed to resolve:

The camera needs to be facing towards your target
The player’s ship will always block the view to the enemy ship
It’s going to be difficult to put together tight controls in a short amount of time
- This makes it difficult to put together elaborate bullet formations, due to the ship’s reaction to the player controls
The Unity standard shader makes the game too dark to see
Enemies had terrible aim, which heavily reduced the thrills

Identifying issues this early allowed me to quickly plan on a solution to each of them.

A practical and consistent graphics

One of the first issues I’ve tackled was the player’s ship always obscures the view to the enemy ship. Ultimately, I had one of the three options to choose from:

Make the ship transparent
Make the ship exceptionally small
Make the ship a wireframe

Naturally, I chose the wireframe, as it felt like it was something most other games didn’t do. From there, I’ve experimented with Blender’s Wireframe modifier and put together a very thin ship.

After that, I dropped an unlit color shader on the ship to make sure it was always visible, even if the screen dark.

Once that was done, the rest came pretty easily: the enemies needed to be clearly visible, so I stuck with the earlier wireframe method and simply made the outlines thicker.

While I initially used unlit color shaders on enemies as well, I quickly found out that it made it harder to tell the shape and distance the player was from the enemy. Instead, I used a toon shader that provided a distinct bright color that, at the same time, made the sillouhette of the enemies clear and easy to distinguish.

Lastly, to put a nice bow to the whole package, I applied a bloom image effect, lots of trailer renderers, and star particles to fill the negative space. The result was the most easily praised feature of the game: gorgeous graphics.

Lots of enemy types

Star Driller Ultra actually features a lot of different kind of enemies: the Asteroids that replenish health; stationary enemies Turret I, X, V, and M; and moving Chasers I, X, and V. I’m personally impressed with the amount of enemies I was able to put together, especially the heatseekers and the beam types (V and M respectively), in such a short amount of time. Granted, I feel like there should have been more enemy types, since bullet formations was supposed to be a major draw in the game, but it still worked out to a cohesive experience.

Maximum juice

Thanks to years of honing this skill, adding juice to the game came very easily for me. In this simple game’s case, I only needed the following actions to have a form of juice:

Flying
Drilling
Destroying an enemy
Getting hit
Enemy firing
Bullet trail
Empty fuel
Low health warning

This amounted to some simple feedback for each aspect of the game. For a few examples, flying only needed an obvious animation on the direction the ship was facing, which I later accented with trails on all of its four back corners. Drilling uses motion blurs which, combined with the ship’s trails, spinning animation, and rainbow-colored nose particles, lead to a really hypnotic graphic. Destroying an enemy was a bit more involved: jack up the bloom intensity, and pause for a fraction of a second to let the bright lights suck you in. Lastly, add a lot of big, bright particle effect and a low growling sound to depict explosion. Knowing about these common juice techniques such as pauses, sound effects, and particles helped me polish the game at a super-rapid pace.

Proper food and sleep

I was able to balance food and sleep pretty well in my schedule. Well, that’s not much

What could have been better

Boring core mechanic

The intended flow for Star Driller Ultra was as follows:

Since working with 3D space in a space shooter is complicated enough as it is, I tried to simplify the idea by having the player always focus on one enemy only while the fight was going on in the surrounding. This means that I needed to make the locking into the enemy and dodging bullets part as fun as possible, as they take up the majority of the time in the diagram above.

I think I failed on both accounts.

The order that you lock into a desired enemy is, from the player’s perspective, completely arbitrary. Basically, all I do is aggregate a list of all enemies, then sort them by distance from the player when the scene initially loads. The list never gets re-sorted in real-time. This has a few advantages, such as allowing the designer to control which enemy the player will lock into next, but it’s disadvantages are enormous: it makes the player feel less in control.

For dodging bullets, I had a two-fold problem: I struggled to offer tight controls for the player ship without causing it to fly off or dive right into the enemy, and I couldn’t get the enemies to be better at their aim. Given these two problems, I was forced to take one of two terrible decisions:

Make the enemy bullets bigger
Allow shooting a lot of bullets

I ultimately chose the latter, thinking it was the lesser of the two evil. Regardless of whether I was right or not, neither would have made the dodging bullets part more engaging as fixing the player controls and having better enemy aims would have.

Disguised as a space combat simulator

It kinda seems like all you do is wait until you approach the target, then hold the drill button…of course, if you run out of fuel, you’re completely screwed. I don’t know, it’s got great graphics, I just didn’t find it that engaging…
-Listen2Reason

So without good lock-on system and a fun dodging mechanic, what is Star Driller Ultra, really? For a good long while, I was trying my hardest to turn the game into the space combat simulator I initially envisioned. However, as the deadline loomed, I took the defeat and polished on what I thought the game did succeed on: a resource management game where you need to handle the health and fuel meter. The health would be limited in number: you can only recover health by destroying asteroids, which needs to be locked on (a cumbersome process) from the first place. Fuel is necessary to drill, and while it deplete quickly, it also regenerates quickly as well. Additionally, drilling makes your ship invulnerable, negating the need to dodge bullets if you have enough fuel. For both, I simply put together stages that I thought balanced these aspects well enough.

Ultimately, though, I feel like I robbed the player’s expectation. As much as I tried hard to make Star Driller Ultra into an action-packed space combat simulator, I just couldn’t within the 48-hour time frame.

Poor difficulty curve

With only several hours left to put the game up, I hardly spent any time working on smoothing the game’s difficulty curve. So when it came to stage design, I relied on a simple: introduce something new in each level to keep the player engaged.

Bad idea.

I introduce different enemy types so quickly, players had a hard time catching up to even the most basic tasks, such as controls. I could have been a lot less rushed and spent a bit of time reducing the difficulty of the game.

Prioritizing on content over playability

On the second day, there was a comment from a playtester indicating that the game was hard to navigate, and a radar would have helped. Weighing on whether I should add more enemies or work on the radar system, I ultimately chose to add more enemies and levels. At the time, I thought the radar was going to take too much time to implement. Looking back, I think I greatly over-estimated the effort to add more content, and should have focused on putting together the radar first instead. Generally speaking, I favor usability over content, but this was a bizarre moment where I simply didn’t think a radar would be that high of a priority.

What will I do next

I chalk Star Driller Ultra as a pretty big mistake and a learning experience. While my ability to create juicy and visually attracting games are better than ever, I found this entry to be a bit enlightening in the fact that I still have a long way to go in deciphering what game mechanics leads to which experience. You can’t polish turd, and if the mechanic is broken, so will the rest of the game. I also think I clung to the the space combat simulator idea too much, when I could have abandoned it and made Unconventional Stick Swinging Simulator instead, or something more experimental.

Still, I’m hardly deterred. I’ve had an incredible streak with #OneGameAMonth, with such wonderful games like Suddenly, Thousands and Ichabot Crane. If anything, I think Star Driller Ultra helps me be a little more humble with a realization that I still have a lot to learn. I could use a bit of humility every once in a while.

In any case, I’ll probably continue the experimental route that I’ve worked hard on. I’ll continue to throw spaghetti on the wall, but I have one more data point this time to make the spaghetti more sticky.

Impossible Poker Post Mortem

January 30, 2015January 30, 2015 | Taro Omiya

So, I’m programmer, been consistently making digital games every month, and yet, made a card game for Global Game Jam this year. Oddly enough, I found the experience to be more challenging than the common perception would imply. While the development process of the prototypes and iterations were quick and easy, properly identifying problems with the game, as well as understanding why the inspirations for the game were so engaging proved to be more tough than expected. This is the post-mortem of Impossible Poker, a game where you don’t know the rules.

What is Impossible Poker?

Impossible Poker is a card game that’s easily playable with 4 or more people, a deck of playing cards, 2 cards with one saying ‘yes’ while the other says ‘no’, and some tokens. The game starts with one person designated as the RuleMaster, and creates a rule that governs the values of each card. Each player is given 5 cards, and they play one card from their hand at once. The RuleMaster, then, determines which played card wins, then creates a stack of that card to provide a visual history of the results (note that by default, the highest valued card wins). Finally, the players can either ask a yes or no question to the RuleMaster or make a guess to the rule using either one of their 3 tokens, or the free opportunity they’re given every 3 turns. A yes or no question will be answered privately using the yes or no cards, while guesses will be answered with a correct or incorrect publicly. The first person to guess the rules correctly wins.

Our team consisted of four people: Kelli Dunlap, Eric Vignola, James Kim, and myself, Taro Omiya. I largely worked more as a supporting role, proposing many different solutions to problems we’ve identified (most, which I admit, weren’t all that useful).

What went right?

Learning something new

I swore to myself that I would get around making a board/card game at one point, not only to experience what it’s like to work with them, but also because I strongly believed it would help me become a better game designer. Not only am I happy that I finally satisfied that bucket list, but I’ve also come to a surprising conclusion: designing analogue games aren’t all that different from video games. Much like designing digital games, creating an engaging card game revolves around creating tight feedback loops, giving steady reinforcements, and dealing with holes and exploits in the rules. The only differences I found were quick feature implementation and feedback, simpler aesthetic, and the lack of juice (which is actually a relief). This experience should be useful when I experiment with different methods to prototype before creating the final product.

A worthy challenge, with a satisfying twist

I’m also proud about taking on the challenge of creating a game where the rules aren’t obvious. It has the classic hook of, “how can you play such a crazy game” that I like to implement in most of my digital games. Plus, the game proved to be a pleasant challenge to design, with unique problems and solutions I haven’t encountered with other games. A lot of people at the end of the jam were interested in trying the game, so we were definitely onto something with that selling point.

Finally taking comfort in supporting role

As of last year, I’ve been working solo as a full-time indie developer, and it’s been a pretty big concern to me on whether I’ve started losing touch with other people. Additionally, the Global Game Jam 2013 proved to be a wake-up call when I realized I was somewhat uncomfortable at taking roles outside of designing and programming. So I was pleasantly surprised this year that not only did I feel comfortable taking on a more supportive role with the team — with my efforts focused largely on forming the team, planning a simple schedule, providing some feedback, and programming the random rules generator — but I also felt like a valuable contributor as well. I also had the feeling that throughout the development, the rest of the team members were comfortable with their roles as well. Nobody was talking over each other, we were quick to identify and solve problems, and only times when we were really tired did any of us wander off and disperse. Plus, at least for me, there was a huge sense of relief that the programming aspect of the game was completely optional rather than a major component.

What needs improvement?

That one play-tester

At 3:00 on the second day, the doors were opened to allow any curious convention goers at MAGFest to visit and play test our games at the current state. We’ve hand some wonderful feedback from several people who visited our location, but one in particular stood out: the one who lectured us for a few hours. This play-tester actually had a lot of great insight about our game, such as the lack of hints to figure out the secret rules, and the exploitable win condition. While useful, the delivery of the feedback was, well, a bit intense. I think that session left us both exhausted and unsure of ourselves. Between that time to the end of day 2, we’ve been mulling about changing the game entirely, but never been able to determine how.

A little too laid back

I think we’ve gotten a little too comfortable before that one play-tester came along to really realize some flaws in the game. Ultimately, I feel like we should have gathered feedback from other people sooner to help identify problems with the gameplay. In context, I realize this would have been difficult: most people who would play our game were stuck working on their own game at the jam site, and our game still required 4 people at least to play. Fortunately, the day 2 feedback did prove to be a good wake-up call, so we did eventually get back into shape.

Programming independently from the game design

One feedback we found early on was that it was hard to come up with 3 secret rules before the game started, making the setup time longer than necessary. It was decided in the middle to eventually program a random rule generator that would be smart enough to provide 3 non-conflicting rules so that the user can easily choose a set of rules as they please. I finally took on this task during day 3’s morning, immediately while the rest of the team decided to change the game focus from the originally gambling objective to sleuthing. I wasn’t able to communicate or update properly at the time, so right when I was done with the framework and UI design, I was surprised to here that the game changed entirely from the former 3 set of rules to any number of rules you’d like (though only one was recommended). A classic moment of terrible communication, especially on my part. Fortunately, most of the framework still worked for the game, and the rest of the team commented it’s very unlikely that anyone would want more than 2 rules to play (let alone 3), so this problem was very quickly resolved, and I was able to proceed on creating more content.

What to do next

I’ve been told numerous times that paper prototypes are the best place to start designing your game, but up to this point, I’ve only been nodding my head in reply to that advice. Now I see the real wisdom behind that advice: paper prototypes provide quicker feedback and ease in modifications that is much hard to do on the digital space. This is perfect for experimenting with different design ideas, and making sure they’re tight enough to start a bigger project. Next time when I’m brainstorming and prototyping on a game, any ideas that doesn’t rely on physics heavily will be prototyped via paper to make sure it is as engaging as I hope.

Suddenly, Thousands post-mortem

October 21, 2014September 17, 2015 | Taro Omiya

Now that Bacon Game Jam is over and I had some good time to rest, it’s a great time to do a post-mortem!

What is Suddenly, Thousands?

Suddenly, Thousands is a mob-controlling puzzle game that uses a recruit and dismiss system like Pikmin and Little King’s Story (more closer to the latter), while implementing a synchronized character movements like The Swapper. It also allows you to switch which character you play as, which turns out to be a critical element in the later levels, as some characters are shorter and can fit through smaller spaces, while others jump higher and reach higher locations. Combined with the many dynamic elements of the game, including movable blocks, deadly lasers, switches and doors, the game becomes a chaotic and challenging experience for the player, yet oddly manageable.

It was developed by one developer in 48 hours for the Bacon Game Jam. In fact, it’s available for voting right now!

What went right?

Embracing Accidents

The theme for this game jam was “millions of them.” Initially, when I was brainstorming on the theme, I’ve decided to go with a Hitman, Assassin’s Creed and Watch_D0g hybrid idea where hints identifying the person to assassinate will trickle in through your device, and you had a short time limit to figure out who it was using Facebook data and stab him. The game would use some items that would disperse the crowd, spreading them out or isolating a few people to make it easier to find your target.

If that sounds incredibly daunting for a 48-hour task, well you’d be right. It was incredibly fortunate, then, that while developing the crowd AI on the first day, I accidentally dropped 2 characters with the same control script code. Watching these 2 characters move synchronously was so mesmerizing, I literally ended up playing with it for a few minutes before dropping everything I had and said, “Screw Watch_D0gs; I’m going to make this into a game.” I couldn’t be more happy about this decision, since the code was already there and the mechanic legitimately felt fresh and satisfying.

Using External Resources

So I won’t mince my words when I say I’m a lazy programmer. Let me say that again: I’m a really, really lazy programmer. Knowing from experience that programming is typically the worst bottleneck, having the willingness to use openly available code and resources is a great attitude to have, especially during game jams. This time around, I used a lot of the code from the Unity wiki, Sample Assets (beta), and code I wrote for Ichabot Crane. They were all huge time savers.

Making Each Character Unique (Even If They’re Barely Different)

Outside of giving each character a distinct model, I also configured them to have different physical heights, running speed, and jump heights. This turned out to be a huge strength in the game, as it drastically increased the kind of puzzle elements I could introduce, and gave a distinct personality to the game to differentiate itself from its inspiration, Pikmin and The Swapper (though it’s not nearly as distinguished from Little King’s Story; that game is brimming with personality). Additionally, the differing run speeds adds a lot to the chaos, an element I found to be the most entertaining part of the game very early on. Just making small differences like these can make a huge difference in the impression one gets from the game.

The First Three Levels

Having made many game jam games by now, I pretty much have the order of which to introduce elements in a game down to a science. Basically, my formula goes like this:

Level 1 tells you how to control your character in a stale but safe and non-distracting environment.

Level 2 lets you practice what you learned one more time in a slightly more dangerous situation.

Level 3 is the level where I instantly drop the player into the meat of the game, letting them know why they’re playing the game, and why it’s so unique.

I started working on this level progression with Touch Yoga, and used String Theory and Ichabot Crane to really fine-tune this structure. I felt like Suddenly, Thousands implemented this in the best way possible, especially after watching this Let’s Play of an early build (that had a lot of bugs and only four levels, grr…) that shows how effective this strategy is.

The Last Level

Unlike Touch Yoga, String Theory, and Ichabot Crane, I felt that Suddenly, Thousands had a wonderful final level. Yes, up to this point, I haven’t been really satisfied with the last level I created for all the #OneGameAMonth games I’ve made. This time around, I think it’s perfect. It properly utilizes all the mechanics I’ve introduced the player into a single level. It has a simple and easy-to-understand layout that lets the player easily figure out where to go next. And it has the incredibly satisfying feeling of controlling a ton of characters at once. This in comparison to all the other games where it was pointlessly hard and failed to utilize all the elements introduced earlier, let alone emphasizing why the game is so interesting.

Utilizing A Task Manager

Yes, for a coder, this is a very obvious advice: use a task manager. It was a life-saver. I started using BitBucket’s issue tracker on the second day of Bacon Game Jam (first day was pointless because it was all experimentation). The tracker does an excellent job at reminding me what the priority of the tasks were, especially for this sleep-deprived event. Numerous times during the game jam, I have completely forgotten what to do next, so the issue tracker really helped!

What needs improvement?

Missed Narrative Opportunity

In an earlier post mortem, I said I would spend more time exploring gameplay and narrative integration. I…didn’t for this project. I was short on time, but I feel like this was a huge lost opportunity to experiment with narrative for this game. I mean, all the elements are right there! The need to gather outside help, check. Progression gets easier as you gather more characters, check. The need to use individual strength, check. The devastating effect of losing even just one character, check. And the work to get everyone to the finish is sloppy but satisfying, triple-check. This would have been a wonderful metaphor for the importance of teamwork and individuals, but I completely neglected it! Grr! Maybe next time…

Too Much Time Spent On Graphics

If you watch the time lapse below, you might notice that I spent a bit of time on playing around with shaders. Then I do it again a little later, this time taking hours. Then again, slightly shorter. Then yet again…

Seriously, I know I’m a graphic fanatic when it comes to designing games (I have a very high standard on the games I make, even if it’s only 48-hours), but taking this much time on it is too much. Originally, the issue I was trying to solve was the huge variance in character model and texture quality. Ultimately, I’ve decided to drop all normal maps, and use a post-processing effect that drops to details in the entire game, but the process to get there took way too much time. Seeing that graphics don’t drastically affect the development of the game, I should have left that effort until much later

Level Design at the Last Day

Broadly speaking, my development process went as follows: Brainstorming the first day, implementing puzzles and mechanics the second day, and level construction in the third. This meant I spent about 8 hours (between 10:00 AM and 6:00 PM) to complete all 12 levels and credits. Bad idea. I honestly should have reserved a few hours on the second day to create some levels, and use the third to clarify them as well as adding more. It would have given me more time to understand what makes the game really tick.

Proper Credits

I’ll be working on this later today, but I completely forgot to update the LICENSE.txt file in the BitBucket repository, which until yesterday declared that the entire project was MIT-licensed (it also stated the project was a template…which it wasn’t). I greatly apologize. I should have constantly updated the repository’s license as I imported or copied each individual file, at least to signify which folder belonged to which company/individual. Better late than never.

Lack of Marketing Material

I didn’t have much to market other than screenshots, gameplay video, and the time-lapse, which is a real shame. Right now, the Bacon Game Jam voting period is going on, so I unfortunately lack the time to construct things like trailers when other methods, like playing other people’s games, commenting, and providing lets plays, are more effective means to get votes. Plus, I need to spend some time on my next project, Prototype: Murakami.

Terribly Fickle Controls

The controls in the game is honestly not on-par with my standard. The characters move sluggishly, and the camera controls are incredibly wonky. Given the time I had, I’m only slightly unsatisfied with what I have, but I really think more time should have been spent fixing these.

Not Enough Juice

While technically, puzzle games are exempted for requiring a lot of juice, a little more could have seriously helped this game. The one element in particular I think could have benefited from juice were the switches goals, especially when a character enters or exits their field. As of right now, I only have sound and a change in label, which isn’t enough of an indicator in my opinion. Additionally, I could have in a very short amount of time implemented a projector that indicates the range of character recruitment, making the mechanic that switching characters also shifts the recruitment circle more obvious.

Lack of Sleep

Well, duh.

What will I do next?

Schedule Level Construction Earlier

Levels are obviously one of the most important core experience of video games, so I need to put more emphasis on them. In the next set of projects, I’ll do my best to allocate more time to explore designing and polishing levels. As they say, it’s not the quantity that counts, but rather, the quality.

Experiment With Gameplay and Narrative Integration

I feel really ashamed for completely missing out on this, so I’ll definitely work on it sooner with my next set of projects. In fact, as hinted earlier, I’m already working on it with Prototype: Murakami.

Get Comfortable With Making Marketing Materials During Development

It’s going to be important moving forward to get used to creating marketing material, and allocating resources to distribute them as part of the development process. I’ll spend much greater effort on this in the next set of games where I can.

In Conclusion

Honestly, I’m really satisfied with Suddenly, Thousands for the time I spent on it. I cover the level progression really well (especially when taking into consideration how stressed I was), and the game has a lot more personality than I expected. However, I had a few easily avoidable slip-ups that I need to be careful next time I attend events like these.

Suddenly, Thousands is available for free at the following venues:

“Not a Clone” Post Mortem

September 29, 2014September 29, 2014 | Taro Omiya

I’ve been debating on when to write this Post Mortem. I wanted to gauge people’s reaction to this #OneGameAMonth project before writing this post, and for the most part, I’m glad it was positive. There are several parts, though, that I felt I did a terrible job at, leaving me with mixed feelings. Overall, I think I succeeded in making an entertaining game, but not one that delivers the proper message.

What is Not a Clone?

Not a Clone is a Wario Ware Inc. style game where you play a series of super-short mobile games. The story is as follows:

Upon receiving his new smartphone, poor Jimmy downloaded all of the top-selling games that now demands every second of his attention. Help Jimmy play through as many mobile games as possible before the battery runs out!

At the end of the game, the game tallies which games you’ve played were clones, and which weren’t.

What went right?

Focused idea

Not a Clone‘s core design was to water down mobile games to 5-second chunks, then serve them with progressively increasing difficulty. It’s a super-simple concept, and one that I knew would work well. Because of how focused this concept is, I didn’t need to spend that much time experimenting and polishing the game, leading to quicker development.

Quick access to free assets

Not a Clone required creating a variety of minigame, all of them as different experiences. While I’m adept at programming, I’m nowhere near as swift when it comes to art and sound, so I was glad that I had a few libraries I can immediately rely on to complete this game. This includes graphics from Kenney, music from Kevin Macleod, particles from the Unity Asset Store, and BFXR for sound effects. These assets helped me pull through the last week of development, where I had to put everything together.

Increased efforts in marketing

Seeing that Not a Clone is a series of minigames, finding the best screenshots for this game was shockingly easy. Since each game looks visually different, I could post a new screenshot every day for two weeks and not make it look repetitive or annoying. And that’s exactly what I did.

I’ve also started using Twitter more actively, first to connect with developers from Boston FIG, then later to use hashtag-seeking bots to spread the screenshots. The latter strategy worked surprisingly well. A lot of my posts were retweeted every day with this method.

Lastly, I took the time to set up a proper trailer for the game, even though it’s a super-short game. While it’s too early to tell whether the trailers and the retweeting bots were effective strategies, I think it drastically helped from where I originally started.

Provided enough instructions to play each game

An unavoidable nightmare with games that you only have a short time to play is to actually teach the player how to play it within that time frame. This was an early complaint with my, albeit minimal, playtesters. After spending a few days working on that, and releasing the game, it seems this problem has mostly vanished. I’ve only heard of one feedback that told me a minigame was confusing, and I consider that a huge accomplishment from where I began.

I learned something new!

I always try to learn a feature I haven’t touched before on Unity, and this game was no different. This time around, I educated myself in how to use Unity’s new GUI system from the recent betas. I can say I have a very good handle on them now.

What didn’t go so well

Poor presentation of the game

Let’s get the most important thing out-of-the-way. Many people were discouraged by the game’s tagline, “a satire on the mobile game market.” I’ll go over the reason I wrote that later (and that reason might surprise you), but for the purpose of marketing this game, this was a poor, poor idea. When hearing that this game was supposed to be a satire, there were a few people who thought the game wasn’t supposed to be fun. Heck, one of my friends who played the game posted on Facebook that he thought the game was very fun, and asked why it’s a satire from the first place. The game was designed to be fun, and more importantly, addicting. So it’s my own folly that I gave precisely the opposite impression for would-be players.

The people who played the game and got the message weren’t that better off. Mainly because of this ending screenshot:

I won’t sugarcoat this: this screen is very condescending. For the people who aren’t familiar with mobile games, they would have legitimate fun playing this game, only to be scolded by the game for not recognizing which games were clones. For the people who are familiar with mobile games, this screen punishes them for not recognizing which games they played were actually original. I fully admit that not only is this screen offensive to me as well, it’s not even the message I want to deliver. Originally, I wanted to convey that the app market’s reliance on top charts and poor discovery leads to absurd number of clones due to uninformed customers. Instead, I’ve created a game that says either the player is uninformed or misinformed, and that’s why the app market is the way it is (they had fun, after all). I feel like I failed pretty badly in this regard.

Working with a controversial game is draining

To be completely honest, when I was developing this game, I was completely nervous about making it. Almost the entire time, I was debating on whether the game looked different enough from the source material, or not enough. This constant worrying left me with low confidence on the delivery of the game. The reason I had the tagline, “a satire on the mobile game market” at the beginning of the game was because I was afraid someone might think this game was a predatory attempt at cloning mobile games, despite having a clearly sarcastic title. It also lead to a ridiculous amount of time spent on the credits, just to make sure I had every necessary information in there.

Fortunately there wasn’t any immediate backlash with the game, and as mentioned earlier the reception was definitely positive. Still, considering how badly pressured I felt making the game, I doubt I’ll be making a similar game again.

Minimal Playtesting

I had exactly two playtesting sessions: one with the Dirigiballers team when they were setting up the Tumbleweed Express booth at Boston FIG, and one with the Albany Unity 3D meetup. I had many last-minute bugs and polishes at the end when building the game largely due to the lack of playtesting, and thus, the lack feedback and bug finding. A lot of the problems during the last week of development could have been easily detected with outside help.

Working with beta software

While I learned a lot about the new GUI with Unity 4.6 beta, the software was also pretty buggy. The minigame my friend commented earlier that lacked sufficient instructions was a result of Unity crashing when attempting to provide that very instructions. Since I lost a lot of back then, I’ve decided to avoid providing the intended instructions with that game.

Poor scoping

Initially I scheduled myself to create 20 minigames with unique mechanics for each one. In the end I created 26 minigames, with only 16 of them having actually unique mechanics. I ultimately blame on bad estimation on this one, especially since I’m the kind that’s easily distracted with internet.

What will I do, moving forward

Developing this game was a significant departure from what I usually make, and while a lot of parts came together well, a lot of other parts clearly needed more work. It’s clear to me that while I’ve polished my skills in making fun games, I’m still miles off from one that’s capable of conveying a message, let alone a story. Moving forward, I see it necessary that I practice more with conveying narrative into a game. Additionally, the incorrect message I gave with Not A Clone were mistakes that was easily predictable, both with playtesting and with a little reflection. For next month’s game, I’ll be seeking for a method to have regular playtesting sessions. Lastly, I’ll be work with more stable software, rather than betas so I don’t get hit with crashes again.