This is just an updated version of the Land Navigation project that I did in UDK. The goal here was to get the old project into the new engine. I used this to learn more about the Unreal 4 engine while at the same time improving on the old game. I did a lot of very cool things for the UDK version but UE4 works completely differently. One of the best improvements is how much easier it is to get a HUD into the game. So I did some research and fiddling around and came up with a lot of stuff that made the game a lot better. Below is a picture of the entire UE4 HUD blueprint. (well most of it)
One of the quality of life improvements that I made was to improve the practice mode. In the UDK version I made it so that if the player was lost they could hit a button and teleport back to the last correct marker. This worked but did not serve any purpose in teaching the player anything about land navigation, which was the goal of the game. So through the magic of the HUD blueprint I set up a system where, if the player chose, they could turn on a “help” feature. This would place a HUD element over the last correct marker reached that would give them the azimuth they needed to plot to get to it and the distance away they were from the marker. Below is the part of my HUD blueprint that makes this work. The best part of this is that if the player is not able to see the marker inside their field of view then the element HUD is not drawn.
Below is an example of it working in game. The text will adjust its position vertically based on the player’s distance from the marker. So the further away the player is the more centered on the screen the text becomes.
Something else that I had to do in UDK was make a AS3 swf then import it in order to have menus or buttons. You know, some very simple things. UE4 lets me make my own buttons. Now I had to program some of that. Below is the custom function I made to draw a button and let it act like a button. That means stuff like changing when hovered over and clicked on.
Below is what I did after the button was created to make it act like a button. This is really just swapping out textures based on certain events.
Below is all of the stuff that happens when you press a button. There are a lot of conditions that need to be checked to make sure that the correct action happens when you press a button. For instance what screen is shown when you hit the next button.
The other major change I made was getting rid of the map. Now in real life navigation, a map is one of the most helpful tools. But I found after watching people play the UDK game, that players never used the map so I got rid of it in the UE4 version. I replaced it with a sheet that gives you the information you need to play the game. Below is the part of the HUD blueprint that pauses the game and pulls it up.
Below are screenshot examples of what the menu screen looks like. The first one is for a practice session. That means that the player is given all the info that the player needs to navigate a whole course.
Below is the test menu page, you may notice that it is considerably more empty. The test is to see how well you can actually navigate. You are not given distances, marker names, and the help button does not work. The test is so hard it hurts me when I have to test it.
I still had to get the compass to work, and it was mostly the same as it was in UDK. Below is the entire code that runs the game on the Level Bleuprint. In UE4 most of the programming is moved to classes as opposed to all being in this one blueprint. That took me some time to really get the hang of, but it is a much better system.
The only thing I needed that was not in UE4 was have something ignore the rotation of the object it was attached to. This is so that the compass bezel would not rotate with the player. In UDK there is an option in the attachment features, but alas, that is not so in UE4. So below is the blueprint part that does that. Also included is the part that makes the needle point north.
Here it is working in game. (hard to see in a still picture)
So most of the game was moved to the marker class. A class is just an in game object with code attached to it. So I put all of the code on the marker. The best part of this is that when you drag a new marker into the level, it has all the code necessary to work with the game. Below is all of the code that runs the markers. It is mainly a lot of checks for when the player crosses into a trigger around the marker. Then it tells the marker what to do if it is the right or wrong marker.
It also sends info to the HUD for the help feature. Below is what does that.
Below is the marker talking to the HUD to let you know you reached the correct marker.
One of the really cool things you can do with the classes is make variables external, or seen by the editor. This means that all a level designer would have to do is drag a marker into the level, say what its name is, what path or paths it is on, and then what order it is. Super easy and you have a working path. Below is what the level designer uses in the editor.
One last thing that I did was to make the footstep sounds. I started with the player pawn, which is a collision volume and a camera. Because that has no animation notifications to make footsteps easy I had to tell it when to make the sounds. Then I had it trace to the ground to see what the player was “stepping” on and play a sound that would match the material. Below is what that looks like.
All said and done this came out (design wise) way better than the last one. UE4 gives me a lot of new tricks and tools that make this better. I cannot wait to see what else I can do in the engine. if you want to try your hand at compass navigation you can download it here. Good Luck
Land Navigation is a project I was asked to join by Luis Cataldi, the chair of our department at SCAD. He volunteers with CEMA (Chatam Emergency Management Agency) and helps them with Search and Rescue. He thought that it would be a good idea to have a 3D training program for CEMA to use before they put people in a forest for their navigation test. The core of the game would be navigating through a photo real environment with a compass. Since I have a degree in geography I was oddly qualified this project was. He wanted to do it in UDK and have a crack team of artists make it look great.
When I began designing it I had to keep reminding myself that it was a serious training simulator, not a game. So where normally I am looking at making sure that the moment to moment gameplay is engaging and keeps the player in the flow zone, this time I was more concerned with teaching the player a real life skill. I am used to designing around the player learning the game mechanics, but not something that correlates to the real world. I was really excited about it. I have done a lot with gamification and would love to make a curriculum based game some day, but this is a great first step.
When I started designing the game I completely missed the point of a training simulator. It took me going out and actually navigating through a forest to finally get it right. The best example of this is that of pace counting. Originally I was going to do this for the player, so that they would just have a counter that told them the number of paces. I figured that this would be something that is easy to do and thus the player should not be bothered. That is how I would approach this if it were a game. Nature taught me differently. Counting your paces is the second hardest thing that you have to do. Add that in with having to navigate correctly and it can be very challenging. So I made the player have to keep track of their own paces. I added a pacebead mechanic so that they could keep track of it visually, but they still have to count it themselves.
So the main programming challenge of this game was the compass and distance. The compass had to point north and the distances between places had to be measured in a unit that actually existed. I also had to get rotation information into something that could be used by a person to navigate. So UDK measures distance strangely because it has no set unit. a single Unreal Unit has no real life correspondent. That is to say that 1 UU is not 1 inch or something. UU’s can scale. So I had to find a reference for distance in the game and base all distance on that. The player height is 96 UU and buried deep in the documentation I found that it is supposed to be roughly 6 feet tall. Some quick math reveals that at that scale 1 UU = 2 centimeters so I did this to give me distance from one object to another in meters.
Once I got that I was able to figure out all sorts of stuff that I needed to know. So the average human pace = 0.8 meters. But what is our player character’s? Well at the base groundspeed of 600 it was almost 3 meters to a pace. That was a little long for the game becuase the player would cover too much ground too quickly and negate some of the challenge of land navigation. I also wanted it to be closer to the average human pace. That was the wrong idea. Setting the groundspeed to about 150 got us close but holy cow did it take a long time to get anywhere. It felt so very slow. So I got the ground speed to 220 and the pace to 1.72 and it was right where I wanted it, a perfect balance between speed and realism.
After that I needed a compass to work. So I did a lot of refreshing on how north works. Its not as simple as you think it is. There is true north, magnetic north, map north, and you have to take into account declination. I was trying really hard to find a way to get all that stuff in….. but why? This is a training simulator not real life. All I had to do was teach them the basics, not how to be Liam Neeson in any movie he is in. So I cheated, I made a cube moved it way off into the distance and said that it was north. I set up a simple matinee that made a needle point at it and bam a compass was born. After that I had to get navigation directions. That is a direction you must go based on a 360 degree heading to reach your next location. Well UDK does not measure rotation in 360 degrees but in 3500 rotation units. So more math ensued and I found that If I got the rotation vector and divided it by 182.044 It would give me a 0 – 360 number that actually coincided with the compass direction with one hitch. it was 0 – 180 on one side and 0 to -180 on the other side like this:
Which meant that to get actual azimuths for the player to use I had to do some in kismet math, fun fun. It ended up looking like this:
It was actually a lot of fun when I got it working. But figuring out how UDK does rotation made my head hurt a bit.
I learned a lot for this project besides land navigation. I wrote my own custom game mode, pawn, sound controller, and two kismet nodes. Having never done any of that before it was easier than I expected. The game type, sound controller, and pawn were pretty easy as they just extend stuff already written. It just allowed me to make changes to things like ground speed and camera bob with out hurting the game for other people. It also allowed me to do some cool stuff for the pace counting.
So originally I wanted the player to count paces by listening for every second footstep. This worked great unless you lacked headphones, speakers, or were deaf. So I needed a visual cue for the paces as well. I combed through the pawn script and found where it called out to the footstep sound cue. I tried a lot of things here to make sure that it would output to a log or something for testing and could never get it to work. This is where my first custom kismet node came in. I wrote it to listen for a specific function call then output a kismet signal, super simple and it worked.
The other kismet node is more complicated but I will get to it in a second. The other major thing I learned for this project was making flash menus and UI elements for UDK. Importing them was not hard, getting them to output a signal in kismet was not that hard. After I got it all figured out and realized that I could do some UI as well, it opened up an idea for a visual pace mechanic. Attaching flash videos to the screen looked so much better than trying to attach them to the player camera so I decided to do that for the pace mechanic. I was told that since it was a SCAD project we needed a SCAD logo in the corner of the game. I decided to make that logo flash orange on every pace count. This meant that I needed to send a signal to the flash video every second footstep. Well there is an invoke node in kismet but it does not function with AS3, the language I was using. So I looked into it online and opened up the AS2 invoke node script and modified it so that it would call out to an AS3 swf. It took a bit to get right but it works great. Getting that guy working was very cool for me, It opened up so many doors for future projects, I can do custom UI all day now. If you would like to see it you can view it here.
In fact here is a zip of all the files
After that I asked the CEMA guys what they wanted to get out of this training. Gary, our consultant, told me that there are two parts to CEMA training their volunteers. The first is where they take the people into the woods and teach them the basics for a few hours. This is to build confidence and comfort with the process. Then comes the test where they purposely make it hard. So I set up multiple courses with that in mind there are 2 practice and 2 test courses (for now) and I can add as many as I want. The practice courses are built to be easy and teach you the basics. The test courses, like theirs, are hard and meant to push you to your navigation limits. The kismet built to do this was a little tricky but works to pick a random path of either practice or test depending on what you pick.
The main difference is that practice will allow you to teleport back to the last correct marker if you are lost, and it tells the player when they get to the right marker. Test just says good luck.
If you would like to learn how to use a compass download the game here.
The paths are described below:
Normally the test path would just give you the letter of the first marker, and the direction you had to travel. You would have to give me the distance you traveled based on your pace and I would grade your accuracy.
This project would never have been possible without the others that worked on it.
Luis Cataldi – Project Lead
Rebecca Blessing – 3D Artist (Train Area)
Tanner Lambeseder – 3D Artist (Tech Artist and Trees)
Meghan Connor – 3D Artist (Docks Area)
Allyson Smyth – 3D Artist (Trailer Park)
Kaela Smith – 3D Artist (Road Area)
Nina Park – Producer
Preston Goodson – Sound Designer
Inspired from old school arcade games and the IP of Cyril Guichard. I took inspiration of scoring from a game called Super Stardust HD on the PS3. It is a simple system the rewards the player for playing well, but is not too harsh if they mess up. Focused on high scores and fun. I carried this over into the game play. I was asked to design this for mobile browsers, so I tried to keep it simple enough to do that. The game is designed to last not much longer than 6 Minutes.
I programmed some AI into the game. I wanted the humans (things you are not supposed to kill) to defend themselves. So they have basic target priorities. This was harder than it sounds but the finished product was worth it. The aliens also have AI. I have 4 of them and did not want them to all act the same. 2 Hunt the humans and if they cannot “see” any humans they hunt the player. 1 ignores the humans and only goes for the player, and 1 does the exact opposite. So I make the humans target the aliens going after them first and after the player last. Its a little mini war, which is awesome.
The sound effects really serve to bring the game alive. My sound guy Tommy Sarioglou did some great work. I wanted some of the sounds to help telegraph stuff to the player. The shield sound and the RPG sounds are great examples of this. The RPG has a kathunk sound followed by the explosion, which helps the player understand the delay.
The best thing i did was add a High Score screen. It made the game. Games like this need a goal. Since the player cannot last more than 7 minutes they need something to work towards. The High Score works towards that. I had people competing right away and it was awesome. Short mobile games like this thrive on repeat play and this is the best way to do it for this game
Spaceholes or “Space Assholes” was the game my team and I did for Global Game Jam 2014. So the theme “We don’t see things as they are, we see them as we are” was a little annoying this year. Do not get me wrong, themes in general are great. I think that designing within constraints is way more fun than blue sky design. It allows you to focus on user experience and moment to moment gameplay. Compare it to last year’s theme “The sound of a Heartbeat.” That theme is everything a theme at a jam should be. It is so simple that you only have to read it once. It serves to focus design, not force it. Oh well.
So Spaceholes came from us wanting to make a shoot em up. We tossed around the theme for about an hour and we had to re-read it a lot (not a simple theme at all) and every time we got somewhere we realized that the theme no longer applied. So we decided to make a shoot em up and do what we could with the theme later. Not long after that we came up with the loose tie in to the theme. So we wanted the player to project their urge to kill on the aliens that they found. So the player was going to be told that the aliens meant them harm and that fighting them was the right thing to do. The aliens would send out some messages and logs to the player in their language (made up of comic book cussing symbols) that would look threatening. The messages would sound like demons chewing gravel and screws. But as the player interacted with the aliens (by killing them and getting upgrades) they would start to translate the alien language. It would turn out that the aliens were peaceful and would have given the upgrades had they been asked. So the player would realize that they were projecting their thoughts on the aliens. To add to the theme, the first translated words would be “harm” or “kill,” from phrases like: “Please do not harm us” and “Do not kill the orphans”
That was how we were thinking about tying the theme in. It was a good plan. We really wanted to do a multiplayer shmup. So we wanted to incorporate the theme, as we had imagined it, into the multiplayer. I designed it so that as players fought each other they would get missiles that destroyed planets. Planets would give the players upgrades. As a player passed any planet they would get the message (like before) and as they blew up a planet the messages would be translated. So that would have worked out great. Time prevented us from adding theme related stuff into the game though, because we wanted a fun game, as opposed to a game that worked with the theme.
The multiplayer stuff was cool to design. I really want to design multiplayer games. That is what I really want to do. So I started getting all of the design layed out, and it was way to complicated for 48 hours. Everything about our design was. But that is always the case in GGJ. So I started with weapons and upgrades and moved into the combat. This was all i really designed at first because I wanted to see what I thought we could work in. I made some basic shmup weapons, and had plans to make them better. The multiplayer stuff is not where I would like it, but I was able to put some of my touches on it. I prefer balanced and competitive play. Let me talk about the art that was made really quick and then I will get back to the design.
The art was stunning. The art team I put together is amazing and they did a lot of great work. Some examples below:
So we made a lot of ships (not all are seen above) and each ship had 4 upgrades (2 for speed and armor) that changed their appearance. Originally I had some complicated design stuff for the acquisition of upgrades. Planets had 3 tiers based on how hard they were to blow up and certain upgrades came from certain tiers. To blow up a planet you needed a planet destroying missile, which was given to you at the start of every life and unlocked when you killed another player. If a player is killed before they unlock their missile then they drop their missile. Players would lose 1 random upgrade per death down to a cap. Weapon wise I had planed and designed 4. (only 2 made it in) Tier 1 planets would unlock new weapons at random as players started with a wimpy single shot laser rifle. Tier 2 planets would unlock the first weapon upgrade or level 1 speed or armor upgrade, again at random. Tier 3 planets would unlock the final upgrades for everything at random. This was done to give the players a goal to work towards, and try and keep players from snowballing out of control.
All of that was scrapped for time. So We decided to give the players the best weapon upgrades from the start, so it would be more fun faster because we were running out of time. We made the players ship upgrade visually with every kill, but stay the same stat wise, and was all reverted when the player died. This eliminated snowballing of any kind, which is good, but felt like it did not reward a player for doing well. So we wanted to give the player a golden halo when they were fully upgraded (4 kills) but that was also scrapped for time. We did get in music that built up and sounded more and more awesome the better you did. Our sound designer was amazing. To give the players something to do, because time is the great killer of features, we made it so that blowing up planets was your score, and killing players gave you more bombs.
All in all there is so much I would have loved to do with this game but time killed most of it. Our programmer worked miracles and did way more than I thought he could in the time frame. I think If I could do it all again I would have narrowed the design much sooner. We would have had a little more time to do stuff and get things implemented. I learned how to work side by side with a programmer, better, and that is very important. I really enjoy game jams and this one was really fun. SCAD Savannah put out some great work and everyone should be proud of the games they made. I know I am. On a parting note though, our game was being played by people pretty consistently for the next few days, which is pretty damn awesome. Are you a space Asshole?
I needed some assets to begin scripting the game, which meant that I had to do art. This is not a normal thing for me. So after having my girlfriend belittle my attempts at making assets for testing, I started the scripting. It was a hard start in a new program, but after I got a better handle on the event system it starting going fast and loose. The hardest thing, but coolest after i figured it out, was how Construct 2 handles object instances. It will make spawning aliens super easy. After all that I was able to get it working online and hosted to my website. HTML5 is super easy and fun.
So apparently I have to do a blog. This is part of the experience of acting like a real studio. It’s not really that big a deal, and I need the 10% for my grade so here I go. My proof of concept was well received today. The game is oddly fun and challenging, and I think once I get more meat on the game bones it will be a great thing to have on my portfolio. I also made a back log, which is going to be useful. Not much happened today. More on design later
So this project came about from an internship I did with Cyril Guichard at Garage Collective. I was asked to make a mobile version of their IP for marketing purposes. They wanted it to be in HTML5 and able to be played on tablets and maybe phones. I will get into the design on my next post because it will be about level 1. But the best part of doing this project is that Cyril gave me some art assets to work with, from his game. They are super easy to implement and already make the game look way better. The skittering bugs and aliens make the game more tense and feel better. Some people think that art does not make a game fun, and that may be true…. but art can make it feel more real and immersive. I think that a good blend of game design and art make the best games.
The 1st level began as proof of concept, but was always what I wanted the 1st level to be. Subsequent levels will do different things and take from different arcade games of old. For the 1st level I wanted the player to feel surrounded and tense, and have the game rely on twitch entirely. The decisions that need to be made are how to prioritize which alines to kill when. Its pretty simple but gets going quickly and is very tense. The main thing I had to do is get the spawn rate of the aliens down. I will be tweaking that for a while but I think I have it in a good place now. The goal is to give the player a little bit of time where the spawn rate feels easy, and the player feels that they have it under control. After a while it slowly gets worse and worse, and creeps up on the player. I have the values that determine the spawn rate do a few things to keep the pace intense. The spawn rate increase every time a value (kill_count) gets to a certain number (starts at 10) and increase by 20 each time. The progression goes: 10, 30, 50, and so on. But kill_count resets every time. meaning that you have to spend longer and longer on the harder spawn rate to keep going. The score multiplier works in a very similar manner but it’s value goes down every time you get hit and the amount of kills needed to get it up resets as well. So the score is easier to get back up the higher it is. This will all change when I add an end condition to Level 1, so that it all carries over into Level 2. But more on that later.
Testing a game like this requires me to restart it a bunch of times. That meant reloading the page. I want my game to feel more smooth than that so I added a start and end screen. The start screen is simple for now, only having a “start game” button. The End Screen though shows you your score and how well you did. This is all simple stuff but required me to get my level to restart in the game and work correctly, which took a little bit of logic I did not anticipate. All the work though made it a better version. I will have it uploaded soon.
I was thinking of adding a bomb to the game. It is a staple of games like this, it can give the player a welcome relief from insanity and with good timing can keep their score from dipping. So I did some more terrible art, and was in the middle of implementing it when it hit me, make it a shield. Bombs are cool, but over done in this genre. The reason it hit me was I was having a slight issue getting it to expand out so that it would act like a ring of death. This way actually worked out better. It still gives the player some relief (3 seconds of shield) adds more stuff to time, and I do not have to do a bomb counter. The shield recharges over 10 seconds (for now) and adds meaningful choices as when to use it. Giving the player some breathing room is important. To make it even more fun the shield does not apply the score multiplier to the aliens it kills, but no aliens hit you, so to maximize your score you have to use it just right.
So I wanted a quick tutorial to tell the player how to play and how the score stuff works. It was an easy addition but very useful. While testing the game though I noticed that with the addition of the shield activating via spacebar that the game had become way to easy on pc. I would have to up the spawn rate a lot to make it challenging (at least for me). This would put the table at a distinct disadvantage, which I do not want. I will have to find a way to balance and tune that so that the tablet players do not get overwhelmed too quickly. I also think that the core deliverable I want out of this game is a well balanced and tuned game, not some super different indie smash hit. Though that would not be bad. If I want it to be a well tuned game I need more opportunities for tuning. The best way that I could do that is by adding multiple difficulties.
So I showed my game to a group for some critique and got a great suggestion that I am going to run with. The suggestion was that there should be things the player does not want to shoot on the screen. This was pretty cool because it would break up the gameplay and add some variety. This caused me to think that there should be a constant stream of people that the player would have to protect from aliens, while protecting themselves. I could have a few different alien types that would do different things. Some aliens would go for the player only. 1 type would wait until saw a human and rush it. Another would go towards the player unless it came near a human. This would add a lot more variety to the game and make it way cooler. It still fits within the core that I want, something to tune and balance. I can still add more difficulties and stuff like that. It will also work as well on a touchscreen. This is going to be a lot of fun to make. I will put different levels on the back burner for now, because this is going to require a lot of change.
Well I added humans in to protect. It makes the game feel way better. Right now they are super clunky and do not always do what I tell them, but that is coming. With the goal to protect them it makes the game much more dynamic. I think once I get more aliens in and have the aliens do different things it will get even better. The goal is to make this something you could watch and want to try your hand at. If there is nothing visually interesting going on then it will not be fun to play. I think that with the humans being part barrier and part objective it will get more frantic. This is a good first step but I want to push the design of this more.
Well they had guns right. After adding the humans there was just no reason not to make them defend themselves. I added in a new alien type , well really I just adjusted what the hunter(dark scary guy) does. He now hunts the humans exclusively and ignores the player. He is hard to bring down, or should be. The humans keep killing him so fast. I think its because they all fire at the same target. I need to find a way to have them not do that. But this gives me ideas for a few more alien types. My friend Ben noted that we need a secondary fire so that you can shoot over the humans some times, which is a great idea so I will work on that. Jack also wants the Humans to come in in groups some times. I will see what I can do.
Well I added a RPG in on the right click. But that does not work well on a tablet. I will have to make buttons for the tablet interface. All the new aliens in make the game super frantic, but with the humans defending themselves it is getting a little bit easier. I think that I am going to make the game start off easier and give the player a bit to learn the mechanics then ramp it up. I re-added the shield because I love it. Now i just have to make the game hard enough to warrant it. The buttons are not working how I want them to, but I have an idea how to fix that. The humans are so much better now. They shoot tiny blue lasers, its so cute. They also move in groups some times. I need to give them collision.
I met with my sound designer Tommy and I think this project is going to be awesome. With all the QOL improvements I have made to the humans I think that they are finally to a point that it is awesome. I can seriously sit there and watch the humans act like tiny little bad-asses. The Aliens all look better with the sine wave function to their movement. I am going to try and randomize it a bit more. I am however rapidly reaching the point that I am going to stop adding features and just polish up what I have. The sounds are going to make a huge difference. I am going to take a page out of my own book and have the music step up and down based on player performance. Because I want the game to start off a little easy while the player gets the hang of the game the music will get cool then when the aliens really start coming it will be harder and harder to have the music be epic. I think that it will add some cool atmosphere to the game. There is a lot of good coming this game’s way.
So I planned to do a lot of stuff. Almost none of it got done. I had to finish a project in another class, so I got little done. I now have the majority of the rest of the quarter to finish this project. So not much has been done. The one thing that I can say is that the sounds are looking… sounding really good. Me and the sound guy have been going back and forth getting some really good stuff going. I will have a lot more time in the near future and lots more is going to get done. If I can I really want to get in a hi-score screen. But we will have to see.
With the help of Jake I made some really good website updates. I updated WordPress, which was more involved than it sounds. I made my permalinks way prettier. I got rid of a useless page in favor of a posts page which is just way more fun. Soon I am going to have more games on the site. Most of this has little to do with the game but was important and needed to be done. It was done to give my game a better home. Now I just have to make the game fun. But i have already worked most of that out, just need to implement it.
White Facade was the idea of Jacob Sawyer, who looked at Metal Gear Solid: Peace Walker and said “that could be done better.” Jake pitched the idea in our Studio 2 class and I was asked to be the design lead. Jake wanted there to be elements of X-Com in there as well, like base building, soldier permanent death, being able to see the soldiers on mission, and the tactical feel of the game. Un-like X-Com though we wanted to limit player agency in the missions.
Since this game was going to be targeted at tablets the primary design goal was to keep it simple. Keeping the game simple, so that it was immediately apparent what was happening with no tutorial, presented an interesting design challenge. Peace Walker (PW) was a good fit for the tablet so I pulled a lot from what they did. The first thing I noticed is that they had a LOT of stats for each soldier, and what they all did was not immediately apparent. I wanted to move away from that so I put in 3 stats that would affect multiple things that all made sense so that the player never had to ask, “What does that do again?”
When it comes to missions PW and X-Com differed quite a bit. In X-Com you would pick your squad and go direct them move by move. That is what gave it such great a tactical feel. In PW, much like the assassin’s guild mini-game in Assassin’s Creed (AC), had you sending soldiers out on missions and waiting a set period of time for them to return to see if they were successful. Jake wanted a mixture here. You could send soldiers on missions all day or if there was a “big” one you could watch it. This meant that the 3 stats needed to be flexible enough to accommodate both methods.
In a non-spectated mission the stats are used to determine percentage chance of success. The first thing that was decided was that the player should never have 100% chance of success. 100% success removes any tension that permanent death adds. Even if the player sent a super hi level soldier against a low level mission there should be that chance that the soldier could be killed. To keep the values simple the three stats (Assault, Stealth, Support) to have max values of 5 per soldier. Each mission would have a max stat value of 20, and only 4 soldier could come. So if all 4 had maxed the stat required they could get 80% chance for success. (It would calculate 20/25 here) The goal with this was that the player could see exactly what was required.
Keeping with making it simple the UI was made to match. Single colors for each stat, Icons that match each stat, and have the pips fill the requirement. This way what you need and how close you are is very apparent and nothing is hidden from the player. To make it even more obvious, the amount of money you can earn is seen and the amount of money each soldier takes to add is removed as they are added. The primary design goal, of keeping it simple, was made prevalent throughout everything.
In a spectated mission the stats had to get more complicated, because more was going on with them. It was still made simple by keeping the numbers in line with the stats. Keeping the stat numbers small meant that simple math was all that was required. Accuracy is determined in a similar way to the percent chance for mission success in the non-spectated missions. Assault added 1 to accuracy per point and Stealth added 2. this meant that the highest value possible was 15, up to 5 more from weapon bonuses. This meant that 20 was the highest possible value and accuracy was calculated out of 25. So if a soldier had max Assault and Stealth the highest accuracy was 80%. This percentage could be increased to 90% through “operations staff” which give passive bonuses to soldiers but cost a lot of money to bring along. Damage was super easy, weapon damage + Assault value. Health was 5 + Support value. I designed stealth and other stuff, but none of that made it in. It also followed the same design themes, simple, never 100%.
All said and done this game was a lot of fun to design for. I find that designing with limitations, (someone else’s concept I just had to make it fun) is the best way. It lets me focus on designing a few things well. This was fun because one of the things I really liked about X-Com was that there could be emergent content or story telling. During play testing of White Facade we all had stories of a soldier, mine was Lazar Dixon, that wrecked entire missions, which for low levels was very hard. We told stories and had a lot of fun discussing how cool our personal soldiers were, Lazar Dixon killed 9 enemy soldiers on his fist mission and he only missed 4 times. This is something that I would love to design again. I think the secret to it, in our case anyway, is the random chance. The perceived notion of my soldier “beating the odds,” the lack of agency, and the permanent death made for a few oddly engaging moments.
Today was a game pitched by Melissa Andrews as more of an experience than a game. I was not originally on the project but was asked to help about half way through. The original objective of Today was to have the players feel guilty as they explore the house of their friend, who has committed suicide. The idea was to have the player explore the house, find out why their friend committed suicide, and ultimately find their body.
The first time I was asked to help they were having a little trouble with the overall system design. The two designers working on the project were spending a lot of time scripting and so they had little time for the actual design. The main issues that they were having boiled down to how to end the game, and how to not make it feel like a game but an experience. These two problems were very interrelated because at the time the game ended when you found his body. There were gates you had to unlock to get there; keys to a room hidden somewhere, a combination to a safe, answering machine with clues on it. The problems with all of this is that they wanted an experiential game, not a point and click adventure.
I recommended that they get rid of as many obvious game elements as possible. The largest offender was the locked bedroom door to stop the player from finding the body as soon as they walked into the house. No one has ever locked their bedroom door with keys that you could open from the outside. This broke the immersion. That solution, however, led to another problem. The player could just walk in, find the body, and end the game. So the next major change that I suggested was to make the game loop when you found the body.
I thought that this would be the most useful solution. Every time you find the body the game starts over. This would allow the player to do what came natural at first, do a quick glance through the house for obvious signs. But after a a loop or two the player would start wondering why their friend committed suicide as well as why the game was looping and would explore the house to find out. Then the only way to end the game was to walk out the gate you entered from. This way the player experienced exactly what they wanted to and left. It would also, I hoped, add to the guilt. The only way to end the game was to leave your friend’s body undiscovered.
The second time I was asked to help was much less system and much more level design. I helped with sound and immersion. Small tweaks to what was there to make it as experiential as possible. I helped their level designer come up with sounds to add to give the house and environment some more weight and presence. House creaks, wind, ambient traffic, and other stuff like that. I helped the footsteps sound more natural as well. Some of the old game elements were still in there, finding batteries for the answering machine and the combination to the safe, but those made sense in the world and did not feel like obvious game elements. The one major system change I did make was to suggest adding a narrator.
The original design called for a silent protagonist in order to allow players to feel like it was happening to them as opposed to a character. The problem was that with the silent protagonist gave no clues as to help direct the player through the environment. In other games they could have used literal or figurative signs that would let the player know where to go, but those would have been very out of place in this game. This game was supposed to prompt exploration and the easiest way to do that was to have a narrator give small hints and directions as to where to look and go, otherwise the players usually just felt lost. It all helped but would need some serious narrative overhaul to make the whole thing come together, but that is hopefully to come soon.
All said and done it was a fun project to help on and offered some fun design challenges. I had never had to try and make a game not feel like a game. That is something that I now have an idea about how to do.
This was a project I worked on in my Gamified Systems class. The class was all about designing gamifed systems for clients that our teacher got us in touch with. This project was for a company called Fandor. If you are unfamiliar with Fandor, which is most likely, they are essentially an indie Netflix. They focus their product towards movie enthusiasts, people who love the old black and white films and shun most modern movies. They also look at film festival films, and indie produced films. They came to SCAD to get some help with their loyalty program. They wanted a gamified system that would reward their customers for participating in their site.
Before coming to us they had done some market research into their customers. They wanted to know what drove them and how they participated in the service. That research identified 4 groups; Detectives, Explorers, Performers, and Couch Potatoes. The research they gave us had a lot of words and fancy pictures but boiled down to this. Detectives wanted to find the most obscure movies and newest indie stuff, and enjoy it themselves. Explorers were very similar to Detectives but they liked to share more. Performers liked more filtered content, that matched their interests, and share it a lot. Couch Potatoes just wanted content given to them that was easy to digest.
Our goal in the class was to give them a system that allowed each group to do what they wanted to do already, get rewarded for it, and contribute to the community. So I came up with the “Fandor Funnel” as we all started calling it.
This was the diagram we made to describe it. Essentially I wanted to organize the groups and this was the most obvious way to do it. The Detectives would sort through all of the movies that were obscure, new, and hard to find. The Explorers would get the movies from that group that the Detectives found to be the most enjoyable by genre. The Performers would look to the Explorers for a more filtered experience based on what they liked and share it. The sharing would happen through social media and be distilled to the Couch Potatoes. This made the most sense to me. Get all the groups doing what they wanted and would have done anyway. All we had to do then was reward them.
This is a diagram of the roles and what they could do in our system. It goes over mostly what I have already talked about with a few additions. We wanted to design the product around their exclusive and discerning clientele. One of the main ideas that I had was to allow the users to write movie reviews, and have the community rate the reviews. This way the Detectives and Explorers could have that avenue of expression. The people that wrote the best reviews would start to get noticed for their discerning taste and recommendations. We also had the idea of having public viewings of movies like a film festival. This would be something that a lot of people could tune in to and watch at the same time. To enhance the experience for the more knowledgeable and well respected members of the community I wanted them to be allowed to participate in a chat that discussed the movie. Everyone could see it, and maybe vote on some of the topics to be discussed, but only the best rated and most outspoken members could be invited to participate.
This is a diagram of the rewards as we saw them. Everyone had something to do that would reward them and fit with their goals and motivations.
I also wanted a profile page that would serve a variety of functions. Let users know where they stood in the community. Give them a sense of how many reviews they had written, and how those reviews had been received. Reward them with badges for completing certain objectives, like write the first review of a movie. Let them see what their favorite genres are based on what movies they have watched. A simplified version of this page would be view-able to others. This was so if you found someone that wrote a review of a movie that you liked or agreed with, you could “follow” them and see what they watch and write. Giving people the ability to find new movies if they are less inclined to go looking for new stuff. This all ties back into the funnel. The Detectives would only really be following each other. The Explorers would have their groups of Detectives they followed, and so on.
When we pitched this to Fandor they seemed really receptive. I have no idea if they will follow through, but I think they should. I am not a fan of their product, which made designing for it a lot of fun. I had to get into a different mindset in order to make a system that would not alienate the user base. The gamified system had to be designed in a way that did not appear to be a game. Which led to the best idea I had while working on this project, the title reward system. Titles are great in a lot of games because they are funny or impressive sounding. The problem with that, in this instance, is that the users want to be very individualized. So I came up with title rewards being tiered in such a way that the more you earned the more words you could add to your title and you could say whatever you wanted in it. It would have the same effect as it did in other games and systems but would be perfect for the target audience.