• trykon

One Game a Week 2014: A Retrospective

With One Game a Week 2019 starting in just a few days, I've been thinking a lot about the last time I worked on this kind of project. I wanted to take some time to look back on the games I created five years ago. I thought it would be interesting to see what I was able to accomplish in a week back then, and how that compares to the games I create this year.


So let's take a little stroll into the past. The year is 2014. Flappy Bird was released less than a year earlier. Candy Crush was all the rage. And I was a novice game developer trying to gain some experience -- so I decided to dedicate my time to following Rami Ismail's advice of making one new game each week.

As I mentioned in my One Game a Week announcement post, I spent about eight weeks back in 2014 working on these lovely little prototypes. I worked on this project together with my friend Benjamin. We decided that rather than collaborating on one game together, we'd each work on our own game every week -- but we would still keep an eye on each other's progress to help provide motivation and feedback. Each week would follow a similar formula -- we'd start off the week with a planning meeting, where we tried to brainstorm some ideas about what kind of game each of us might make and do a rough outline of what the code architecture would look like. We were trying to mimic a real work environment as much as possible, so we even did daily “standup” meetings over Google Hangouts where we would talk about our progress and bring up any big technical hurdles we’d faced. Sometimes those calls would lead to longer problem-solving sessions -- like when we tried to come up with three different difficulties of artificial intelligence for Benjamin's Nibbles clone -- or sometimes these meetings would just serve as a quick check-in. Whether they were long or short, though, doing these daily meetings certainly added a degree of “realness” to the whole process.



The Bad News About My Old Projects

I'll start with the bad news -- I do not have playable versions of any of my games from OGAW 2014. Each of the games I made for the project were made in Unity. For most of them, I built them for Unity's Webplayer for ease of distribution -- it was much simpler to send someone a link to something that they could play right in their browser, rather than something they needed to download and run locally. This was a choice that was very convenient at the time, but a choice that has not aged well due to Unity's lack of support for their Webplayer and the increased security measures for most modern browsers. I was hoping to show playable builds of each of my OGAW 2014 games, but after a couple of hours of frustration, I have not been able to find a way to get the old Webplayer builds to run in any browser -- not Chrome, not Firefox, not Edge -- I even downloaded Opera to try and see if I could get some of my old games to run.


No such luck.


If anyone has any advice about how to run old Webplayer games, I'd love to know how to do it. I tried to upgrade some of the projects to a recent version of Unity so I could try to build them for WebGL, but it seems like that introduces breaking changes into almost every project. Given no other choice, I will eventually sort through these bugs and fix each of the games -- but it would be nice to not have to do that.


So with that caveat -- let's get to the games!


The Games

Week 1: Rocketshapes

I remember reading some advice back in 2014 which said that you should try and design mechanics around something that is inherently fun. That sounded logical, so I tried to brainstorm a list of things that were inherently fun to do. One interesting item on the list these awesome little blocks I used to play with when I was younger:


These little blocks were the highlight of my day!

At the time I didn't know the correct name for them. After some searching, I saw that they were called "Pattern Blocks" -- these were one of my all-time favorite things to play with in school. I loved creating structures out of these shapes, so I decided the player would mimic that in the core mechanic of the game. I eventually decided they would try to build a structure outward, avoiding obstacles as they went.

As I searched for art to use in my game, I came across some cool assets revolving around an outer space theme. At that point, the only thing I was really committed to was the mechanic -- so for no reason other than easily accessible art, I decided to set the game in space. And thus, Rocketshapes was born.


It was small in scope and rough around the edges, but this was the first game I ever finished!

The basic idea is that you create a chain of shapes by placing a new shape alongside any open edge of your current active shape. Then, the newly placed shape becomes your active shape. You are given a small Tetris-like preview of the next five shapes to come so you can plan out how you're going to construct your chain. I also programmed a little semi-transparent preview of where the next shape would be placed -- but you could rotate that to any unoccupied edge. All the while, you try to avoid obstacles such as little electric gates and asteroids falling from the top of the screen. You only get a game over when your active shape is hit by something, so it's fine if your existing chain gets demolished. To try and keep the player moving, a giant lava pit chases the player from the bottom of the screen -- so if you don't move quickly enough, your active shape will get destroyed by the lava.


During my search for music to use in the game, I came across one of the most useful and incredible websites for my game-jamming activities -- the incredible Kevin Macleod and his website where he hosts free music. I found a song that really instilled some action into my game. It really came together by the fifth day of the week, and I spent the last two days polishing it up and trying to craft tricky obstacles.

To this day, Rocketshapes remains one of my all-time favorite games I've ever created. I've had very intense back-and-forth contests to try and maintain my spot on top of the leaderboard among my friends -- that competitive aspect really makes it addictive in a way that some of my other games aren't. Of all the games I'd love to share, this is high up on the list.

Week 2: Sick Day


After creating an action-arcade game during my first week, I went in a very different direction for my second game. I decided to try and make something with Gameboy-style graphics that was focused more on the story and less on a fast-paced mechanic.


Sick Day is a game that is near and dear to my heart. It’s a deeply emotional narrative adventure game about staying home from school when you’re sick. The core mechanic is not so interesting -- it's mostly about walking around your house and reading different people's diaries to learn about the story. Thematically, though, Sick Day talks about themes of children’s agency, how to relate to your parents, isolation, and antisocial behaviour — all things that I’ve experienced in my childhood. The whole thing is wrapped in my own painstakingly created pixel art -- I tried to style it in a similar way to the first Pokemon games, even borrowing the idea of a single-colored palette. Although the game's themes were really important to me, and I'm glad I got to create a game that tackled these topics, the actual execution of developing this game taught me a few hard lessons.

The main character on the left, interacting with his little brother on the right.

This was the first game that really showed me how limited one week is in terms of development time. Really, I could call this week a failure — I ended up cheating a bit and spending 10 days on this project instead of the allotted 7, and I still didn’t really get a playable build. Creating code to have characters talk to one another, plus writing the code to properly detect collisions against the environment -- these things take time. Also factor in the time for creating all of my own pixel art, and this was a game that was not scoped properly at all.

Mechanically, the game is pretty terrible, and from a visual art standpoint, it's pretty terrible too. But the underlying theme -- the story I really wanted to tell -- I think that still resonates with me. Maybe the ethos of Sick Day will appear in another game I work on at some point down the line. It still sometimes gets me a bit teary-eyed to put myself inside the mind of the character in this game -- so vulnerable, so scared. I hate the idea of forcing children to do something that makes them miserable when they feel like they have no power over their own life, and that's how I felt about being forced to go to school when I was younger. I guess it was probably a necessary evil -- but I think it's an emotion worth exploring, and some day I might take the time to explore it again.


Week 3: Puzzle Island

After struggling to complete a game that was far too large in scope in week 2, I decided to go in the opposite direction and design a game that would be easy to create in seven days. I tried to do something inspired by Candy Crush, which was insanely popular at the time. In my game, instead of matching three similar objects, you would click on a particular item, and it would disappear along with any blocks touching it that had the matching color, allowing existing or new blocks to fall down in those spaces. You had a limited number of moves overall, so you would try to strategically get blocks to line up together.


My first "casual" game, Puzzle Island.

Puzzle Island is probably the game I have the coldest take on. I did complete it within the allocated time, which was a win compared to week 2. But looking back, it doesn't inspire me the way some of these other games do. I guess this might have been an exercise in learning what kind of game I don't love to make.

Week 4: 4-Dimensional Design Studio

Okay, so this game is a weird one in a lot of different ways. The first thing that make this game unusual is the fact that I made this game for Ludum Dare 29 — so I did not even spend a full week on this project. Instead, I did it within the constraints of Ludum Dare's Compo rules -- I created all the art and code myself, and I did it within the span of a single weekend.


As for how I came up with the idea -- I'm happy to try and explain it, but let's just say it is way more convoluted than necessary. The theme for this game was "Beneath The Surface". At the time, I thought that I would capture people's attention if I took a really abstract interpretation of the theme. So rather than creating a game about being under the surface of the earth or something straightforward like that, I decided to write a whole list of different, interesting interpretations of the theme.


Ultimately, what I decided was this -- I would try and do a game about being "Beneath The Surface....of Time".


The idea was to take some sort of structure, and have the player reverse-engineer the steps of how it was created. The final product the player was given would be the "blueprint" with all of the steps already taken. I wanted to have the blueprint already contain all the information necessary, but the player had to figure out the sequence of moves beneath the surface and what order they happened in. Essentially, this was my idea of having the player figure out what was "Beneath The Surface" of time. Since time is often thought of as the 4th dimension, I tried to explain this concept by calling the blueprint a "4-dimensional object" -- and so you, as the player, were an employee in a 4-dimensional design studio, trying to find ways to create these blueprints.


If you've ever wondered what your desk would look like as an employee at a 4-dimensional design studio...well, now you know!

If you don't follow how I came up with the idea, don't worry -- I was trying way too hard to try and be clever and it doesn't really make any sense. But the game itself was pretty fun -- you would try to use the computer on the left to figure out the sequence of moves required to "paint" the image seen on the right. The constraint was that the blocks would each paint the image at the same time, and they could never touch one another in any way -- so you had to try and have the blue square and the yellow square touch the same point in the image to create green, but make sure the blue square and yellow square didn't end up in the same position at the same time.


Between levels, your boss would check in on you, often having bizarre or funny things to say. The boss talking was kind of a throwaway feature that I spent maybe 90 minutes creating at the very end of the weekend, but it ended up garnering a lot of praise from the Ludum Dare voters.


This game ended up being a bit of a spiritual precursor to my commercial game, Omnicube. The color-coded puzzle element was not dissimilar to my choice of the block-sliding mechanic for Omnicube, and the silly comments made by the boss in 4D Design Studio was very similar to the conversations you can have with the Omnicube in each level.


Unlike Puzzle Island, when I look back at 4-D design studio, it really makes me feel excited. It makes me want to sit down and create new levels and write new funny things for the boss to say. This is definitely a game from OGAW 2014 that I'm very proud of!



Week 5: Super Benjamin 64

For my fifth OGAW 2014 project, I decided to venture into the world of 3D platformers. One of my all-time favorite games was Super Mario 64, and so I decided to try and make a scaled-down version of that. I thought that if I could at least get a fully-working set of platformer mechanics, that would serve me well in the future, even if the actual game kind of sucked.


Compare this to a screenshot from Super Mario 64 -- you can hardly tell the difference!

Needless to say, this was another overambitious project. I ended up spending a few extra days on this game too, but I did get a playable build. The character art, if you can believe it, was modelled by me -- it kind of makes me cringe, but it kind of makes me smile too. I had a lot of fun trying to build a colorful, vibrant world that was reminiscent of some of the classic Super Mario 64 levels -- I realized that it's harder to do than it seems. Trying to build my own world game me a lot of respect for the creators of Super Mario 64.


I would love to return to this kind of game one day and build out more worlds — but the version I did end up with was pretty fun. A very fun background music track and some challenging platforming made this a fond game for me to look back on.

Week 6: Canvas

After spending a lot of time getting my 3D platformer code working for my week 5 game, I decided to do another 3D game and re-use some of that code -- that way, I could focus more on the game-specific content and polish, rather than spending most of the week creating the baseline code needed to move around the world.


I decided to base my sixth game off of The Legend of Zelda -- my sixth game’s aesthetic is largely based off of the Temple of Time from Ocarina of Time. There is a haunting, hallowed musical track playing in the background, and the floors are all white marble. The whole experience has this immaculate, holy-temple type of vibe to it.


My week 6 game was called Canvas -- the central mechanic revolved around an item called the Color Wand. There were a series of paintings throughout the world, and you could use the Color Wand to change the color of certain sections of the paintings. By painting certain things the right color, you could unlock doors.


The title screen for Canvas -- it really captures the visual aesthetic of the game.


The power of Color Wand extended beyond just paintings, as well -- many of the other objects in the world could have their color manipulated by the Color Wand, and sometimes it would change the object's behavior. For example, a purple platform moving side-to-side could be painted green, at which point it would start moving up and down instead. As the player progressed through the temple, they unlocked more and more colors that they could cast with the Color Wand, opening up even more possibilities for manipulating the world around them.



Our stick-figure protagonist stares longingly at one of the scrolls as he tries to figure out how he's going to reach it.


Every time I think back to Canvas, I'm reminded of how much I love the mechanic. The ability to change so many aspects of the world really gets the mind racing -- there are so many possibilities for how you could access new areas. The other thing that always jumps out at me, though, is the story I built in to the game. Scattered throughout the temple are scrolls, which can be read by the player -- and eventually you discover that these are being written by some long-lost love of our protagonist. It explores theme of hurt, love, loneliness, regret -- all things that I remember vividly experiencing at the time I was making this game. Canvas, maybe more so than any other game I've created, is really imbued with my mind, my heart, and my soul -- I tried to make clever puzzles for the player, but I also poured a raw and vulnerable part of myself into the story elements. It makes me sad to think about some of the emotions involved in the story, but mostly, I feel very proud of the final product -- it really feels like art to me. Canvas is definitely one of my greatest pieces of work as a game developer.



Week 7: Vexation: The Life and Times of Victor the Vector

In the summer of 2014, the company behind the game creation software RPG Maker decided to host a game development contest. Benjamin and I decided to work together on an entry for this contest -- a game we originally called "Vectorman", but later changed to the much more pithy title of "Vexation: The Life and Times of Victor the Vector". This wasn’t really a One Game a Week game — it was a collaboration between myself and Benjamin, and we worked on it part time over the course of a couple of weeks, rather than the time limit of a single 7-day span. This game did take up all of our OGAW time, though, which is why I'm including it this list anyway.


The core idea of this game was that the player moved by drawing vectors, and then the character would follow the magnitude and direction of that vector, sticking to whatever surface you ran into. So you would hop from surface to surface, trying to point the character in the right direction -- drawing larger vectors when you wanted the player to move more quickly. It was kind of my way of taking math concepts and translating them into game mechanics -- I always loved drawing lines and shapes and vectors on graph paper, and so this game borrowed from that fundamental experience and turned it into a game set in this sort of neon-glow aesthetic.



That little blue square is actually the character!

The mechanic didn't work perfectly according to how we drew it up -- ideally, you could only hop from one surface to another, but in practice, you could make a bunch of small vectors to inch your way along one surface which sort of undermined the challenge of some of the areas. Overall, though, it was a pretty fun and decently challenging game. I like to think it's got a pretty unique mechanic, too -- when I was trying to decide what to do for my first commercial game later on in 2014, I strongly considered working more on this game to try and polish it up. I didn't end up going all-in on this particular game, but some day I might!

Week 8: A Link Between Screens

A couple of weeks passed while we were working on Vexation, and then we took a little break from development -- and before we knew it, it was once again time for Ludum Dare. It turned out that this Ludum Dare game was my final OGAW 2014 game, though I didn't know it at the time. The theme this time was "Entire Game on One Screen". I spent a lot of time trying to brainstorm a cool mechanic, and ultimately I decided on something pretty neat.



The overall gameplay is similar to a 2D Zelda game like Link's Awakening. I wrote a very rough set of movement code and the ability to swing a sword, but what I spent most of my time implementing was the new mechanic I devised -- a mechanic I called the "Puzzle Gloves". These gloves would allow the player to click on a certain part of the map and drag it to a new location, essentially rearranging the map.



This is a before and after image -- on the left is the normal map configuration, and on the right, the player has dragged part of the map over to connect it with the purple door area. By clicking and dragging on a segment of the map, you can move it to any open slot -- creating new pathways. This lets the player reach the previously inaccessible purple door.



I spent the majority of the weekend implementing the Puzzle Gloves mechanic -- constructing the world into a set of tiles that could be rearranged by the player and working out the logic for when a certain tile could or could not be moved. I also spent some time trying to design a world that would be interesting to rearrange -- I wanted the player to have to think a little bit about how they could leverage the mechanic to collect the keys and then reach the door to progress to the next level. Ultimately, trying to fit all of this onto a single screen limited the design pretty significantly, but the actual core idea is still pretty awesome -- it's one of my favorite games to have people play without knowing what the mechanic is. They think they're playing a straightfoward 2D action game, until they try out the puzzles gloves for the first time. It almost always elicits a "whooa!!!" when they discover the control they have over the shape of the world. I think this is a mechanic that could be really neat to try and use in a larger project -- alas, for the purposes of a Ludum Dare game, this was not a realistic possibility.


A Link Between Screens was the last real One Game a Week game that I completed. Although I dearly loved working on these little prototypes, none of the games really felt like fully fleshed out creations that I could sell commercially -- they just didn't have the necessary level of polish. I felt the need to focus my time on one serious project, one that I could work on for several months to make sure it had a high degree of polish and professionalism.


So it was at this point that II started working on Omnicube! The development process for that game ended up taking me a lot more than a few months to complete...but that's a story for another time.






So that’s a brief history of my One Game a Week experience back in 2014.

Now that I've had a chance to show you the kinds of games I worked on back in 2014, I want to take some time to reflect on the lessons I took away from that experience. I'm going to write a separate article about the lessons I learned.


Don't forget that I'll be starting the 2019 version of One Game a Week on Monday, February 11th!


Thanks for strolling down memory lane with me, and I'm looking forward to sharing some of the things that I learned along the way!


--Kyle


#onegameaweek #OGAW #gamedev #indiedev

84 views