OneGameAMonth

Suddenly, Thousands post-mortem

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

https://www.youtube.com/watch?v=UK7I8ywegSQ

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:

Prototype: Murakami Progress #05 (November 2014 #OneGameAMonth)

| Taro Omiya

Now that the Bacon Game Jam has started, here’s a quick update: I fixed the buttons from last time. I’ve also improved the camera animation to react more quickly. Similar updates has been made to the menus as well. As mentioned earlier, point & click puzzles will be next.

PrototypeMurakami05

While I’m working on Bacon Game Jam, there might be a mysterious post that claims it’s automated. That’s the playable build of Prototype: Murakami! Now that the game is in a testable state, I’ve configured the automated system to post publicly to this blog. The prototype is, well, in super-early state, but it should bring better context to these development updates.

Prototype: Murakami Progress #04 (November 2014 #OneGameAMonth)

| Taro Omiya

Yesterday, I finished the navigation, and had a working menu system to navigate from one path to another. Today, I added in camera animations to provide better view on the paths the character can take. I’m still working on update the buttons to indicate direction, but as you can see in the screenshot below, I’ve made some progress on that as well.

PrototypeMurakami04

Once I fix the buttons (you can tell the text leaking out of the screen), the plan is to start on the Point & Click puzzles. For a week-long effort, it’s exciting to see the navigation working, but I still have a long way to go!

Prototype: Murakami Progress #03 (November 2014 #OneGameAMonth)

| Taro Omiya

Last time, I was in the middle of the rail system, particularly on setting up a menu that shows up when approaching a fork. Today, I have a prototype of the menu letting you know of the branching paths. Clicking on the buttons in the screenshot below will put Unity-chan down that path. Escaping from the menu is as easy as just turning around with a key-press (currently assigned to shift).

PrototypeMurakami03

Next up will be the camera animation. In the screenshot above, it’s hard to tell that our heroine reached a fork. Thus it’ll be necessary to visually show that the path does indeed split. That’s a little hard to do with the current suspenseful camera angle, so triggers will be implemented to pan the camera out.

Registered for Bacon Game Jam October 2014

| Taro Omiya

I forgot to mention that yes, I’ll be attending the Bacon Game Jam this weekend. Bacon Game Jam was originally created at Reddit to help game developers learn to develop and finish their project. The game I create for this game jam will cover the #OneGameAMonth for October.

Due to shoddy internet connection at my current location, I won’t be live-streaming my development progress. I will, however, attempt to create a time lapse of my progress. Assuming I don’t make the same mistake I did last Ludum Dare…

Prototype: Murakami Progress #02 (November 2014 #OneGameAMonth)

| Taro Omiya

Last time, I was working on making Unity-chan move in a pre-defined, on-rails fashion from point-to-point. Today, I implemented a button to turn the character around 180 degrees at any point in the game. Additionally, I cleaned up the running and turning animation so that the character moves very smoothly. Lastly, I updated the physics so that the player can climb and descend hills pretty easily.

PrototypeMurakami02

The screenshot above shows my work-in-progress with the rail system. Like Killer7, the intent is to have several branching paths. As of now, the connections between each points are working, but the ability to choose which direction to go when approaching a fork in the road is not. Hopefully that can be implemented tomorrow, making the prototype of a navigation system complete.

Make it Juicy Presentation Update: Scores!

| Taro Omiya

I am a little late on this update, but I added a scoring system to the game. I also added flashes and pauses into the game. I’m actually about 3/4ths done with this presentation, and hopefully by the end of tomorrow, have the entire demonstration finished (but not yet complete).

As usual, here’s the link. Any feedback to the presentation is welcome. As noted earlier, the intent is to make sure each iteration of the game actually improves from the player’s perspective.
http://gamejolt.com/games/other/make-it-juicy/35387/

“Not a Clone” Post Mortem

| 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?

https://www.youtube.com/watch?v=0bhokXGXgiU

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:

EndingScene

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.