Evan Polekoff: Development Blog

[epolekoff]

The trailer for my senior project, The EcoKids and the Paper Pests is complete! Check it out!

[epolekoff]

Why Pacman is the most well designed character in Smash

The title might be over exaggerating a bit, but I started focusing on Pacman competitively recently and noticed how intelligently designed each of his specials are. The key to each of them is how much “counter play” they all provide. By “counter play”, I mean that the moves are pretty fun to fight against while still being really fun to use as Pacman. I noticed a few returning characters had some of their moves swapped to add more counter play or risk-reward options, such as Dedede’s new Side B which can be swatted right back at him and Charizard’s Side B that deals damage to himself. However Pacman takes it to the next level, where every single one of his moves is designed around enjoyment for all players involved.

Up B

Pacman’s Up B creates a trampoline to bounce him into the air. Each bounce send him higher up to 3 bounces. If he hits the trampoline a 4th time, it will break and he will freefall to his death. The most interesting part about this is that enemies can jump on the trampoline as well! And of course this means they can also go into freefall on the fourth bounce.

If you think about it, the trampoline is actually more beneficial to the opponent than it is to Pacman. When Pacman bounces, it sends him into freefall after each bounce. The idea is that he will grab the ledge as soon as he is able to get punished for landing on stage. Other players do not suffer this same weakness and can continue their offstage game after using the trampoline. The only benefit Pacman has is that bouncing off of the trampoline causes damage to enemies that hit him while he’s traveling upwards.

The opens up so many interesting scenarios! If a Pacman is really far below the stage, far enough that he will only grab the ledge on the 3rd bounce, an enemy can easily drop down and fast-fall into the trampoline, stealing the last bounce and securing a free kill as Pacman falls to his death. It also means Pacman needs to be more careful about where he places is trampolines, since his opponents, especially heavier characters, can use them to recover better. Pacman can also delete his old trampoline and create a new one whenever he is able to use his Up B. This means if an opponent is planning on using his trampoline to recover, he can simply create a new one and watch as his confused opponent struggles to find a new plan for getting back to the stage.

Neutral B

Pacman’s Neutral B allows him to charge up a projectile and hold it for later. As the projectile charges, it changes form and cycles in the same order every time. The order is Cherry>Strawberry>Orange>Apple>Melon>Ship>Weight>Key. Each form has different properties when thrown, meaning each has a tactical advantage for when it should be used. The apple travels linearly downward when thrown and bounces if it hits the ground. The melon travels slowly in a straight line for a very long distance. The key travels very quickly in a straight line, making it clearly the best but harder to get as it’s the last in the sequence. All three of these forms can kill at high percentages,

The counter play comes in watching what projectile the Pacman currently has selected. An off-stage opponent will need to choose a recovery option based on what projectile is being used. For instance, if Pacman is holding the Apple, it will be easy to hit, gimp or stage-spike a low recovery option. Meanwhile, a Melon or key would easily hit a high recovery option. The form of the projectile can also be upgraded if Pacman is given enough space, bringing back the mind games of switching up how you approach him. When I play, I tend to hold onto the Apple, since it can be upgraded to the Melon if I see my opponent use their recovery above the ledge. The other projectiles have tactical advantages as well, like how the weight travels in an arc before dropping straight down and stunning the opponent, but for the sake of keeping this shorter I’ll move on.

The other, lesser form of counter play present in this move is based around the fact that Pacman can only have one projectile on the screen at a time. If someone picks up the projectile, they can hold onto it or throw it back. This move is very crucial to Pacman’s moveset and approach options, so it’s pretty important to be able to have one ready. When the opponent is holding it instead, Pacman isn’t able to approach as well and could even get hurt by his own attack. This makes tossing out easy-to-grab cherries a riskier move because the opponent can hold onto it and use specials to poke Pacman to high percentages.

Side B

Pacman’s Side B creates a trail of pellets in front of him, ending with a power pellet. The trail can be steered with the joystick as it’s being created. If Pacman is falling, the trail stays relative to him. When the trail finishes or the player causes it to end, Pacman will follow the trail and launch forward upon eating the power pellet. If Pacman hits a wall or the ground, he will tumble over, leaving him wide open. The attack also has ridiculous lag after it finishes, making it very easy to punish.

The counter play on this move is probably the weakest of the four, but it’s still interesting. When Pacman is creating the trail, the opponent can attack the power pellet (or I believe attacking any pellet will work) to break the trail. Even if Pacman is already following the trail, he will just go back to whatever he was doing before using the attack (falling or idling). The power pellet also drops to the ground and can be picked up to heal by any player. As i said, It’s simple, but an opponent can watch for the move, attack the power pellet at gain some health back. It makes for some interesting scenarios when fighting against a projectile user like Falco.

Down B

Saving the best for last, Pacman’s Down B is definitely the most interesting.

Pacman creates a fire hydrant below him and boosts himself into the air by a tiny bit. If he is already in the air, the hydrant will shoot straight downwards. After a few seconds of being on the ground, the hydrant will shoot water left and right, pushing all players and projectiles back. If a player is standing on top of the hydrant when it charges its water, it will shoot the water up instead. After 2 shots of water, the hydrant disappears. Pacman can only have 1 hydrant spawned at a time.

While there is a lot of strategy in dropping the hydrant over the edge to attempt to gimp recovering opponents (or dropping the hydrants onto a curved surface so they roll down the hill and hit unsuspecting players), the counter play comes from one more special property. When the hydrant takes enough damage, it can be launched by an attack, dealing a lot of damage and knockback to anyone it hits. The trajectory of the hydrant depends on the final hit, so it can even be aimed. This means that every time Pacman creates a hydrant to deal some damage, he is creating a huge risk of receiving even more damage right back.

What I’ve noticed is that opponents tend to run to the hydrant like its some sort of map objective to try to be the last one to hit it. The fact that the water pushes them away as they’re desperately trying to be the first to reach it is hilarious to watch every time. The hydrant can be dropped to block projectiles or cause damage and the water can be used to push people off the edge as they get back on stage. There are so many tactical ways to use the hydrant and it’s also really satisfying to hit the hydrant back at Pacman.

This might just be my favorite move in the game from a design perspective. It completely changes the strategy of the fight and causes players to change their attack patterns to better utilize the opportunity. A Jigglypuff might opt to charge a smash attack to hit the hydrant when they usually get all of their kills by wall-of-paining them off the stage. Moves like this one show how much depth a platforming-fighter like Smash Bros. has over the typical 2D fighting game.

If you have a character you think is better designed than Pacman, post a comment. I didn’t cover his standard attacks or aerials, which are also pretty cool, but maybe there’s another character that has him beat in that regard.

[epolekoff]

MassDiGI Game Challenge Follow-Up - Learn from your Peers

My senior project team performed really well at the MassDiGI Game Challenge this past weekend! We presented our game, The EcoKids and the Paper Pests, which I've mentioned in a few previous posts. We won our category of Serious/Indie/Alpha!

The competition was an amazing learning experience. We pitched to indie developers and other college students in part to practice presentation skills, but mostly to gauge how well an outsider could understand the educational message we are trying to teach with our game.

We found that some people were confused on some aspects of the game we thought were obvious. We were asked why the game was called "The EcoKids...", and simply by explaining that the player avatars are the "EcoKids" cleared up all confusion. We also received advise to emphasize the fact that possums aren't predators and indirectly affect the foodchain because that is a common misconception about invasive species. People think that herbivores are harmless and it's only bad to introduce predators, which is false. This is a fact that I thought was obvious, but by explicitly mentioning it adds extra educational value that I hadn't originally thought of.

After the competition, we had a constant stream of people telling us they were really excited about our game and couldn't wait to see it finished. We were told that educational games whose core mechanics are in themselves implicitly educational are hard to come by but especially powerful.

All in all, the competition was extremely inspirational and boosted my confidence in the project. The information and feedback I gathered from my peers will help shape the project as we move into more playtesting and finish up the game over the next few months. If you're a developer in MA, I HIGHLY recommend competing in the game challenge next year. And even if you're not on the east coast, get your game in front of your peers ASAP!

[epolekoff]

Here's the trailer that Studio REKS is showing during our pitch at the MassDiGi Game Challenge!

[epolekoff]

Here's a trailer I made to submit Race Condition to be in the WPI booth for PAX East.

If you want more information on Race Condition, check out some of my previous blog posts!

[epolekoff]

The EcoKids and the Paper Pests is the game I'm working on for my senior project. We're entering it in the MassDiGi Game Challenge in Boston in 2 weeks. I'll post more information later, but for now, enjoy our first development trailer!

[epolekoff]

Global Game Jam 2015

Link: http://globalgamejam.org/2015/games/backslash

The game I made for the Global Game Jam 2015 is a turn-based competitive multiplayer game called Backslash.

During your turn, you can choose one of 4 actions to attack your opponent or move to a better position on the board. After choosing an action, your opponent will have a short amount of time to react to your choice with one of 4 reactions, before getting to perform an action of their own. The game goes back and forth in a mix of strategy and quick reflexes until one player's health reaches 0.

For a game jam, this was the most complicated game system I've had to build. The there are so many complex rules for how actions and reactions play into each other (Wide Slashes can be blocked but not spot-dodged, etc), and everything had to be easy to change so we could iterate and balance the game. I was working with 1 other programmer, so it was totally feasible, but we still just finished in time.

I didn't work with any artists this time around either, so we used stock Chess pieces, cubes, and random slash sprites in place of action character animation. I tried to work around this limitation by changing the color of the affected tiles whenever a player uses an attack, which made it a little easier to identify the action. Full character models would obviously be preferred if possible.

My partner wants to port the game to Unreal Engine 4 and continue development, so that's the plan currently. If the game has more progress in the future, I'll post more updates. In the meantime, play the GGJ15 version on the GGJ site if you have 2 Xbox controllers and a friend. Let me know what you think!

[epolekoff]

Paper Pests at PAX East 2015!

Looks like my senior project, EcoKids and the Paper Pests, is also going to be at PAX East 2015 alongside Race Condition! If you're going to be at the show this year, come by the WPI booth and check it out!

[epolekoff]

Race Condition at PAX East 2015!

I just got confirmation that Race Condition will be playable at PAX East this year! I look forward to polishing it up to perfection for the show!

If you're going to be there, come check out the WPI booth and play my game!

[epolekoff]

Designing Games for Smart Watches

I am an avid believer that smart watches will be the next big technology. I have had a Samsung Gear 2 Neo for half a year now and it has become an integral part of my everyday life. The utility of the apps you can run on it is already enough of a selling point, but of course the game designer in me wants to use it for entertainment purposes as well.

I've been looking over the Gear Store at the Entertainment section to see what kinds of games people are trying to make. Right off the bat, a large portion of these games are flappy bird clones, 2048 clones or one of those boring ancient games you see everywhere (Simon, tic tac toe, etc). There are a few interesting games where it looks like the developers tried really hard to make something unique, but I always see the same issues that are common to designing a game on such limiting hardware.

In this post, I discuss a few of the common problems I see and what styles of games would be much better suited for the target platform of smart watches.

Common Problems

The obvious issue in playing games on a watch is that the screen is so small. This isn't much of an issue in looking at the graphics of the game, but there is a problem trying to select/interact with game objects by tapping on them. If something on the top of the screen needs to be tapped, The rest of the screen is inevitably going to be blocked. The same goes for 2-finger tapping, but even more extreme. To build on two-finger tapping, it is physically impossible to tap 2 things within a a quarter of the screen of each other because your fingers will collide with each other! Because of these limitations, tapping should be limited to selecting or 1-time actions (like flying up in flappy bird). Expecting someone to be able to tap an area of the screen repeatedly AND see what is happening is expecting too much.

Device Benefits

Each brand of smart watch will probably have different hardware capabilities, but the Gear 2 has the following: camera, IR baster, heart rate monitor, vibration, accelerometer, pedometer. That's a lot to work with!

An even better approach to designing these games is to look at the purpose of the device and think of what types of games are suited to a similar purpose. Here's a brief list of reasons a person would want a smart watch:

Check the time, date, weather at any given moment

Instantly see personalized notifications

Monitor life activity (steps, sleep cycles, heart rate)

Convenient access to functionality (using the IR beam as a remote control for TVs, controlling the air conditioner, etc).

Breaking each of these down, we can look at styles of games that can be built off of this functionality:

The first two bullet hints that a user wants to be able to check information at a glance about their current situation. This lends itself very well to games where mechanics are running in the background independent of player action. For instance, farmville, cookie clicker, and tomogatchi would be perfect. These types of games allow a player to quickly and conveniently check their progress without needing to constantly interact with the game, take out their phone or sit at their computer. They can remain hands-free while occasionally looking at the screen and tapping to advance the game.

Another note about the personalized notifications, one neat side effect I noticed about smart watches is that the vibration is completely unobtrusive. Typically when a friend of mine receives a text, the vibration of their phone can be heard by everyone in the room and the phone is usually placed on the table for easy access. With a watch, only the wearer knows when it vibrates. This could be integrated into the previously mentioned timer-based games, or even some kind of social game where the vibration pattern tells the player information without the need to look at the screen and without other players being able to hear it.

The third bullet is a style of game that a lot of people have been working on. One of the senior projects at my school was a fitness game that leveled up characters based on how they walked. Nintendo's 3DS uses playcoins that accumulate based off on the amount a player walks in real life. With the watch counting steps and with its ability to read the wearer's heartrate, smart watches are a great platform for these types of games.

One interesting way I've seen the watch used before is as a controller for other games. The Gear 2 can only be synced to a phone, but future iterations will definitely change. Since the watch has an accelerometer and the touch screen can be treated as a joystick or a button, the watch as a whole can be used to control a game on a different screen without being restricted to the real estate of the watch face.

I've only really named a few styles of games that are perfect for the platform, but I guarantee there are more I haven't thought of. As smart watches become more popular when the iWatch and better AndroidWear  watches released, novel game ideas targeted at the new hardware will be something to look out for, and I'm pretty excited.

If you can think of any cool game ideas that are best played on a watch and you feel like sharing, shoot me a message! I love hearing game ideas! Also, sorry for the lack of pictures! I couldn't really think of much to throw in here!

[epolekoff]

Game Jam: Doko Dog

Around Halloween time, I worked on a spooky game with ceschiii and another friend, Kyle. In Doko Dog, you play as a witch who must search for her lost dog in a dark, spooky forest filled with monsters.

The monsters are drawn to light, including to the glow emanating from the player. You can toggle the light off to hide, but you won’t be able to see where you are going. The witch can also cast a spell to fire an orb of light and draw the monsters away from you while also getting a view of what lies ahead. Only one orb can be cast at a time, so manage it carefully.

The game focuses a lot on sound as well. The dog can only be located by listening to its barking in stereo. The monsters can also be heard approaching, so keep your ears open.

I made a time lapse of the development during the game jam here.

You can play the game online here, or download it here.

[epolekoff]

Tron Font

Yes, Race Condition uses the Tron font. It was thrown in because it looked "tech-y" if you will. From the beginning of the project, I knew I was going to need a new font eventually, but I had to rush out most of the features for the MassDiGi Game Challenge, a prototype competition I entered. The font was minimum priority at that point.

Since then, I've shown the game at 1 convention and Showfest, a big end of year demo event at WPI. I lost count of how many people came up to me and said:

"Nice Tron font."

"Is that the Tron font?"

"Look at that Tron-ass font!"

The main logo for the game uses an edited version of the Tron font, with a few edits and a few circuit designs springing off of it. This is irrelevant, everyone still calls it the Tron font.

The lesson this time is very simple:

DO NOT USE THE TRON FONT! EVER!

DO NOT USE ANY RECOGNIZABLE FONT!

My plan currently is to find a futuristic looking for that is kind of standard and draw circuit designs over it to make it more unique. If anyone else has a better method of font creation, let me know!

Bonus Topic: Trail Renderers

I was going to make a separate blog post about this, but I decided it's not worth it and I'll just tack it on here.

DO NOT USE THE DEFAULT UNITY TRAIL RENDERER!

Everyone will notice and your competitors will not hesitate to point it out. It looks lazy, sloppy, bland and just generally detracts from your game's aesthetic. In fact, don't use default anything in Unity unless you are in a game jam strapped for time.

Seriously, put the extra effort in to make it look unique. Dragging and dropping a Unity asset and saying "oh, it works, it looks kinda cool" is the worst thing you can do.

[epolekoff]

When Atmosphere Gets in the Way

As I discussed in my Tangential Learning post, I take every opportunity I can to make tie-ins to computer science and tech in Race Condition. However, there are a few occasions where this priority has gotten in the way of player understanding and negatively influenced their gameplay experience. How far should we go as game designers to immerse the player?

The specific case I would like to highlight here is my use of binary as the countdown clock before a race starts. In typical racing game fashion, a clock will count down before the players are allowed to move, typically 3...2...1...GO! In my case, I simply swapped this out for the binary equivalent of 11...10....01...00! I thought it was charming and a bit of an inside joke for people who could count binary, but all i got at conventions was "Why is this clock counting down from eleve- OH! WHAT!?"

There are probably ways around this. I could make the number 00000011, 00000010, 00000001, etc. This hints to players they are not looking at decimal numbers. Another option would be to start the counter at 11111111 and decrease at a much faster rate so players can see the number decreasing, but this loses the understandability of the 3 second countdown. Part of the problem is that "11" looks like the number eleven and normal people with in base-10, not binary. Perhaps the solution could be as simple as flashing some 1s and 0s to say "hey look, this is binary" before starting the countdown. Then the player would at least be put into that mindset. There are so many ways of counting down without using binary (colors, sounds, decimal numbers, etc), but they all circumvent the issue entirely and remove this extra layer of atmosphere.

I used binary in another part of the game as well, on the lap counter depicted above. I think this use is perfectly acceptable due to the fact that the number is counting up and players should be able to remember how many laps they have already raced. There top of the screen also displays a counter of the number of laps each player has won, giving a second indication. The countdown clock is much more front and center, making it much more of a problem.

On the CPU Difficulty Select screen, I worked around this by measuring the GHz of the processor, the computer equivalent of the CC of a kart in Mario Kart ;) Since the processor is part of the hardware, the values are 1, 3 and 5 GHz, values that people will see when building/buying computers or reading about super computers online.

My takeaway from this is that gameplay is always more important than atmosphere. If a player doesn't understand the inside joke or tangential learning aspect to the point where it negatively affects the gameplay, it NEEDS to be fixed or removed! If I can't think of a successful way to replace this countdown clock, I will be forced to remove it, even though I think it adds a really nice touch.

What do you guys think? Is binary a well-known topic? I go to an engineering school so everyone I know is a little biased. If you have any neat ideas for how to fix the countdown, I'd love to hear them!

[epolekoff]

Designing an Immersive Menu

Video game menus are often overlooked when developing games. A "good enough" way of implementing them is usually obvious and developers can fall back on the tried and true menu systems that work for their game. Mobile games have large buttons you can tap on, most PC games have lines of text you can scroll to select an option. However, i have a huge appreciation for games that go above and beyond to make their menus unique. I even attempted implementing a more unique and immersive menu system in Race Condition as well, to mixed success.

Good: Get the Player in the Mood

The immediate benefit is that the menu does a good job of getting the player in the mood for the game on a deeper level right from the title screen. Of course the music and graphical style play a huge part in this, but that doesn't mean menu mechanics can't increase this immersion.

In Race Condition, the menus are all giant wheels that rotate when the player presses left/right. This is to simulate the player control in game, where pressing left/right rotates the player around the inside of the tube. Even before seeing gameplay, the players are introduced to the concept of rotating the track.

The menu item on the bottom of the circle is the one that is currently selected. It glows blue, grows in size and it's the only word in the circle that is rotated so that it is completely readable. I personally don't even think this is enough and I've been wanting to put an instance of the player model above this selected option to draw the player's eyes down to that option. It would also better represent the player action of rotating the track by actually showing the player rotating the track!

In the background, I have a camera running along the center of an empty track, with the same perlin noise light animation and glow effects that the players will see in-game. Mostly this is for flashiness, but it also gives player insight into what the game will look like. When the track opens up for the first time at the start of a race, the players already know what the track looks like and they already know what to expect. When demoing a game at conventions with people of all demographics who have no idea how to interpret your abstract game, every opportunity to make it easier on the player should be taken!

Good: Looks Impressive

Everyone's seen the dropdown menus before. Everyone knows what to expect. However, when they see this wheel of text and press left/right for the first time and see the wheel turn, it already blows some players' minds. It's unique, it stands out and it just looks cool!

Another benefit of having the text arranged in a circle is that the center is completely open. That's most of the screen that can now be used to show off the flashiness of the track behind it. The flip-side of this is that it makes the menu options on the top of the wheel unnecessarily hard to read. However, there are some games that don't even show all of the menu options unless they are scrolled through. At least they can see how many options there are!

Bad: Breaks Standardized Controls

I mentioned before that developers tend to fall back on the tried and true menu conventions that work for their type of game. This method has a huge benefit in that players already know exactly what they are looking at.

Most menus let players cycle options by pressing up/down. In Race Condition, players need to press left/right, which means I'm already off to a bad start. Most menus also have the selected option on the top or allow the cursor to scroll down the menu. My menu has the selected option on the bottom, meaning most players will default to looking in the wrong place.

However, once players get over this hurdle of figuring out the menu, I think the benefits outweigh this initial confusion. At conventions when I demoed the game, I selected the options on the menu for them or set up the menus so players could just hit A all the way through to avoid this problem. When players get the game in their own hands, I think it is a small price to pay.

Bad: Menu Inconsistency

The wackier and more demanding the menu, the more inconsistent it will inevitably get. By inconsistent, I mean that 1 crazy menu scheme can't possibly cover every scenario. For instance, the player select screen in Race Condition:

Since there are 2 players, there needs to be 2 wheels for selecting colors. If both players selected their color from the bottom of the wheel, it would be harder to display which while belongs to which player. I wanted those bars (gray in this picture but they will eventually be the same color as the player) to flow from the wheel directly to the corresponding player.

Other menus like my "Number of Players" menu are also flawed. The number of options is so small and spread out, the real estate of the wheel is under-utilized. I could make the wheel not cycle all the way around and move the numbers closer together, but that's inconsistent and it no longer represents the game play 1:1. I'm afraid the Options menu (that I have not yet implemented) will follow the reverse of this, where the number of screen resolutions will exceed what I can fit on the wheel. Same with the number of tracks as I add more and more. Eventually, the consistency will have to be broken.

I encourage everyone to push the boundaries of what they can do with their menus! And if you find any that are particularly interesting, send them my way! Also, let me know what you think of Race Conditions menu and if you had any trouble figuring it out!

[epolekoff]

Designing Chance-less Racing Game

One of the complaints Mario Kart gets a lot is that the game requires no skill because the items are too random. Extra Creditz did a video recently on how randomness in competitive games does not remove all measure of skill as long as a tournament has enough matches to equal out the random chance over time. The Game Development Club at WPI recently had a Mario Kart 8 tournament where a student ranked 3rd in the world on one of the time trials took first every time, clearly because he was more skilled.

However, when I was designing Race Condition. I wanted the game to be entirely based on skill with 0 chance involved. I wanted it to be entirely focused on the mind games between players and I wanted the more skilled player to always come out victorious.

Removing randomness introduced a bunch of other challenges, though. These are the ones I discovered and how I addressed them:

Fun for All

The random items in Mario Kart are clearly a mechanic meant to add hilarity and chaos to the game for racers in every place. The players in the back get the better items to allow them more chances of reaching the satisfaction of passing other players. Removing items altogether removes a huge portion of the fun, especially for the players that are losing.

An interesting effect of the design of the wall-toggle ability in Race Condition is that it's independent of position. Screen looking is a core mechanic and walls are all over the track. A player who never even left the starting line (if that were even possible on an on-rails game) could still block the other player with walls half-way through the track.

When playtesting Race Condition at Made in MA and WPI's Showfest, I noticed a common trend in the enjoyment of the game. People would always laugh (or at least smile) once they experienced the satisfaction/frustration of blocking/being blocked by another player. If the two players were buddies, they would already start smack talking each other in a friendly, competitive way. At this point in development, I didn't have the markers in the center of the screen that said who was in the lead and a common complaint I received was that players had no idea who was winning. Each race was also only 1 lap, so the game seemed as though it ended spontaneously for no reason. Part of the players' enjoyment might have come from the ignorance that they were hopelessly behind. More playtesting is definitely needed, but this concept of global track manipulation definitely helps.

In a previous blog post I talked a lot about metrics gathering and assessing a player's skill with extremely precise data. I talked about potentially ranking players based on factors other than simply saying what place they finished. Touching on this topic again briefly, there is a lot of potential to provide a rewarding experience for players than lose or don't have any chance of coming back. There's still an incentive to get a higher ranking in certain skills and by messing up the other player's ranking, etc.

Opportunity to Come Back

That leads into the next big flaw of this design, which is that the losing players don't have many ways of coming back. Currently, the only way to slow down another player is to block them with a wall or force them to the outside of the curve (also using walls). If the player is skilled enough (as they often are, considering they are currently winning), they should theoretically be able to dodge the walls and stay inside the curves.

The first change I made to compensate this is to reset both players to the starting line at the end of each lap. Both players get a clean slate and the losing player is given a second chance to come back. This also addresses another problem: superior knowledge of the track. If one player has more experience with a specific track, they will have an edge over the opponent, giving them a much larger advantage on the first lap. The advantage would propagate into other laps if the players were not reset. This also makes the procedurally generated maps more interesting since the first lap can be seen as a "learning" lap and the next few are the "memorization" laps. Players more skilled at the core game might win the first lap, but by resetting both players to the starting line, the game puts a larger emphasis on learning the track layout and using this knowledge to one's advantage.

I've been wanting to add new mechanics to the game to directly help players that are behind. I've also been wanting to add something that allows players to directly interact with each other. One situation I noticed is when both players are on a straightaway next to each other and neither player can do anything to the other. This break in gameplay could easily be filled with something more exciting. One idea I've been tossing around is a projectile that both players fire when one of them charges it up. This allows the player who is behind to aim more easily in front of them and forces the player in front to screen look in hopes of avoiding it. The charge time would give the leading player enough time to see it coming and could even lead to more mindgames where the losing player isn't even close but wants to psych his opponent out. I haven't decided if the players should be able to deflect the projectile or control it in the air, if the player in front fires their bullet backwards or forwards and what happens if the bullet hits the wall. More testing would be required.

Multiple Kinds of Skill

Even though Race Condition focuses on skill, there are multiple different kinds of skills and they can't all be included. Skills in puzzle games barely apply here. This is obvious information, but it's still important to focus on what skills your game exercises to help balance it. Race Condition exercises the following skills:

Twitch-gameplay, Super Hexagon style: Players need to react to wall-switching and still maintain focus on what's in front of them.

Multitasking: Screen-cheating is important. Not everyone can steer and toggle walls at the same time. Players need to keep a snapshot of the next few seconds of the track in their mind while they shift focus onto their opponents screen.

Prediction: Players need to learn their opponent's playstyle to counter their actions. If they always take the same path and toggle the walls off instead of avoiding them, a player can easily pop the wall back up and gain a huge advantage. Players should also be aware of their own strategies so they don't become too predictable.

For twitch gameplay, the inherent speed of the game makes everything reaction-based. I typically don't have to worry about it much.

For the multitasking, I actually ended up removing the mechanic of toggling off boost pads because it was too much for new players to understand and it barely offered any new gameplay. I've found that keeping track of walls, speed, and staying inside the curves is already challenging as is, so future mechanics should aim for moments that relieve some of this stress (locking the ability to toggle walls with a mutex) or aim for moments where there are slower moments (the projectiles I just mentioned that are really only fired when players are near each other on straightaways).

For prediction, it's just a matter of making sure players have enough options to avoid being screwed over. Both players can toggle walls, or even avoid the walls if they want. With the projectile, the charge up time gives an indicator of what's coming, but still has enough variability in how it's used so that the player needs to predict what the opponent is trying to do.

That's all I have time for today. There's always a lot of thought that goes into game design decisions and I just wanted to shed light on my process.

As always, let me know what you think! I need feedback! Game mechanic suggestions, complaints about how boring Race Condition is, anything at all! Send it my way!

[epolekoff]

Designing a Tangential Learning Game

The original idea for Race Condition came when I was doing research on race condition exploitation in WoW (funny how I was researching exploits for a game I later went on to make a tool to help debug). I had been wanting to make a racing game for a while, but I wanted to make something completely unique that had never been done before. With the name Race Condition, I figured I could make it computer science themed, which ended up going somewhere.

The game

In case you don't know what I'm talking about, you can play the game here and read more information about the game in my previous blog posts.

What is a race condition?

Before jumping into the thought process behind the game, I should probably define what a race condition is for those of you who are not software engineers. When a program is running, it is usually running in a single process on the computer. One run through the code of a program must happen in sequence before looping back to the beginning. However, a process is allowed to have multiple threads to allow certain parts of the program to run in parallel. The threads have access to the same pool of shared memory, meaning they edit the same variables and they can see those changes. If programmers aren't careful, code can be written such that the threads will be changing the same variables at the same time. If one thread sets the value of a variable that it relies on for some other part of its code, but then that variable is changed before it can be used, that is a race condition. The other thread "won the race" to that variable.

Symbolism in the game

The track represents the computer process. Each player represents a thread.Fun fact, the trail behind the player was supposed to be a rope with rope physics to simulate the appearance of an actual "thread", but I couldn't get it to look good in practice.

Every action the player makes in the game affects that track globally. This is the same as accessing that shared pool of memory that the threads rely on. In fact, the "race condition" moments, the moments where a thread is expecting a variable to stay set  as the value it was originally set to, are when a wall is popped up in front of an enemy player. The player that hits the wall was relying on the fact that the wall would stay down, but another thread changed the value and screwed him up.

When a lap finishes, both players are reset to the starting line for the next lap. This was implemented for gameplay purposes, I will admit, but it also makes more sense in context than letting the winning player continue on. When programming multi-threaded applications, the threads are usually joined back together before looping back to the beginning for the next code cycle. With the complex way the operating system handles threads, it is impossible for the two threads to finish at the same time and often times the  order of which thread finishes first is inconsistent. This reset symbolizes that join and starts on the next code cycle.

Missed opportunities

One key way of preventing race conditions is to use mutexes. They act as a lock on the shared memory so that one thread will have to wait until it is their turn before they are allowed to access it. Obviously there is a lot more depth (like how the waiting thread might have read-only access to the variables), but it has a lot of potential for abstraction in the game. Perhaps the first player to cross a certain line (grabbing the key to the lock, essentially) is the only one allowed to toggle walls in that marked off region. Lots of potential.

So what do you think? Did you notice the similarities when you first heard of the game mechanics? Now that you know what a race condition is, does the game make sense? Do you appreciate the game any more? Does the complexity of the game inspire you to dig deeper into the topic?

My favorite thing about tangential learning in games is how it unconsciously motivates people to learn more about topics they might not have had an interest in before. For instance, when a professor mentions race conditions in my computer science classes, I have a bunch of people who look over at me with a smirk. Just the existence of my game has caused them to perk up and unconsciously pay more attention to the subject matter in class even though it likely has nothing to do with my game. Tangential learning is so incredibly powerful, I hope everyone reading this can find a way to work it into their own games!

[epolekoff]

Designing an On-Rails Racing Game

I wanted to make a post about the elegance of designing my game Race Condition around the concept of an on-rails racing game.

Right from the get go, the concept doesn't sound like it would mesh well at all. On-rails games have little to no steering involved while racing games are entirely about staying on the track. However, the combination of the two  actually works extremely well for a number of reasons:

Freeing up Player Action:

In a typical racing game, steering and staying on the track is the majority of what the player is doing, if not the entirety. Games like Mario Kart give players items to slow other players down or knock them off the track, but that's pretty much it. Because staying on the track is put in the spotlight, the games need to limit the number of actions that the player can do so as not to overwhelm them.

By removing the need to stay on the track, Race Condition frees up the players' minds to focus more on the other actions the game provides. The core concept of Race Condition is that every player action affects all players and the track globally. This means the player needs to be aware of the opponent's position as well as their own. Screen looking has been made into a core mechanic and in certain sections of the track a player will be looking at their opponent's screen more than their own. The tracks are designed to have sections with minimal/no walls so that the player can take the time to check up on their opponent.

There is still some degree of steering, but it has been abstracted to a very basic sense by letting the players rotate around the inside of the tube. The players still need to avoid walls, but it's not nearly as big a deal since the player can toggle the wall off or even wait for the opponent to lower the wall. Positional awareness on the track is also still a factor since taking the inside of a turn is always faster than going around the outside. However, since players are always moving forward and don't have to steer, a player can line himself up with where he wants to go and then shift his focus to the opponent without constantly maneuvering his own character.

The current version of Race Condition only has the ability to toggle walls, toggle between 2 speeds for the players and toggle boost pads on/off (although this feature is in the process of being removed for reasons I will explain in another post). However, I am always thinking of new, crazy, abstract actions I can give the players because the option is there! Players have so much more freedom!

Precise Data/Metrics:

When racing on a track, there is a lot of variability in where players can drive while still progressing forward. In Mario Kart, a player can drive over grass through a short cut, which would take longer than going on the actual road, or boost over the grass, cutting the time dramatically. As a result, it's difficult for the game to know if an action that the player took was optimal. This type of gameplay lends itself well to time trials, where players can practice the same tracks over and over to learn and memorize the optimal path to the finish. Then there's always the chance someone will come along and learn a better path.

Race Condition does not have that complexity in its tracks. It was not designed to be played with time trials, and without a new mechanic to change things up, it probably wouldn't be very interesting. What the on-rails aspect of Race Condition does provide is a concrete metric for how far along the track a player is. In fact, since the track is built using an array of points, the game is able to calculate the EXACT percentage of the track that a player has completed by looking at the distances between each point. This percentage is displayed in game to give players an exact measure of how much they are winning by. However, this algorithm can be taken a step further to provide even more data on a player's race. While Mario Kart only has the time at which a player completes each lap and is only able to collect this information after a lap has been completed, Race Condition always has this assessment of how far ahead a player is at all points of the race. It also has a concrete measure of how large a comeback is, how successful a wall toggle was, etc. Since players move at the same rate along a fixed path (ignoring walls and speed boosts), the game knows exactly how long each race should take and can compare this predicted time with the actual time of the players, even potentially ranking them based on their performance (similar to how the Naruto fighting games rank players, but with more precision and more exact variables). The potential to implement complex data analysis algorithms is enormous and I'm excited to play around with the data and see what I can do with it.

More Interesting Procedural Tracks:

Procedural tracks are nothing new in racing games. If a racing game lets players build their own tracks, then a procedural one can be generated fairly easily. However, tracks in Mario Kart are unique and interesting all the way through because of the unique and well designed locale. For instance, Shy Guy Falls in Mario Kart 8 is designed around a waterfall and the flowing water plays a huge role. Also, this style of racing game relies on the variability I mentioned earlier, with carefully placed shortcuts. Everything needs to be designed carefully.

In Race Condition, the interesting parts of the track are the way the tube bends and the arrangement of the walls. With the current mechanics, that's it. Since the tube and walls are created and rendered at runtime, it is very easy to procedurally generate them. The tracks aren't as focused on shortcuts or variability in the structure of the track since they are all tubes. Part of the fun becomes memorizing the wall layouts to better block the opponent on subsequent laps of a brand new track.

As you can see, the racing genre doesn't need to be confined to the Mario Kart clones that everyone seems to be making. There are interesting design discoveries that can be made by combining the sense of speed of the racing genre with other unique playstyles. If you haven't given it a shot, you should try out Race Condition here and tell me what you think! And if you have any other ideas for mechanics that you think might work in this abstract racing game concept, let me know! I'd love to hear them!