Dev Diary - Project 3: Changing The Game

During the playtest, the major issue was with the "Planning Phase". Our idea was that when the phase starts, the player can observe guard movements and draw out a route for the accomplice. When the player finishes the route on the exit tile and lifts their finger, the "Execution Phase" triggers instantly.

What we found in playtesting was that finishing the route and instantly switching phases, disorientates the player. The accomplice is already moving by the time they even begin to lift their finger away from the screen. This instant change is what we don't want. It creates the experience of not being in total control of the accomplice and its path, as you should be. 

A way to fix this, would be to make the "Planning Phase" truly a planning phase. When the player draws the route and it connects to the exit tile, it doesn't instantly start the next phase. A button pops up saying "EXECUTE". Pressing it will start the "Execution Phase". This gives the player time to still plan. They don't need to awkwardly hold their finger 1 tile away from the exit, waiting for the guards to get into position. Having a dedicated button to then start the next phase, allows the player to time the execution more precisely. As after all, it is a stealth/strategy game and giving the player time to observe the play-field is necessary. 

Also, during the playtest, drawing the actual route was a challenge in itself. If you let go before getting to the exit tile, the route would disappear. If you hit a wall, the route would disappear. The route also couldn't overlap itself. This was a massive problem and the main point of feedback from testers.

In having the route drawing like that, it takes away from the experience yet again. Drawing the route shouldn't be hard. It should be something you can do in the back of your mind while observing guard patrols and figuring out the best places to move to. Focusing on drawing the line, not hitting walls removes that aspect of observation. So a way to fix it, which is already underway is...

• Allowing the player to let go of the path and continue on with it, allowing them to let go of the screen.
  • This will allow more time for the player to observe the level.
• Overlapping the route.
  • This allows for more possible paths, more solutions to the puzzle.

Dev Diary - Project 3: The First Playtest

Today was our first playtest. We went into class with a few minor issues that we quickly tackled before the testing. These including making the game run much smoother on the tablet. Apart from that, the game was pretty solid for a weeks work.

We had numerous people playtest the game and even with a 1 page document telling them what to do, some of them were confused.

In the "Planning Phase" you're mean't to draw out your accomplice's route, going over the primary valuable and finishing at the exit. Can you tell how you would start? Where the entry/exit is? Where the primary valuable is? Visually showing the player what their goal is and how they can start, is something that is missing.

By far the biggest issue with the playtest though, was drawing out the accomplice's route. Around 80% of the time, the testers were trying to draw the line, hoping that it won't hit a wall and destroy. This was a big issue on our side. In our minds we expected around 30-40% of the playtime for each level would be in the "Planning Phase", not almost the whole playtest. 

Once the testers finally made a route, the "Execution Phase" happened straight away. They were thrust into the game, with the accomplice moving along the path. What they had to do from that point was still unclear. They read that they need to tap on distractions to distract the guards, but where are they? What do they look like? By the time they managed to figure it out, they were already caught. Again like mentioned before, showing the player what they can interact with is necessary.

So what needs to be fixed?

• First of all, drawing the accomplice route.
  • Make it not destroy when it hits a wall.
  • Fix all the numerous bugs it had.
  • Make it not instantly switch phases upon letting go on an exit tile.
• Visually show the player what to do and how the world works.
  • This could mean having the entrance tile glow or flash to attract the attention of the player, showing them that that is where they need to start drawing their route from.
  • Make distractions and the primary valuables more visible.
    • Have the primary valuable glow golden.
    • Have the distractions show off a radius of effect during the "Planning Phase" and have a small particle effect.
• Numerous small bugs to do with the guards, including...
  • Accomplice being able to walk through vision cone sometimes.
  • Movement bugging out.
  • Moving to distractions and standing at an awkward position.

Dev Diary - Project 3: Learning How to Use CSV's in Unity

For our project we will be making out levels in Google Sheets and exporting them as CSV's. I've been looking at examples of both CSV's and CSV readers on YouTube and different websites. Pretty much a CSV file is a spreadsheet converted to text, separated by commas. A CSV reader, converts that file into pretty much anything. It can be a simple sting array or even a dictionary. It depends on what sort of project you're working on, as well as how complex/flexible you want the reader to be. For our project, we're going to be reading prefab names from the CSV. So it will translate to either a normal string array, or a 2D string array, which will give us coordinates for placing the tiles. Let's look at an example of a CSV reader I found online here, and break it down.

This is a function essentially takes in a CSV file as a TextAsset and returns a 2D string array. A 2D string array would be best for grid based games, such as the one we're making. This is because the 2 index's that an element has in the array can correspond to a reference point in a grid, or as an individual tile.

Then we create a 2D string array variable called "allStringsByWord". This array will have each element corresponding to an individual word or "cell" in the CSV. Also there is another variable, this time just a normal string array called "allStringsByLine". This is then set to be each line of the CSV file. The .Split function, splits a string based on a character. In this case it was the "\n" or new line character, so each element of the array will be a line in the CSV.

Then we make the "allStringsByWord" array's row count equal to the amount of lines (or rows) in the "allStringsByLine" array.

Next, we loop through the length of the "allStringsByLine" array. Each row in the "allStringsByWord" 2D array, is having columns added. These columns are done by splitting the same corresponding element in the "allStringsByLine" array by commas (,). This essentially makes the 2D string array represent the spreadsheet layout. If there are 5 rows and 3 columns in the spreadsheet, then the array size will be [5][3]. You can then get elements from that array, for example allStringsByWord[2][1] will return the cell of string from the 2nd row, 1st column.

Our CSV loader will of course be more complex in the game. It will need to sort through each element of the 2D array, perhaps each element would also have more than 1 value. Since we have guard patrols, this may be a challenge. Either way, through looking at this CSV loader and many others, I now have a better understanding of what they are, what they do and how they do it.

Dev Diary - Project 3: Learning MagicaVoxel

For our 3rd project we will be using MagicaVoxel for the 3D models. We have 6 animators working with us, yet it's still good to know how to use the program. First I downloaded the program and then watched this YouTube tutorial. It was about making a tree yet I knew what I wanted to make.

I went in and re-created the car model from my Barnstorming remake.

I started off pretty much the same way I did with the original model. With the wheels. I made one, then duplicated it 3 times. This gave me the general dimensions of the car, placing the 4 wheels. From there, I made the 2 axles connect the front and back wheels, then have the drive shaft connect those 2. Then the base plate and the orange "wheel guard" thing. From this point I was already using quite a few tools. I used the circle tool to create the wheel shape, the paint tool to make the white hub caps and the "extend" tool to make the axles. 

The next step was for the body of the car. I tried to get a similar looking red and began to draw it on. For this part I turned on the mirror option, so that I really only needed to create half the car. Since I was working with voxels and could pretty much draw on the textures, I decided to add some detail. The shape of the door and edges of the car's body are painted on in a darker red. I think it makes the car look a bit better, yet some could say it makes it look tacky.

Other features I added to the car that diverted from the original was:

• Spare wheel.
• Dimension to the car body.
• Bottom axles and driveshaft.
• Interior.

I made an interior to the car. It had a dashboard, steering wheel, pedals and seats. For this I needed to really know the camera tools. They were pretty easy to understand and actually much better in my opinion than other 3D model programs. Here, you just hold right mouse button to look around and scroll wheel to zoom in and out. While other programs like Maya require you to hold ALT to look and move around, MagicaVoxel is simple yet effective in its camera controls.

Dev Diary - Project 3: The Second Pitch

After our initial pitch, we were told that by the end of the day, we would be pitching our games again, based on the feedback. Since me and my team pretty much remade our game, we had to create a new pitch. 

Since the new game has a more solid grounding and a definitive start and end point to each level, it was much easier to talk about. With the previous game, it was just "sneak around and steal stuff". This one has 2 distinct stages, each giving the player different playstyles and options.

We also had images showing what the game would look like on the tablet. With our previous pitch, we had questions asking about the camera angle and presentation of the levels. The audience weren't able to picture the game in their head which is a problem. Having images representing the game though, fixes this and allowed us to show off the 2 different stages, planning and execution.

Overall, the pitch went well. Much better than our first one. Some of the feedback we got was:

• Consider the game play time.
• Have the player steal more sentimental valuables, rather than money.
• Consider the planning stage.

It's quite open. There was no feedback directly criticising parts of the game, but feedback that wants parts of the game to be flushed out more. I don't really know how to put it into words. The game idea was deemed good and overall, people liked it. The scope was good, and other questions were generally asking if certain mechanics would be in the game. From the feedback we also got quite a few new ideas, like having some items affect the accomplice and maybe having the guards get suspicious if the player triggers too many distractions.

From here, we need to finalise the game idea and start working on the feature spec and tech spec.

Dev Diary - Project 3: Creating a New Game in 30 Minutes

After the initial pitch and feedback, we as a team were thinking. You as the player are essentially just moving around. In a way it is a dungeon crawler. Along with the scope being too big was the fact that this game wasn't a unique touch experience. It would be better to play this type of game on a computer or with a controller. So we decided to create a new game.

An issue with the Thief like game, was that its mechanics were all over the place. There was no hook or interesting core idea of the game. You walked around. Avoiding guards while stealing valuables. I also thought that there was no structure. If you were to tell someone about this game and explain how the process of completing a level was achieved, you couldn't really. It would just be something like "sneak around and steal stuff". It just didn't sit right with us after the pitch feedback.

The new game we designed though, is much better in our opinions. You the player, are the eyes in the sky, the hacker behind the computer (tablet in this case). You have hacked into many billionaire mansion security systems, and your accomplice is to go in and steal a valuable. First, you need to plan out their path, tracing it out with your finger as when they go in, you cannot control them. While doing that, you will want to observe guard patrol patterns. Like the thief game, these guards have vision cones. Now, when your accomplice enters the house, it is up to you to cause distractions for the guards. Ringing phones, flickering lights and turning on house hold appliances to attract the guards attention away from their patrol and your accomplice's potential route.

This game has core idea of distraction. Distract the guards while your accomplice burgles the house. It has mechanics from there, expanding out from it, still connected. Like drawing the guards attention in many ways. It is also built for a touch device. You draw out your accomplice's route and tap on distractions to trigger them. We believe that this idea is much better than the last in both design and scope. 

Dev Diary - Project 3: The Initial Pitch

As mentioned in the previous dev diary, I said that we were going with the metroidvania/stealth game. Well as team we blatantly saw that it far too over scoped. The entire map would need to be planned out before we start creating levels, and the design behind these sort of games is very hard. So we went for our original idea of a top down, Thief like stealth game.

Just as a quick note. I'm writing this dev diary after Wednesday, which there will 2 more of these from that day. Things did change quite a bit, so keep that in mind.

When brainstorming the game, we came up with many ideas for cool things. Like hiding in cupboards to avoid guards, smoke bombs, fire crackers, the whole lot. Now we knew obviously that this stuff wouldn't be included in the pitch. So we stripped down the game to its "core" mechanics and started out a script from there.

It took forever to figure out a game name, with us finally coming to a decision of "Rob Em Blind" after a long time and a large list of other ideas. The team name took even longer to figure out. We wanted it to reflect both us as a team, as well as the game. Before class, we were going over a lot of potential names. It wasn't until we began the other team's pitches, that we quickly chose "Team Sneaky". Not really the most unique or thought out name, but it was what we had to go with.

From there, our pitch went over how it was set in the Victorian era and how you as a thief, played the game. Vision cones, sound waves and the objective of the game were explained and we were pretty confident that the audience could picture it in their head.

After the pitch was presented, it was feedback time. Overall, people liked the Victorian setting and thief theme. There was some criticism though and confusion among the audience. The main points were:

• The scope is too big.
• Levels take too long to complete.
• It should be turn based.

We agreed with most of the points presented, except for the fact that it should be turn based. In our minds, this was a game about pre-planning and execution. You observe guard movements and then move in, dodging the vision cones and timing your moves. That was the sort of experience we were going for. Tense and risk vs reward situations.

After all the pitches were done, we were talked to as a class. In some way or another, every one of the pitched games was a dungeon crawler. This wasn't really a bad thing, just something that the lecturers wanted to steer us away from. Then, we had to strip down our games to its core mechanic. Ours was "traversal". Moving around. Not that fun or engaging on a touch device. We as a team, saw this as a problem. So we created a new game.

Dev Diary - Project 3: Brainstorming Ideas

Today in class, we were assigned our next project. To create a game in teams, which loads levels from ascii map or csvs files. It has to be on an android tablet and have a minimum of 50 levels.

As a team we began to brainstorm ideas. The obvious "dungeon crawler" game caught our minds and we went from there. The animation students were previously doing an assignment in the style of steampunk, which everyone agreed would also be good for this project. Then with the idea of steampunk in mind, we though that maybe each level could be on an airship, where the player needs to go around repairing them.

Except, that idea was scrapped.

Many of the other teams had brainstormed dungeon crawlers, and the lecturers weren't that enthusiastic about that sort of game. So from there we kept the steampunk idea and thought of a Thief style of game. Where the player would sneak around different houses, stealing goods to sell later on. It was generally accepted by the team, yet upon further talk about it we decided to take another approach.

We would keep the steampunk and stealthy stuff, yet change the different houses (levels) to one big level. The game would essentially be a metroidvania. The player is a robot who is trying to escape a robot factory. Along the way, different upgrades and tools can be found and all other systems that are associated with metroidvanias.

Studio 1, Project 2 - Post Mortem

This trimester in Studio 1, we as a class turned the original Up Ship Creek board game, into a hex based exploration game. Along with that, the class was divided up into teams to each create a new scenario as well as common items, hazards and condition cards. This post mortem will focus on both working as a class, and working in the smaller team.

Time Management

The most significant problem with the project, was time management. Tasks as a team were done only days, if not the night before they were due. This didn't directly affect the quality of work, although most certainly it would have been better if the time was spread across the week. It did in a way make the team feel kind of disconnected. We only ever really done work on a Sunday or Tuesday night outside of class, clumping all that needed to be done in just one night. In the end we did get the required work done (most of the time), yet leaving such a tight time margin, did remove the ability to alter the project in a major way. For me, this isn't new. Time management is something that I have struggled with in many past assignments. I always just say "i'll just do it tomorrow". The work only really gets done though, when tomorrow is the day it's due. In previous post mortems, a paragraph similar to this one has been said, yet nothing really seems to be changing. One thing I have noticed though, is that when HacknPlan tasks are assigned and timed at the start of the week, the work will generally be done across the week. In the case for this project though, HacknPlan tasks were written out in the middle of the week, or when the tasks were being done.

So, how can this problem be fixed? Like I said above, in some previous projects where HacknPlan tasks were assigned at the start of the week, work was done properly. This is probably because if you have an empty HacknPlan milestone and only create tasks once they've been done, it looks as if there isn't any work to do, or that the work is flexible. On the other hand, if the tasks are there and set for the week, you can see the amount of work you need to do. The exact hours it will take, so you can chip away at it throughout the week. Having someone (most likely the project leader) organise all the tasks for the week and plot them out in the HacknPlan milestone, this will not only make things more organised, but it will set an objective. People will see what they've done and what they haven't done. Thinking in your head that you have to do ten hours of work on a Sunday night, compared to thinking that you need to do this and that Sunday night, is much more daunting. 

Playtesting

Playtesting the game was both great and terrible. Since Up Ship Creek has so many systems in play and the fact that we were making a totally new way to play the game, playtesting it was hard. Not setting it up and getting people to play the game. Or even having them understand the rules. In my mind, what was hard was getting the playtesters to play the game from a perspective of an average player. Early on in playtests, my team would get the testers in and explain the rules to them verbally. Even at times, during explaining the rules, we would say something like; "you'd want to avoid that though", or "this is what you want to get". In a way, we were telling them how they should be playing the game, not how they could be playing the game. This would make their experience different from an average player who goes and buys the game from the shop. Even during play we would say stuff about saving items or good strategies for later on. We were playing the game from a developers perspective, when we should have been playing the game from the testers perspective. Later on, when a rule book was being produced, playtesting still had this effect in a way. As a team we kept on telling the testers to "refer to the rule book" when they asked a question about a system, yet still when playing the game casually, we slipped. It creates impressions in the testers mind, removing the aspect of "should I do this, or this?" a bit. 

The obvious solution would be to not say anything. For when we didn't have the rule book, we needed to talk, so the rules could be explained. Even when we did have it, casual talk and strategising in-game, allowed these "developer perspectives" to seep in. Not talking at all or very minimal during play would not be ideal. The entire point of the game is to talk with each other and stratagise about what to do. A solution would be to "think as the tester". Going in and only really talking about what the tester knows so far. If they are confused, don't tell them what to do. Tell them to refer to the rule book. Not only does it simulate a real playing of the game, it puts your rule book to the test. If there isn't one though, then explain the rules as passive as possible, trying not to give away any possible strategies or indication of how bad/good the system is to the player. While playing, still talk to the testers as after all, it is a cooperative game - just play of their knowledge and don't play the game by yourself. By that I mean, allow the testers to make the decisions. If you are the one choosing where to go and acting as the "captain", then the entire point of the playtest is kind of ruined. Having the testers take lead in a way, and direct the flow of the game, puts tension on the systems. Will these things work? Will they integrate seamlessly with the rest of the game? Will they not be too harsh/too easy for the players? The only way to test these hypothesis', is by having testers with open minds, who are not persuaded by the developers. In some cases where we kept telling the testers to "read the rule book", it sunk in more and made them talk between each other on what to do. Compared to when we told them the rules, with some bias mixed in, they would just follow what we said, not strategising. 

Working as a Class

Something that I was a bit concerned about at the start of the project, which turned out to be quite a surprise, was working as a class. By this I mean coming up with new ideas and iterating upon existing ones. Someone would come up with an idea, the class would talk about it, then we would write it down and get it ready for playtesting. Even outside of class, we had a Discord server, where the whole class could come together to collaborate, ask questions and even have a few meetings. Later on when we had a rule book to work on, sections were done usually by an individual person, then the class would go over them. I recon this behaviour came from the class not really having anyone be a control freak. Of course there were individuals at time who would take charge when things got slow or out of hand, but no one ever had total control of the project. This can be both a good and bad thing. In one case when our lecturer wasn't in class, there was a debate over hazard tokens vs hazard tiles. Since there was no "leader", a final decision was only decided after some time and vote of hands. If there was a leader in that case, they could make the final decision so that the class could get onto the next point at hand.

As mentioned above, the main reason I think the class worked well as a dynamic, was because there was no one in total control. Arguments were rare as generally once a suggestion was made, it was talked about, then agreed upon and set for playtesting. In practice, this may not be possible. There may be people who view their opinion as greater than others. To combat this, it's the class' responsibility to view everyone's opinion as equal. You need to allow different people to talk and listen to their suggestions and reasoning behind ideas. This not only creates an equal work space, but a civil one. Outside of class, Discord was a necessity for us. Setting up a server allows you to not only share ideas and images, but also have voice meetings. You can see who's online, allowing for members to gather the class for meetings and discussions at anytime. This needs to be done at the start of the project. Because it sets a standard means of communication outside of class. If it is set up half way through, people will view it as just something to the side. Yet if it's integrated into the class workflow from the beginning, people will be more inclined to use it. Just like with time management above. Setting a standard from the beginning for me and probably others, cements in place a pillar, holding up the project.

To conclude, the project overall went quite well. A part from time management issues and changing perspectives for playtesting, the final product was a solid "new" board game, with a fairly solid scenario from my team. Working as a class was better than expected as a lot of the time, working with more people is a challenging. Yet it seems in the end it worked out pretty good.

Dev Diary - Project 2: Final Playtest

Today was the last day to work on the project and playtest the game. As a class, our main objective was to test out the new rule book, to see if it's cohesive and easy to understand. My team had 2 animators come in, who have never played the game before. The rule book was given to them and after they read over it, we decided to play the game.

They understood fairly early on, the initial game setup, round phases, tile placement and tokens. One of them did try to connect a blank tile to a path though, which I think is due to our diagrams not showing blanks. There is an image that displays what valid placement of tiles is, compared to non-valid placement of tiles. The image though, doesn't show a blank connecting only to blank edges, so the misconception was understandable.

Overall, the playtest went well. Whenever they asked a question or didn't understand a mechanic, I always said to try and find the answer in the rule book. Throughout the playtest, I was constantly referencing the rule book, since that was the main thing we were trying to test. Here's some of the issues that they had with the rule book:

1. They were constantly flicking through, trying to find different mechanics. They suggested we have each category on a separate page. Hazards, tokens, tile placement, etc, each on a separate page so that it is much easier to navigate around and pick out what you need.
2. There was some contradictory information. This was minor, but things like the number of tokens in the game and some tile placement rules were different around the rule book.
3. There was information missing. How condition cards work and how the cat enters the game were elements that were totally missing from the rule book.

These issues are mainly small errors and formatting problems. For the actual flow of the game and conveying the order and process that things happen, they said it was good. And that is what we were mainly trying to do. Previous versions of the rule book were just the game mechanics thrown under headings. There was no start point or order of play. It left the playtesters asking more questions, the more they read. Now though, the rule book seems to be mainly intact and usable in a real world situation. This meaning that if we gave it to a bunch of strangers and left them to their own devices, they should be able to play the game the way it was made.

Dev Diary - Project 2: Making the Game Hard

Up Ship Creek is what you would call, a hard game. It was designed that way with turn/time restrictions, hazards and a whole bunch of over laying rules that can make the road uneven. In the hex game we as a class are making, it seems that it hasn't been that hard of a game. 

With the removal of hazard rooms, you start out with no hazards. So from the get go there are no dangers (depending on the scenario). It's only when you draw tokens, does that sense of danger increase. The first iteration of the tokens though, had only 5 hazard tokens, that being around 1/4 of the total token pool. When we playtested that, it seemed that most of the time the players would get item tokens, so going in, there wasn't as much risk or worry as we would have liked. To fix that though, we're boosting the hazard token count up to 10, that along with the 9 cat tokens will have the players going in with a more than 1/2 chance of getting a bad token. This hasn't been playtested yet, but will hopefully make the game both harder and more fun.

Yes, fun. Having the tokens be around 40/60 good or bad will make it so that they cannot really predict what they're going to get. This is chance, which creates uncertainty, that equals hopefully more fun for the players. Because having them just fly through the game, only really worrying about their AP and the remaining rounds, is not that fun. Contemplating whether or not to go through a hazard when you're on low health is much more fun than just moving from ship piece to ship piece.

For my team, this is especially important. Our previous playtests have seen people rarely ever get damaged. Again, this might be because of the small pool of hazards, or because of the scenario. Right now we only have 1 crisis which has status effects laid down. 2 rooms are on fire and you need to put them out. There is a chance of you getting damaged, which creates tension and risk. For a scenario about crashing on an alien planet, you would expect there to be more dangerous things. Exposed wires, broken machines, alien creatures, poisonous stuff. I will admit, that the game we are creating hasn't seemed that fun to me. It has been fun playing it in a way, knowing that I've helped create it and have seen its evolution. It's not fun though in a pure game play sense. Not taking damage and not taking those large risks makes the game seem almost like riding on a bus, rather than driving a car. This meaning, you're sitting back, going where you expect to go with no surprises. Contrary to driving a car, where you're in total control and have the ability to change the course or risk at any time. Not the best analogy actually...

 Pretty much, fun comes from taking risks and surprises, that is why I found the original Up Ship Creek game so fun, while I found this one to be... okay. Our scenario specifically, needs fine tuning both through the core game rules, and through the crisis' to make them as exciting as possible. Making them harder, making them a challenge rather than a straight path is what's needed to make a truly fun and compelling scenario.

Dev Diary - Project 2: Trying to Finalise the Rulebook

For this project, we are adding many new features and changing many of the existing ones, so a new rule book needs to be made. The class is working on it together and has been playtested a couple of times. The first version of it, was basically a dump of all the core game rules with headings. As you could guess, the playtest didn't go that well. There was no start point or rules for how to game flows. Who does what when and what restrictions are there. The second version, was a better laid out version, detailing setup rules, phases and what each player does at the end and during a turn. My team playtested it with a Studio 2 student, who was a great help. Basically, the rule book was missing quite a few instructions and wasn't new player friendly.

The problem, was that the rule book was written from our (the class') perspective, so many of the small details were just ignored. On the front page, it talks about things like refreshing HP and AP. What's HP and AP? Another problem with it, was that there was no major start point. The rule book began by telling you how to set up the 5 initial hex's on the board. Every step from when the player's open the box should be written down. Where the cards get placed. Are they shuffled? Face down? How do the bar cards get determined? There wasn't even anything in the rule book about scenario's or crisis'.

This is all stuff that we didn't think about. Again, from our perspective, the playtesters didn't have to worry about setting up the board as it was already there for them when they arrived. Going on with this, there was a big problem, where our tester was constantly flicking back and forth between pages to find out information about different things. Player movement, tile placement, etc, were all under different headings on different pages. There was no flow of information. It didn't read like a book, where the information you needed to play the game was presented in a linear fashion.

So, what did we get back from playtesting with the rule book? Quite a big actually.

1. Write the rule book so that it reads at an understanding of a totally new player.
2. Write it in a way, so that the player's don't need to be constantly flicking through pages. Make it read like a book, from the start to the finish.
3. Have clearer set up instructions. List off where cards go, when to draw player cards and when to pick/read the crisis.
4. Also another thing is to not make it too long. As much as we'd like to dump all of our dot points and information into this rule book, we do need to keep in mind attention span. Reading a 10 page rule book will be boring and you'll probably forget half the rules by the end of it. Having a short, but concise rule book, with solid set up instuctions and easy to understand language is key.

Dev Diary - Project 2: Player Experience

Player experience is a thing that we need to constantly be thinking about with our scenarios. A quick rundown of our scenario is:

Your crew crash land on an alien planet. The locals are quite primitive and on edge about their new, out of this world neighbours. You need to gain their trust, while at the same time trying not to freak them out, or worse.

Start Crisis: One of the aliens is coming to search the ship. Hide the weapons so that they don't think you're hostile.

A Crisis': One of the aliens came on your ship at night and killed themselves on a piece of machinery. Dispose of their body parts and fix the machine.

B Crisis': The mining laser turned on after the crash and is making the locals sick. Turn off the laser and fix the ship.

C Crisis': The leader of the aliens has come to request a statue be made for him. Quickly scrap together a statue.

End Crisis: Your ship malfunctions and is about to blow. Cobble together a contraption to launch the core into space, so that you and the natives don't all die.

The experience we're going for is to "keep the players on edge". Pretty much the players need to feel that they are at risk of being seen as enemies and then being killed. This is done through times crisis'. All the 3 story threads have at least 1 timed crisis, drilling in home this experience. The timer though is quite large, giving the players enough time to think about their actions, yet still having that thought of taking too long be in the back of their minds.

Hiding a dead body, hurrying to fix an out of control laser, rushing together a statue and getting rid of a bomb are all things that will make people panic and rush to complete. The players are fighting against the alien's suspicion of them, constantly trying to make things right and appeal to their new "friends". It's not complete though. The experience is something that we still need to further integrate into the scenario, so that the players can feel it, rather than be told it.

Dev Diary - Project 2: Hazard Tiles vs Hazard Tokens

Last week in class, we were having a debate about what's better. Hazard tiles, or hazard tokens. Hazards in the original Up Ship Creek game were important and added some risk into the play. For the hex based game, we currently have the token system in place, yet there are a couple of people who want the hazards to be tiles. Here's a run down the the 2 systems:

Hazard Tokens

Every round the 3rd player draws a token or anytime during gameplay, a player can draw a token for 1 AP. The token is then placed on any adjacent tile around the player and can be used when the player enters that hex. A hazard token though, triggers instantly when the player enters the hex (just like the hazard rooms in Up Ship Creek). They draw a hazard card and once that is done, the token gets discarded.

Hazard Tiles

Hazard tiles are mixed in with both the environmental hex deck, and the ship deck (i'm not 100% sure on that though), and have a chance of being drawn when a player draws a hex from the deck. A hazard tile is a permanent hazard zone that will be tied to the hex, so if a player enters the hex, a hazard card will be drawn. 

2 systems, each come around differently, and change the experience of the game. I for one was on the side of the hazard tokens when this debate occurred. Why? Well hear out my reasoning.

With hazard tokens, you take a risk (picking a token) and if it's not good, you are forced to place it down. Whereas with the tiles, if you draw a hazard token, yes you took a risk, but you don't have to place it. You can keep it in your hand for the entire game and if at the point where you need to place it, it's not that bad. You can choose where to place it. So if there's a corner of the map you don't go, just slap it on there. Pile up your hazard tiles over there and never worry about them. With the tokens though, you need to place them, and adjacent to you, so it will most likely be in an active area.

The tiles to me just seem like an inconvenience, whereas the tokens seem like a threat. In the end though, the final outcome was that there were going to be the hazard tokens, but they're permanent. This creates the risky nature of the tokens, with the permanency of the tiles.

Dev Diary - Project 2: Node Blocking

In the original Up Ship Creek game, node blocking is a thing. You cannot move onto or through a node that is being occupied by another player (unless you are the Contortionist character). With the hex based game though, it's different. There are 2 distinct areas, one being the ship tiles and the other being the environmental tiles. What we decided on, was that the ship tiles had the original node blocking rules, while the environmental tiles, are still up to debate. 

It's fairly agreed upon that in these outside tiles, node blocking wont really be a thing, that players can move through nodes with other players in them, but at a cost. We talked about it briefly, stating that a player can move through a node with another player for an extra 1 AP cost. But what does that mean? From what I see, there are 2 different ways that this can go down, each with their own pros and cons:

1. Moving onto the node of another player costs 2 AP. This would then mean that 2 players inhabit that node.
2. It would cost 2 AP to switch nodes with an adjacent player. This mean only 1 player can inhabit a node.

The first one is the option most people agree with, yet when you bring up the fact that it would need to have a rule for 2 people to be on a node at once, there's disagreement. When you say that it costs 2 AP to go through a node with a player on it, most people would picture in their mind, a player moving past the node and on wards with the other player in it. But what if you are next to them with only 2 AP. Can you still move past them? Or do you just go onto the same node as them? If so then there needs to be a rule for multiple people in a node at a time. Can all the players be on a node at a time? If so would it cost 3 AP for the third player to join? If you say no, only 1 person can be on a node at once, yet you still agree with the 2 AP cost to move past them. Then that doesn't make sense. It wouldn't cost 2 AP to move past a player, node blocking would just not exist.

The second option was one that I thought about. What if you wanted to go onto or past a node that a player is on, but it would cost you an extra 1 AP (so 2 AP to move) to switch places with the player in your way. If the player your trying to pass is on their way to a goal, switching with them will set them back a node. It may seem bad on their side, but since it's a co-op game, it can be agreed upon. Generally, if you are setting out towards a goal, all the players would picture their turns ahead of time. Yet if you are clumsy and just go straight for a goal, then there might be a problem when later on, 1 player needs to get past another, as they still have AP and need to get to a goal. Spending 2 AP to get onto their node and to set them back to your node, will in my mind, be balanced. There is the 2 AP cost in the first place, so that it isn't as easy as just moving around normally, and there is the set back, which can be punishment for poor planning.

Thematically, the node blocking rules in and out of the ship seem pretty good. Inside of a ship (especially a crashed one), it would be crammed, so moving past people would be hard. Whereas, moving around and past people outside would be easier as you are in the open.

Dev Diary - Barnstorming: Car Animations

Since you could call the game "arcady", the movement and interaction of objects don't need to look the best. Although I believe adding these two animations (seen below), it adds much to the experience and overall polish of the final product. I went over the game feel aspect of the animations here. For now, lets talk about the process of making them.

Unity's in-built Mecanim animation system was used to create these. For both animations, the only properties that are being modified are the position and rotation of the model. The animation also isn't applied to the player's main object, but the 3D model inside of it. This is because modifying the position would clash with the knockback and moving systems already applied to the player.

This is the collide animation, played when the player hits a solid object (it lasts 0.2 seconds). I knew that I wanted to make the car lean backwards as if it's been snapped backwards. It took a few iterations to get it the way I wanted. The problem was that the initial rotation backwards was too slow. Making it only 2-3 animation frames causes it to look fast and snappy, just the way you want it. 

For the slowdown animation (0.15 seconds), the car leans forward as if its front wheels are going into a pothole. This one didn't take as much iteration as the previous animation as I learned from my mistakes. The lean forward is slow than hitting an object, since they are slowing down and falling into a pothole. This animation is less nessecary than the collide one since for hitting a pothole and slowing down, the impact is not as large. Although having it doesn't hurt, and it adds to the feel of the game.

Dev Diary - Barnstorming Remake: Interactions

A key component of Barnstorming is interacting with objects. Going through barns and colliding with obstacles is what the game is made up of. So in my remake, doing these things right was important.

Each interactable object (gas stations, potholes and fallen trees) has a trigger or collider, yet in the case of the gas station, three. The gas station has two seperate empty game objects attached to the model. One is for the solid obstacle colliders, and the other is for the passthrough trigger.

The "Collider" object has two box colliders which are for the building on the station and for the gas pumps. The "Passthrough" object has one box collider set as a trigger. The "Collider" colliders are tagged as "SolidObstical". While the "Passthrough" collider has a GasStationPassthrough script which checks for the player driving through.

This is the code above. It simply checks for the player (who is tagged as "Player") and then calls the onGasStationPassthrough event, which flips up the flag, plays the sfx, counts down the gas stations remaining and triggers the UI to pop.

Here is where most of the interactions get triggered from. It's attached to the player script and they are checking for two things. Objects tagged as "SolidObstical" and "NonSolidObstical". Solid obstacle are gas station colliders and fallen trees, while non solid obstacles are potholes.

If you go over a solid one, the player knocks back, the particle effect triggers, sound effect and animation are played. The camera shakes also. If you go over a non solid one, the car slows down and the slow down animation is played. You can read more about the knockback and slowdown systems here.

The farmhouse has another box collider on it, set as a trigger. The player doesn't manage this interaction, but the Farmhouse.cs script does (which is attached to the farmhouse). 

It's similar to the GasStationPassthrough.cs script, yet all it does is call the end game event, essentially ending the game.

Studio 1, Project 1 - Post Mortem

Overall, I was impressed with the final product. It lived up to my expectations, yet not without some flaws. One of them, was the structure of the level generator. For the three different levels, the procedure of generating the level was the same, with the only difference between the levels being the visuals. The placement of objects generated by the script, was not perfect. In fact, I wasn't that pleased with it. The script followed rules of how and when to place objects, yet many other rules that were needed weren't included. Potholes spawned inside of each other, in-front of gas stations and even in them. Gas stations followed a rule that no more than two of them can be spawned in a row, yet sometimes two would spawn then a gap, then another one. Sometimes even, gas stations wouldn't spawn for periods of fifteen seconds. Also, since it was procedural, there was not really a proper learning process for the player. There could have been an odd combination of logs and potholes which would have not been great for a first time player.

So how could this have been avoided? Well, the obvious answer is to better design the level generator, and yes, that would have probably fixed most of these problems. I had a function in place to check whether or not a pothole was in the position of an already existing one, yet it never really worked. Iterating upon that would have probably fixed the pothole inside pothole problem. In the case of them being in-front and inside gas stations, I could have made it so that if there was a gas station, potholes can only spawn on the opposite half of the road from the station. This way, going through a gas station wouldn't punish the player, yet missing one had the chance to. The placement of gas stations in a row was a problem that I believe is just due to the random number generator. I could have spent some time making a function that returns a random number that hasn't been used in like the past two iterations. This would make the game seem more random, while truly being less random. The learning process for the player is very important. I did have somewhat of a subtle, self-taught tutorial at the starting city tiles, yet when the game first truly begins, it is different every time. I could have had the first ten tiles or so for the three levels pre-made, so the introduction of fallen trees and potholes was natural and easy for the player to understand. Further additions and modifications to the level generator would indeed fix these problems. Yet it seems due to thinking over it or at many times dismissing it as un-important, eventually caused me to write this today. 

Now onto something that I liked quite a bit with the project. Not the 3D models, or particle effects - I did very much like them though, but the biggest shocker for me was the change in font. Before I was just using Unity's default Arial, white font. It didn't look good at all. I was going for a 1940's theme and the font made the game seem too "prototypy". So one day, I looked online and found a font called "Berlin Email." Adding this font to all the text elements and changing the colour to a white/beige/yellow colour made a large improvement. The next time I make any game, no matter the genre, setting, 2D or 3D, big or small, the font will be further forward than it was before. Because for me, what made this game seem less like a prototype, and more like an actual product, was the change in font. It also helped set the 1940's theme nicely, as the only other thing to give it away was the design of the car and the chance that the player even knew who Edward Hopper was. Spend time thinking about what era your game takes place in, or what era it's trying to emulate. Since players are always looking down at the font, putting into their minds the time period or feeling you want them to feel through the font can make a big impact.

Dev Diary - Barnstorming Remake: Teaching the Player

This Dev Diary will be less about the actual code or assets of the game and more about the design in terms of teaching the player how to play the game. There's not a lot of it though, yet there are 3 main systems that are taught to the player before they leave the city tiles. One of them is explicit and the other 2 are more subtle and might not be caught on by some players. These 3 systems are:

• Boosting.
• Gas Stations.
• Movement.

When the camera pans from the inside of the train to look out the window at the game space, the player is motionless, with this text in the middle of the screen. Pressing the spacebar starts the game, as well as momentarily boosting the player. They may feel it and decide to press it again later on to go faster.

Before the player can really move, they drive through a gas station, reducing one of their remaining gas stations. This is a very blatant way of teaching the player how gas stations work and the objective of the game, yet it is probably the best without having a text box on the screen.

Finally, as the player drives through the empty city for around 5 seconds, the empty road above and below them could indicate that they can move there. Pressing up to move upwards and pressing down to move downwards would be the most obvious way to do it. This could lead the players to indeed moving around, waiting for the game to truly begin.

So before the player even sees their first obstacle, they already know how gas stations work and probably have an understanding of boosting and movement. I could have had a popup screen displaying the controls and objective of the game. Yet with my method, it shows rather than tells. You can tell players all you want about how the game works, yet when they get in there for the first time, putting that theory into practice is not the same as learning it for yourself.

Dev Diary - Barnstorming Remake: Player Controller

Look at the way the car moves in the 2 gifs above. The first gets a direct input from the keyboard, getting a value or -1, 0 or 1. It applies that to the z velocity to create snappy movement. The second gif, shows using Input.GetAxis("Vertical") and applying that to the z velocity. This creates the sense that the car is heavy and takes time to build up speed.

I went with the first one though, because as much as anyone would like their games to feel "realistic", you need to decide what is best in creating the experience. Barnstorming is a fast paced, tactile, "arcade" game. Players need direct input on where they will move and when. 

Once the input is saved as a float, it calls the MoveVertically function. This takes that direction and applies it to the car's rigidbody. There are other ways movement could be done. Adding force is an option, yet it would be even more floaty than the 2nd gif up top. Altering the transform directly would be a faster way to do things, yet since we are using the physics system and colliding with things is an importand aspect of the game, we need to use a rigidbody function.

For accelerating and decelerating, the only input read is the spacebar. If it's pressed, then the Accelerate function is called. If it is released, then the Decelerate function is called.

All this does, is move the x velocity of the car up to the max speed or down to the min speed over the duration of timeToMaxSpeed or timeToMinspeed. I tried using Mathf.Lerp instead of Mathf.MoveTowards, yet lerping it would result in problems of the car not entirely reachig the max speed.

The most complex system in the player control is certainly the knockback. When the player collides with a solid obstacle, the Knockback function is called.

It first checks whether or not we are already being knocked back. If not, then we disable all control of the car and stop it from moving forward.

Then the coroutine KnockbackPush is called. This moves the car backwards until the distance between the car and the hit position exceeds the knockbackDistance.

Then after that is all done, we wait half a second before allowing the player to regain control of the car. This is so that the player can't move the car up and down while it's basically stationary. It looks weird and ruins the illusion that the car is actually moving.

When the car hits a pothole the Slowdown function gets called. All it does is first make sure that the car is not knocking back, before setting the horizontal velocity to close to 0. If this knockback check wasn't there, then if we were to slow down while knocking back, the car wouldn't move at all. It would be stuck.