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

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-writingprocedural 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:

  1. 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.
  2. 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.
  3. 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

“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 Rene Magritte

“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.

New Ludum Dare game: The Recursive Dollhouse

Like a swift ninja skittering across a frozen lake, Ludum Dare 37 have come and went swiftly…

Hello, everyone! Sorry for the silent treatment, but we have a new game out! Inspired by an episode of Tales of the Unusual (Japanese version of Twilight Zone), we went full-on surreal: The Recursive Dollhouse is a very strange game about a very strange dollhouse. Created by Taro Omiya, Petey Pezzulo, and Graham Lerch, this open-source first-person puzzle game involves going in deep. Very, very deep.

Full Description:

​A very strange game about a very strange dollhouse. A surreal first-person puzzle game created in 72-hours for Ludum Dare 37.

This game is funded through Patreon. Many thanks to the following:

* Adam R. Vierra
* Joshua Jennings
* XanderHD
* Tommy Pedersen
* Jacob Clark
* David Lin

Made in Tech Valley Game Space!

If you can, please rate the game, and let us know what you think!

Link to Itch.io: https://omiyagames.itch.io/artifacts-of-the-ancients

Link to GameJolt: http://gamejolt.com/games/the-recursive-dollhouse/217729

Link to Ludum Dare voting page: http://ludumdare.com/compo/ludum-dare-37/?action=preview&uid=20557

Some screenshots!

New Ludum Dare game: Artifact of the Ancients

Now that Ludum Dare 36 is over, we have a new game! We’ve attended the Jam (team development challenge) to something a little more familiar: a puzzle-platformer that involves flipping the world upside-down! Our new game is Artifact of the Ancients, created by Taro Omiya, Robert Denner, and Jason Harlow. Oh yeah it’s open-source, too!

Full Description:

Join the archaeologist, Sam, on one heck of a ride as he searches for a mythical lost treasure with his faithful companion, Lucy. You’ll flip as you experience the world from different perspectives and Sam’s life goes topsy-turvy the further he goes down the rabbit hole

This game is funded through Patreon. Many thanks to the following:
* Adam R. Vierra
* Joshua Jennings
* XanderHD
* Tommy Pedersen
* Jacob Clark

Made in Tech Valley Game Space!

If you can, please rate the game, and let us know what you think!

Link to Itch.io: https://omiyagames.itch.io/artifacts-of-the-ancients

Link to GameJolt: http://gamejolt.com/games/artifact-of-the-ancients/184344

Link to Newgrounds: http://www.newgrounds.com/portal/view/680481?updated=1472773693

Link to Ludum Dare voting page: http://ludumdare.com/compo/ludum-dare-36/?action=preview&uid=20557

Some screenshots!

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

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.

UI Mask

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:

ldjam35-1

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.

big switches

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.

ldjam35-2

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.

Block Tracks

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:

impossible platforming

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.

New Ludum Dare game: Hidden in Plain Sight

Ludum Dare 35 has come and gone, but not without a new game! We’ve attended the Jam (team development challenge) to try something completely different: make a surreal puzzle-platformer where your character’s silhouette reveals a hidden world. The journey was full of treachery and danger (read: distractions), but we finished what we set off to do! Our new game is Hidden in Plain Sight, created solo by Taro Omiya. Oh yeah it’s open-source, too!

Full Description:

A lone woman finds herself stuck in-between two dimensions, and only you can help! Guide this person to salvation using environmental cues and your own smarts. Hidden in Plain Sight is a unique puzzle-platformer where your character itself reveals a new hidden world. Use the visual cues in both the real and hidden to navigate through this treacherous world!

Note: a 3-button mouse (mouses with scroll wheels) is necessary to play.

Controls:
* WASD to move
* Space to jump
* Left-Ctrl to crouch and crawl
* Move the mouse to look around
* Use mouse scroll-wheel to zoom in and out
* Esc to pause

Created in:
* Engine: Unity
* Graphics: a combination of Unity Standard Assets, Unity-chan (Candy Rock version) and Autodesk’s free Character Generator.
* Music: GarageBand, something I made a few days ago
* Sound Effects: Unity Standard Assets and BFXR
* Font: Fira-Sans by Mozilla

This game is funded through Patreon. Many thanks to the following:
* Adam R. Vierra
* Joshua Jennings
* XanderHD
* Tommy Pedersen
* Jacob Clark

Made in Tech Valley Game Space!

If you can, please rate the game, and let us know what you think!

Link to Itch.io: https://omiyagames.itch.io/hidden-in-plain-sight

Link to GameJolt: http://gamejolt.com/games/hidden-in-plain-sight/142011

Link to Ludum Dare voting page: http://ludumdare.com/compo/ludum-dare-35/?action=preview&uid=20557

Some screenshots!

We’ll be game jamming at Ludum Dare 35!

Hello, all. We’ll be attending the Ludum Dare 35 this weekend, the largest online game jam where those attending takes the challenge of making a game in 72 hours or less. Like previous Ludum Dares, we’ll hopefully have a new game at the end of this event, so stay tuned! If you’d like to follow our activity during the weekend, we’ll be posting on the Ludum Dare website under the Omiya Games account.

As a reminder, our previous games from Ludum Dare includes:

hack.source.net

hackSourceNet4

Can I Haz Monsters?

1c12ff0628f9a64d350230100d110526

Star Driller Ultra

starDrillUltraAnimated1

Unconventional Stick Swinging Simulator

animated2

Laundry Day

20557-shot2

The Sentient Cube

The Sentient Cube

New Game: The Empire of Lights (Global Game Jam 2016)

Howdy, everyone. As noted earlier, we have a new game created for Global Game Jam last weekend. Much like the Ludum Dare before, we’ve spent this jam learning something new: programming shaders! The Empire of Lights is a visual experiment inspired by a series of René Magritte paintings with the same name. In this game, you need to collect all the coins scattered throughout the world. To reveal their position, however, one must control the position of the sun. It’s open-source, so go ahead and take a look!

Controls:

  • WASD to move
  • Space to Jump
  • Hold the Left Shift to run
  • Move the mouse to look around
  • Hold E and move the mouse around to change the sun’s position

Created in:

  • Engine: Unity
  • Graphics: A ton to name; see the game’s credits.
  • Music: GarageBand
  • Sound Effects: Unity Standard Assets and BFXR
  • Font: Fira-Sans by Mozilla

Special thanks to our Patreon patrons (https://www.patreon.com/OmiyaGames):

  • Adam R. Vierra​
  • Joshua Jennings
  • xanderhd
  • David Lin
  • Tommy Pedersen
  • Jacob Clark

Link to Itch.io: http://omiyagames.itch.io/the-empire-of-lights

Link to GameJolt: http://gamejolt.com/games/the-empire-of-lights/123111

Some screenshots!

This slideshow requires JavaScript.

And for those interested, we have a time-lapse, too!

hack.source.net Post-Mortem

“Networking programming is hard,” I’ve heard, “don’t do it.” It’s been a common consensus among us programmers that online multiplayer is simply not a beginner-friendly material, let alone a game jam material. At the time, having bits of experience programming networked software in college, I agreed with this consensus. This left a strange hole in my large library of games: I have no online games listed. Perhaps it was the Ludum Dare 34 keynote that motivated me to kick this bad habit. Either that, or the Shia LaBeouf’s video mentioned in the keynote.

Either way, hack.source.net is the first attempt I’ve ever made at an online multiplayer game, and an open-source one to boot. Despite being a bug-laden, lag-filled, unoptimized experience, I’m proud of what I was able to make in the short time given throughout Ludum Dare.

What is hack.source.net?

hack.source.net is a 2-player online first-person shooter that allows one to hack and disable up to two buttons from the opposing player’s controls at any point in the game. Born out of this Ludum Dare’s theme, “two button controls,” hack.source.net forces both players to improvise as their best abilities are taken away from them.  The game is played on the keyboard and mouse, providing each player with the following abilities:

  • WASD or arrow keys to move or strafe. In the latest version (v1.5.1), only one directional key can be hacked at a time.
  • Move the mouse to look around. This cannot be hacked, so both players can turn at all times, even if a directional key is disabled.
  • Left-click or left-Ctrl to shoot a slow-moving bullet. This cannot be hacked, so both players can play offensively at all times.
  • Esc to bring up the hacking menu. While this is up, the player can still move and look around, but cannot shoot. This cannot be hacked.
  • Right-click or left-alt to briefly conjure up a shield, reflecting any bullets back to its source. Players cannot shoot while their shield is up. This can be hacked.
  • Space to jump. This naturally provides players access to higher vantage points.  This can be hacked.
  • Hold left-shift to run, doubling their speed. This can be hacked.
  • In addition to these buttons, the radar can be hacked and removed from the opponent’s screen as well.

Combining hacks allows for a variety of strategies to emerge. For example, one could leave the opposing player in the dark by disabling the forward key and the radar. Another may disable the back key and the shield to discourage the other player from playing defensively. Yet another could take the upper ground by preventing their opponent from running and jumping. It plays like the video below, which has an older build that does allow hacking two directional keys:

What went right

Using a Game Jam to learn something new

Historically, I’ve used #OneGameAMonth to learn new features in Unity 5, such as path-finding and the recent UGUI framework. This is for multiple reasons: for starts, even if my game turned out to be bunk, I still took something new and important away from it. Learning just one aspect of a game engine also helps me creatively, developing games that mechanically revolves around one focused feature. As of late, I’ve been focusing on creating Not a Clone mobile remake for so long, I haven’t had an opportunity to learn new things about my game-engine-of-choice. As such, I took the risk to learn and practice the latest UNET framework, using the hacking mechanic to justify the mandatory online connection. Even though the game is very rough on the edges, it’s still lauded for an interesting premise.

Utilizing Unity Standard Asset’s FPS controller

From experience, I knew that the majority of my time during this jam was going to be spent learning network programming. As such, I had to come up with how the game was going to be played as quickly as possible. In this case, I chose to use the first-person controller that comes with the Unity Standard Assets rather than the third-person controller. It comes with the game engine, after all, and it reduces the number of problems I would have to deal with such as camera placement. The rest of the design decisions came naturally from this first choice:

  • Players would fight each other with slow-moving bullets. This would give meaning to the built-in run button.
  • Neither player can hack the shoot button. If I were to allow it, both players could disable each others shoot button, leading to a stalemate.
  • Since the directional controls can be hacked, a player could potentially be cornered. For these situations, a defensive option is necessary, thus giving birth to the reflective shield.
  • This game favors implementing as many useful abilities as possible to balance out the hacking ability.
  • And so forth.

Quick GUI generation

Seeing as menus are a common thing that needs to be implemented in every game, I created a simple GUI manager in my Template Unity Project before the jam. Originally, the GUI manager, along with various example menus for the most common functionalities, was made for a single-player experience. To my surprise, the same code proved to be a time-saving feature for this game as well, allowing me to create a large number of menus in a short amount of time. The hack menu, for example, was simply a re-purposed pause menu that doesn’t stop time, and includes an extra hierarchy of menus that lists all the buttons available for hacking.

Incremental building, frequent testing

Perhaps due to my exposure to Agile development, I always develop with an hourly milestones in mind. In practice, this meant that the first few hours were focused on following tutorials to sync the position of two players, and testing to make sure this worked. The next few hour is focused on syncing the rotation of both players, and testing to make sure this new feature behaved properly. Next hour was on shooting, and so forth. Even the most basic feature was put into its own milestone, followed by thorough testing. To help this, I used tools such as version control (Mercurial + BitBucket) and continuous integration (Unity Cloud) so I can stay focused on coding and testing.

This strategy proved vital for this project since I was just learning network programming, and thus, prone to making errors and mistakes. By testing often, especially after a new feature has been implemented, it helps reduce the time spent on technical problems by keeping the scope of changes small.

Last minute graphical polish

I have a bad habit of focusing on graphics too early in development, which leads to a beautiful game that needs gameplay polishes. This time around, however, I worked on graphics last, which provided me more time to work out technical problems. Unfortunately, technical problems defined my entire development process of hack.source.net, so this isn’t saying much.

What could have been better

One day wasted

As it turns out, I was planning to work with barcode on MaskGarden on the first day of the jam. They overslept, however, and arrived at our real-world meeting place at around 5:00 PM. In a bit of a pickle, I’ve decided to start on my own project at around 1:00 PM. Those doing the math and correctly assuming we live in the Eastern timezone will realize I lost 16 hours. Yikes!

Slow testing, debugging

Network programming is hard. This bears repeating: network programming is really, really hard. A huge annoyance I needed to deal with while testing was the actual setup itself. For a single player game, testing a feature is as easy as clicking the play button on Unity. For networked game, I needed to build the game (a long process on its own), play it, then press play on Unity and connect the build to Unity. I would have to test both the game running on Unity and on the build to make sure when either sends a message to the server, the other receives that information. And this is before I notice something goes wrong! If something goes wrong on the build side but not on Unity, I then have to stop both, host from the build, then connect Unity to the build to check for any errors that may appear on the console. And if I make a fix, I need to go through all this process again to verify it’s gone.

Needless to say, testing and debugging a networked game is a time-consuming process. Since I was just learning how to code with networking, technical issues would occur often, and the grand majority of time developing was taken from debugging and the many attempts at fixing bugs. This experience sure gave me a whole new respect for network programmers.

Missing features

One major feature I never got around learning, let alone implementing, is the latency prediction in most online games. This is pretty huge: I knew that I needed to keep the data sent to the server to a minimum, so I could have drastically improved the user experience by making predictions to player movement and bullets. Sadly, the debugging process alone was enough to punt this feature out of the scope of the jam, leading to a very laggy game. As someone who prioritizes the user experience above all else, this is very shameful.

No play-testing

Sadly, I was never able to find the time to have the game play-tested by other players. Consumed both by the debugging process and hosting the real-world meeting event at the same time, there simply wasn’t enough time to ask others to play, let alone setup. Given this nightmare situation, I simply went with the fastest, minimal plan. Naturally, this resulted with an unstable, laggy, difficult-to-setup game.

Convoluted setup process

The current game requires setting up your computer’s firewall properly, and knowing how to obtain your own IP address to send to your friend to connect to your computer. Due to the minimalist peer-to-peer network setup, a lot of Ludum Dare judges could not actually play the game. This obviously breaks down the most important feature in Ludum Dare: the online feedback of other developers, letting you know what you can improve on next time. It would have helped if I knew how to make the process of connecting 2 players easily, such as creating a lobby server everyone can connect to and find others online to compete with. Obviously, this is well beyond the game jam scope, but it would have been nice to have.

That strange moment where a stranger was staring at what you’re doing

At the same time I was developing hack.source.net, I was also organizing our real-world meeting. Fortunately, the meeting has gone very smoothly, with our participants creating 8 new games, including become a game developer in 60 seconds. That said, the weirdest experience I had throughout this event was when we were visited by a certain tourist. To clarify, we reserved a quiet community room in a makerspace building, so while the makerspace receives a lot of tourists, the room itself remained a quiet and productive place. We did have, though, one persistent visitor who was curious enough about game development to ask if they can see what I was doing. I agreed to this, but immediately regretted it when they sat next to me, staring silently while I try to figure out what I was doing before. This experience only lasted for about 20 minutes, but it was the most awkward moment I had in a jam. I can only say I’m glad I was the only one who suffered from this.

What will I do next

Chanced are very high the next game jam game I’ll work on will not involve with networking again. The time spent on testing and debugging alone is enough to make the task unfeasible in a short amount of time. That said, for any longer-term projects (such as #OneGameAMonth), I think it’s worth learning how to create latency prediction and lobby servers to create a more streamlined experience. Improving hack.source.net, especially down-grading the power of hacking, will need a lot of brainstorming and efforts that won’t be easy to do alone. Efforts on that game will probably remain stagnant for a while as I finish developing Not a Clone.

Also, to avoid the same strange visitor incident from happening again, I’ll need to let the building organizers know that we don’t accept tourists into our area.