Blogs - pebbz

So there's been a recent trend of live narration in video games and I have to say that I'm a big fan. The two most obvious examples to me would be Bastion and The Stanley Parable. By including a narrator to direct the storyline of your game, you can eliminate the need of interrupting gameplay in order to tell a story. I've said before in my blog posts that I'm not a big fan of intrusive story segments (Metal Gear Solid, I'm looking at you) and I have a large interest in developing games that tell a story without disrupting gameplay. So obviously, I decided that I should follow suit and put my own spin on the idea of a live narrative.

Yah... I quickly learned that some of the intricacies of creating a narrator can go over the head of someone who has never thought about the finer details before. To design a game where each artistic aspect reinforces each other, deciding the character of the narrator first is key. The narrator has to not only mesh well with the music, but also the art design and gameplay as well. Imagine playing Sonic with the narrator from Bastion, doesn't exactly sync well together do they? That doesn't even take into account the possibility of the narrator having some sort of impact on the storyline itself. In The Stanley Parable, the narrator is somewhat disconnected from the story itself as he speaks as more of a godlike figure. Compare that to Bastion, where the narrator is one of the few characters in the game, Rucks. He obviously has a personality and his narration comes from his perspective of the situation.

One key thing that I noticed from playing Bastion was that despite the fact that the narrator clearly had his own personality, his character had little weight on the plot and he could have easily been swapped out with a different character. While this isn't that big of a deal, I do think that having a narrator can be used in more extensive and thought-provoking ways. Throughout Bastion we get a decent idea of what the character of the narrator is, without dwelling too much on his personality and his motives. The focus of the story is still on the main character, the Kid, and the desolite world that they live in.

So what if we put a large focus of the story on the actual character of the narrator himself? One of the most complex things about creating stories is the motives and personalities of the characters. Anyone can design an outline for an interesting story, hell I'm sure most people probably made a few back in kindergarten. Creating interesting, believable and relatable characters that drive the story is the hard part. By using a narrator we have the ability to fully explore and develop a single character. Even if in comparison the other characters in the game are bland, we can take a very in-depth look at that single individual. If we set it up so that one person is the driving force behind the plot of the game, we can ignore the fact that the other characters aren't as fleshed out. Developing a story focused around a single character is difficult but not impossible, just look at Cast Away or I Am Legend.

But now here comes the hard part. To construct a storyline that is so heavily dependant on a single character, you have to plan ahead, a lot. You need to know exactly why this character is the way that they are, they need to have a obvious motive behind everything that they do. If you focus heavily on a single character, people will notice any sort of flaw that exists in that character if you screw up. This can cause a significant amount of overhead when creating a game because whereas some games might have a storyline that evolves during development, in this case the narrator's personality will need to be clearly defined to start. If the character of the narrator starts changing during development, a lot of additional work will need to be redone to make sure the narration is consistent throughout the game. Also mix that with the fact that the narrator should match the gameplay/art/music to get the most out of the experience, you may end up getting yourself in some tricky situations as a designer.

Once it works though, it is incomparable. There aren't really any games that can match the storytime atmosphere given off by Bastion, or the somewhat peaceful but still uneasy narration delivered in The Stanley Parable. It gives your game a very specific type of attitude which can't easily be recreated or copied. While I would love to show off what kind of narrative we have in progress, at this point it would only take away from the final product. We're still too busy finalizing the personality of our narrator, so I wouldn't want to jump the gun. Let's just say that 2015 will be a very progressive year for our development and I can't wait to see the way things turn out.

So I had the unfortunate opportunity to learn about component-driven development during a job interview for a potential internship at a mobile games studio. Despite the fact that I was geniunely interested in learning more about it and that I hoped to teach myself prior to starting the job, I don't think they were too interested in a student who knew nothing about the topic. Let's just say I didn't get that internship.

It's been a couple years since that interview and I like to think I'm at least slightly more knowledgeable about certain design patterns. So when it came time to finally design the engine which I was going to use for my first marketable game, I immediately decided that I should focus on designing it as an entity-component system. The decision was pretty easy considering how well Unity pushes the design pattern via the Inspector. My main goal though, even more so then using components, was to design an engine which I could add and edit with little development overhead. I wanted to simplify the process of creating new objects to the point where it would take me virtually no time to create something like a new enemy.

For this post, I'll give a high level overview of how I designed the engine to be easily modifiable and expandable. In a later post (don't know how long from now) I'll go more in depth with certain aspects of the code and how it all works together. If you have any specific questions, feel free to ask in the comments. If the question is simple I may just answer it there, but if it is more long-winded I'll probably include it in the sequel to this blog post.

Since this wasn't my first attempt at designing a component based engine, I already knew one issue that I wanted to avoid, the overuse of components. Components are super helpful and great for abstracting out a specific mechanic or piece of code; but, they are only as useful as you make them. Just like anything else in development, they are a tool which can help or hinder you depending on how you use them. There's no point creating a design where each object is required to have 10 components, and while that is a gross oversimplification, overengineering can lead to some serious headaches down the road. Considering I'm only creating a 2D engine, I don't need an excessive amount of components per object.

So let's break down a basic enemy object into potential components, I'll use the example of a Goomba since it's easy to understand and most 2D platformers have their own example of an enemy with a similar movement pattern. The most basic requirements for a Goomba object can be broken down into a few components (X/Y position, Horizontal/Vertical speed + Gravity, Collisions and Sprite updates):

While some might argue that you could break it down into even more components, I like to believe in the KISS principle (aka, Keep It Simple Stupid). It's better to nail the fundamentals first before adding all the fancy trim so let's do just that. Out of the possible components I outlined above, we can start to predict what will be the basic structure of an object in our engine. Obviously the most important part of all the components is the position of the object, as speed/collisions/rendering are all dependant on the coordinates in a 2D space.

I decided to call the component which handles this most basic functionality the BaseObject, as all the other components are supplementary to it. I would normally call this the GameObject, but Unity already uses that name heavily and I don't want to fight against Unity THAT much. Let's give names to the remaining components as well to make this a bit easier to follow. The component which handles the horizontal/vertical speed and gravity will be called the PhysicsObject, the component which handles the collision event handling will be called the CollisionObject and the component which handles the changes in animation and/or sprite will be called the SpriteObject.

Now looking at these other non-BaseObject components, none of them are really required for a typical object. Not every object will need a PhysicsObject (stationary objects), not every object will need a CollisionObject (non-interactive objects) and not every object will need a SpriteObject (static sprites with no animations). BaseObject on the other hand is required, so let's build these three components to be optional extensions to the BaseObject component.

By structuring our model like this, we use BaseObject as a single point of reference for all of the additional components on the object. While the Update function is called for each component by Unity, we can instead have the BaseObject handle the updating of the other components instead, forcing Update to be called only once for the whole GameObject. Necessary? No. Clean? Yes.

So since I'm just giving a quick overview in this post, I'm going to avoid posting code or going too in depth with the functionality of each component. Instead I'm going to focus on the design decisions made to allow quick changes to these components to streamline the development time.

Let's start with the simplest case, the SpriteObject. This component doesn't need much more then basic functions to change the current sprite or animation time. In all honesty, I haven't gone into too much depth with this component myself yet as I've had no need to. We're only using development art at this time, so I would be wasting valuable dev time by trying to expand it at this point. Once I figure out the type of assets that we'll be using, I'll start thinking on how to extend the design of this component.

The PhysicsObject isn't exactly complex either, but it is important to have it easily modifiable. While each object tends to have it's own unique SpriteObject, the PhysicsObject doesn't require many variations. By using public fields for the force of gravity, acceleration, friction, horizontal speed, vertical speed and maximum velocity, it's easy to adjust the physics of the object directly in the Inspector. All the component is required to do is move the BaseObject via those values.

The CollisionObject component on the other hand is an important one to design to be modular. Each object will likely have it's own variation of the component, so we want to minimalize the overhead of setting it up. The best way to do this is to design the class to use mock handler functions. If we design the base CollisionObject class to detect collisions and call a function stub based on the type of object collided with, classes that inherit from the class can simply override the stub to handle the collision. This logic is illustrated in the diagram below:

This creates a desirable interface for handling collisions. Each object contains a script which inherits from the base CollisionObject class and defines the behaviour during different kinds of collisions. It doesn't get much more clean and simple then this, and it can take literally seconds to define the behaviour of a collision between two objects. Unlike the PhysicsObject the behaviour cannot be set in the Inspector, but handling collisions is fairly more complex than setting the speed of an object so this is to be expected.

While unique functionality of each object must still be defined by the BaseObject, we were successfully able to abstract out the optional logic for physics, collisions and sprites into their own components. Also by having these optional components accessible via the BaseObject, it is easy to cross-reference them in scripts. While some people may have their own opinions on how they like to structure their engines, I tend to like to take the most simple approach as long as it is still efficient. By creating my own engine it becomes a lot easier to streamline my development to my own personal preferences, which to me is extremely important. I like development but I like design better, so the more time I can spend on designing my game instead of dabbling in code, the better.

So one of the major things that I wanted to focus on when I started designing games, was exploring what video games could become as an artistic medium. I know I'm definitely not the first one to bring up this issue and I think I can assume that most, if not all, of the indie developer community already considers it an art. That being said, there are a large portion of people out there who either don't agree with us, or simply don't care. And to be honest, I'm fine with that. As opposed to trying to convince them, I'll spend my time doing what I do best, and that's making games. You can't convince someone who isn't listening anyway, so to me, the only solution to this problem is time.

So now that we're off that topic, let's start dissecting what actually makes video games different from any other artistic medium. Obviously one of the first things that comes to mind is the fact that video games are played. Video games take input, which can't be said of any other medium. Books must be read, movies must be watched, music must be heard, etc. As the only medium which can accept user input, this is the only medium where the story can be affected by the user (I'm not counting Choose Your Own Adventure Books).

Now many games have caught on to this already and realized that this allows for multiple scenarios within the same story. There are quite a few notable series of games that have already played with the concept of alternate storylines, and personally I don't have much interest in currently exploring that method of storytelling myself. So let's explore how else user input could add to the medium in an artistic sense.

A result of the story being affected by the user, is that the story now relies on the user for certain storyline events. They are given somewhat a sense of responsibility over the storyline, as opposed to just 'soaking it in' like you would expect from other mediums. This sense of responsibility opens a whole new realm of possibility, not only in just storytelling methods, but also in the emotions felt by the player of the game. Let's take Pikmin for example.

In Pikmin, the player must raise and protect their pikmin in order to progress. The player is given the responsibility of raising them and protecting them, but if they screw up it will cost the lives of their pikmin. While pikmin can be considered fairly expendable, the player does feel a sense of disappointment for letting them die. While some players may actually feel a sense of loss due to actual attachment to their cute little creatures, others may just feel disappointed because they know it will require them to harvest more pikmin.

While the actual emotion felt is dependant on the player, the sense of loss exists for all players. This emotion could not exist without input from the player, as they were to blame for something going wrong in the story at all. Since units in Pikmin don't have much in the way of unique personalities, let's further explore this concept using Fire Emblem. While I've never actually played a game in the series, I know that once you lose one of your allies in the game, they don't come back. This is a harsher version of it, but it is still the same sense of loss being felt by the player.

Now notice how this specific emotion cannot be pulled from the user without input. This is an example of a feeling which is not possible to reproduce in any other medium. Yes, one could argue that they would feel loss by having a favorite character die in something like a movie or a book. While this is true, the scale of the feeling is incomparable. This is due to the fact that in games, the player feels direct responsibility, whereas in other mediums the player is following a set script.

This brings me to my main point, one of the fundamentals of what makes games different from other artistic mediums: the idea that games allow us to explore the ability of 'I did this' or 'We did this' instead of 'They did this'. When watching a movie, you can only see things get achieved by the characters on the screen. You have no personal sense of achievement, but you still enjoy seeing your favorite characters achieving their goals because you like them.

With games, we instead get this sense of 'I did this' or 'We did this', for solo and team based games respectively. Because we are given the ability to give input and affect the outcome as players, we also leave ourselves open to express a wider variety of feelings throughout our experience, such as the standard sense of achievement that most people feel when playing games. The examples I gave earlier of Pikmin and Fire Emblem showcase the inverse of this, a sense of 'I didn't do this', which in this case culminates in a sense of loss for the player. By playing around with how we use these mechanics, we are likely to uncover other ways in which to express emotion through the player, but that's all in due time.

So we've identified one attribute that makes game unique as an artistic medium, but that's definitely just scratching the surface. I think anyone reading this can agree that it will be years before people fully explore the intricacies behind the art of game design. That being said, we've got to start somewhere don't we? I want to see this medium grow as well as mature, so I think it's important that we begin to focus on the things that make us unique and different first, so we can expand on those ideas in the future.

5 years. That's how much time has passed since I last created a level in a full-length game. And honestly, I somehow managed to forget how much I flat-out enjoyed it. Doesn't everyone have that one activity which they enjoy doing more then they probably should? Mine just happens to be level design, a fact that I've struggled to remember over the last few years.

Actually, it may not be so much that I forgot about it, but more that a series of events drove me away from it over the last few years. Up until this point, I was honestly putting off the development of the first level in our game. I don't know why, except somehow I ended up with the idea in my mind that it was going to be incredibly tedious. Having put in a fair amount of time into the creation of the level now, I would consider it anything but.

So I started thinking back to my previous games to try and remember why I had such a low interest in level design recently. I clearly remembered it being my favorite part of creating my previous games, so when did I give it the chance to rub me the wrong way? The answer became pretty obvious when I realized the last time I worked on a major project, the infamous final 10% of my largest project ever. Play-testing, cleaning up levels, fixing bugs, adding scenery, minor tweaks and improvements; all things that I considered extremely tedious at the time despite being very important. That was it, completing my previous game had made me decide to take a break; but, it wasn't just that. I didn't get to do very much level design in that last 10% either. All I could remember when I finished, was all the grinding that I had to do at the end of the game, as opposed to the fun parts I got to do throughout.

But let's backtrack a little more first because I can't fully place the blame on that last 10%. I have a very bad habit of wanting all of the art and music for a level before actually developing it (let's say for inspiration purposes). Now when I was creating fan-games with Game Maker, this wasn't a huge issue. I just hit upVG Music to get the music, and Spriters Resource to get the art. Now that only got me so far, but thanks to the help of awesome strangers on the internet, I managed to put together my assets piece by piece. Matching tilesets and backgrounds were a bit harder to come by though, and I probably wasted hours upon hours looking for good artwork for my game. This increased my development time by ridiculous amounts and to put it simply, it was tedious.

This focus of developing levels with the proper graphics first slowed my development to a crawl, unfortunately I didn't notice that until pretty much just now. And the only reason I noticed was because I found myself making the exact same mistakes and doing the exact same things all over again this time around. Initially I was trying to make this game by myself, artwork and everything. It wasn't until Jason came on board and made me realize that what I was doing wasn't necessary or smart. It was time for me to ditch my ego and, instead of trying to do it all myself, leave the art to a professional. This is easily the smartest decision I could have made as it allows me to focus on the things I actually excel at, development and level design. The best part is, I can already notice it making an improvement.

I always considered game development something that I could do on my own, but realistically it shouldn't be. I'll be able to make a better quality game by learning to properly use my team's strengths instead. A one man show is really convenient at first, until you realize how much time you're wasting by doing it.

Shout-outs to aperson98 and NecroToad from DKC Atlas. The DK Bay wouldn't have been the same without your help :)

So for whatever reason I decided to use Unity for my 2D sidescroller. I'm at the point now where I don't at all regret this decision, but thats because I'm not really using Unity the way it's built for. I was given a development application which handled all of the basic engine fundamentals like frame updates, rendering and physics. The only problem was that I didn't care about having any of that stuff. I've built my own game and physics engines for years and I wanted to have the same control over what was happening as I always did.

So what did I do? I fought Unity as hard as I could. I realized early on that I wanted a level of control over the basics of the engine that I was using, which I may not have been able to get had I used the Unity defaults.

Unity is heavily used as a 3D engine because that's what it was built to be. Despite that there are a lot of people who use it to make 2D games. When I was initially looking into building a 2D game for it I had done a bunch of research looking for the most efficient/easy way to render sprite animations. The best thing which I found at that time was the 2DToolkit. I'm not going to go in depth with my opinions with this right now, since I don't even know whether I'll end up using it for the final game (We still haven't decided between 2D sprites or 3D models). I will say though, that while it is good, it is definitely not perfect. I've also heard more recently that there are more alternative solutions for 2D rendering in Unity nowadays, so if your looking for something, I'd say do some research first.

The most important piece of my engine, which I am very happy I did not use the Unity solution for, is the physics portion. It's designed to be heavily modifiable/tweakable, and since I've built it from scratch, there is no bloat (yet). I was able to focus on the things that I thought I needed for level design and remove the elements that I found useless. Granted, I probably could have modified the Unity physics to work the way I wanted to; but, I thought the time tradeoff for that would've have been greater then building it from scratch on my own. Below you can see a wireframed version of our game engine. The red lines represent platforms, the cyan lines represent the mask of collision objects:

The biggest thing that I can take away from all this, having already made the physics engine, is the fact that it is so simple to modify now. Whereas going through Unity documentation can get to be a timesink and a hassle, I don't have to do any of that for my own code. I'm the one who understands how it works and it takes me significantly less time to edit or expand because of that. Yesterday alone I added the ability to walk on slopes, something that I was avoiding because it made my past games more glitchy. Instead, it went very smoothly this time around and, while I can't call it glitch free at this point yet, I haven't found any glitches in it. So now I've already implemented most of the basic elements that I need for the game, which means that I can spend most of my time fully focused on the level design. Personally I think this will have a positive effect on the quality of my level design in the long run.

For anyone who has put some thought into developing their own game in the past, you've probably heard recommendations against building your own engine from scratch. Anyone who has actually gone the extra mile and did it anyways, can probably give you a few examples of why doing so was a terrible idea. While it does allow the developer some increased control on how to construct the engine, the development time trade-off is too significant to ignore.

I'm bringing this up because throughout university I attempted to make a game engine from scratch a few different times. Each attempt resulted in me becoming bored of the game I was trying to develop and ultimately giving up on it. I learned the hard way that trying to re-invent the wheel by making my own game engine is just draining. It doesn't matter how good the developer is, a game engine is a large product and it takes a lot of time to build.

The one roadblock which I always got caught on was the construction of the level editor. I learned to make games using Game Maker back when it only costed $30 to get the full version. I still remember when they moved to the YoYoGames domain, I didn't realize how popular it would become at that point. What I liked about that platform was that it had a fully integrated level editor that I could use to position tiles, enemies and other pieces of the level. Everytime I got to the point where I wanted to start developing levels using the engines that I built, I realized it is much harder to do without an editor. I never learned to do level design on paper and knew making my own editor would take a significant amount of time. Unfortunately, this usually resulted in me giving up on the engine altogether.

When I finally made the decision to start and finish my next game, I decided that I would make use of existing tools to simplify my own development. Around that time I had read a lot of articles talking about Unity3D. It sounded like exactly what I needed to streamline my development due to the support for many platforms and a built-in 3D level editor. In hindsight, I probably could have just used Game Maker again since I had already created an adjustable platforming engine, but I wanted to venture into new territory.

Since then, I actually haven't consistently thought that Unity is the perfect solution for me. While it did offer me a simple way to build for many platforms and create levels, it also gave me loads of other features that I didn't really want. I won't go into too much detail in this post, but I spent a fair amount of time fighting against the engine which I chose to use in order to simplify my work. That being said, I did eventually grow accustomed to it and I wouldn't switch to another engine at this point. I've learned how to build around the things that I dislike about Unity, ultimately making it what I would consider the best solution for me after all.

Let's be honest, no one ignores the test post. Unfortunately, there isn't much to show off about the game this early, or rather, there isn't much I want to show off about the game this early. So for now let's just talk about the type of game which we are trying to create.

To simplify it in terms of genre, it will be a high speed 2D action platformer with a heavy focus on integrated storytelling. I'm personally not a big fan of interrupting gameplay to present a storyline as it destroys the player's immersion, so I love it when a game can properly deliver a story without having the player watch a cutscene or read text for hours on end. Bastion achieved this with flying colors and based on the success and critical acclaim of The Stanley Parable, it has become obvious that consumers enjoy this method of storytelling in video games, even if there isn't much depth to the gameplay.

If you look at my previous games, you will notice that I have a lot of history making action platformers. I figured that there was no reason to switch to a genre which I don't have as much experience with. Instead I opted expand what is my favorite genre by experimenting with narrative instead. Expanding on our predecessors isn't exactly hard, when was the last time there was an actual story in a Mario or Rayman game? We as players always just accepted that action platformers generally don't need a storyline, or at least not a good one. This formula has been fine for a long time, but it's about time we broke out of that mold and explore what a 2d platformer could be.

Now let me just take a break here and clarify what I mean by an action platformer, because some people may not be able to discern the difference between types of 2D platformers. In one hand you have your puzzle platformers, think Braid and Fez. I find that there is an oversaturation of these in the indie game market due to the fact that they are low cost to develop, a trait which is also shared with action platformers. While I do enjoy these games, I know I'm not alone when I say I prefer a more uptempo gameplay most of the time, hence the popularity of the Call of Duty series. Which brings me to the other hand, action platformers (think Mario, DKC or Sonic). These games typically are less based on solving puzzles and more focused on using the game physics to complete levels. Unfortunately, there are not as many of these games being made in the indie world. We occasionally get games like Shovel Knight but it seems like a genre which is mostly being supported through games by major publishers like New Super Mario Bros, Donkey Kong Country and Rayman.

Based on the number of games in this genre being made, you could assume that they don't have very good sales, however its quite the opposite. All the action platformer games I just listed were critically acclaimed upon release and sold very well. Even just looking at the only indie game example I gave, Shovel Knight sold 180,000 copies in its first month available. So why aren't more of these games being made? Hell if I know, but what I do know is that I plan on making one.

If you want access to our blog posts immediately as their written, you can find them at our site.