Category: Game Design

Dr Strangelove or: How I learned to Playtest and Love Iteration

f590d454– A Post-Mortem

 

What went right

We made a game, and it was playable. I am honestly proud of this simple fact.

We used the MDA and achieved something adjacent to the aesthetic goals. We cut features in the concept document that would not have aided those goals, and in general had a consideration for the player. Our goals were;

  • feeling of being overwhelmed
  • Constantly in Danger
  • Pressured
  • Fear of a relentless pursuer

We made assets that were regarded positively. We had a very cohesive visual design that was rough around certain edges but in the end mostly worked out.

People seemed to enjoy the game, and I heard a lot of positive feedback from testers in different stages. The game never felt like a complete bore.

We made good use of user stories and we had clear ideas of what the game needed at various stages. We had mostly clear communication and workflow, with some kinks in the mix.

We took Playtest feedback seriously and made changes that took further steps towards the aesthetic goals. We kept consistent data from each playtest

I now feel comfortable navigating and exploring features in Unity, as well as implementing assets. Having one Programmer was an incentive for some of the team to get familiar with Unity. Me, Hampus (game design) and Wiktor(Programmer) became the Unity team, working in Unity Collab since it only allowed 3 people to share a project.

What we ended up with

We made a nail bitingly intense and difficult game where the goal of the player is to guide a submarine through a treacherous and dark 2D environment filled with narrow caves, spiky rocks and hostile fish, all the while being pursued by a giant and evil-looking creature from the depths. The player could shoot small torpedoes at the fish to kill them, and could use a rechargeable speed boost to move forward. The fish damaged the player if they came into contact, and also hindered the player from moving forward, thus aiding the large pursuing fish in catching up to the player. If the creature catches up it eats the player, resulting in instant death. Several checkpoints are strewn about the level, and the player could pick up health as well as a shield boost that would protect the player from damage for a limited time. The player always had to play through an easy tutorial level before being exposed to the real pursuer. If the player got to the end they were greeted by a victory screen.

What went wrong – and what we should have done

We could have done more game designing effort. Too many assets were imported in the game, implemented, and then tested until they fit the minimum criteria for being an asset. We could have done more experimenting early to get something excellent. I can think of plenty of features right now that would have deviated from the concept document, but increased the likelihood of reaching the aesthetic goals if tested.

Gif of the Game
Post-Alpha

More prototyping. Not just with software, but paper. Make something barely playable and test it. Make ugly art and spaghetti code and throw it away. I have come to learn that Unity is a good engine to prototype in and getting something playable and dirty up and running. Next time I’m getting my hands filthy.

We should have made more mistakes early and failed faster. This could apply to all of us. None of us have been in a similar production pipeline before, so coordinating what needed to be done and when was difficult. For the coder and artists to know that they don’t need art assets because Unity offers squares and shapes. Artists needed to realize that all art created early would be replaced no matter the amount of effort, so make trash before you make fidelity.

The artists of the group (Ellen and me) didn’t always have good ideas of how long individual art assets would take, and so would spend more (or less) time on certain aspects than necessary. These problems were evident on a few items of significant magnitude. This comes with experience, and isn’t something we could have done better at the time. But a good rule of thumb is; if you don’t know how to do something, double your time estimation. Sometimes you should add 25% for good measure. The product backlog exists for a reason; if you finish early you just keep working.

Current state of game Beta 2
Late Beta

We should be slaves to the aesthetic goals, not the mechanics. Don’t be afraid to change something that isn’t working, and examine critically why something is in the game. Does it adhere and add to the aesthetic goal? if not, you can cut it. If it does, make it do that, but even better.  At some point during development the submarine Player character was given 3 health as a placeholder. It was also decided and tested that the player should take damage when colliding with walls. The damage added to the feeling of being constantly in danger, pressured, but it negated the main enemy as the main source of death. This was amplified when the fish enemies also started dealing damage. This didn’t truly become a problem for the aesthetic goals until we changed the level design.

Since those decisions were made the level design had changed a lot due to playtesting and increased experience. The level became harder and more difficult to navigate, and player death was much more likely. We had made checkpoints because we knew the game was difficult and players would need to feel progress in order to stay with it. This was in the concept document, but didn’t really feed into the aesthetic goal. It was at this point (after alpha but before beta) that we became too rigid in certain designs that we had become accustomed to. We didn’t stop and critically examine the mechanics themselves, and rather tried to reinforce the aesthetic goals using the mechanics we already had. Putting mechanics on the chopping block didn’t occur to us in a meaningful enough way to voice those thoughts, as we all believed the game to be good where it was.

All-animationsWe could have doubled down on certain things that made the game engaging; the speedboost mechanic was implemented late in the cycle, but it became apparent to me that it was the main thing that made our movement engaging, and should have been emphasized more.

And finally; group dynamics. Making it clear early what is expected from members when it comes to commitment and engagement, distribution of work and similar. There are many things I could have done to ensure all members were on the same page and engaged with the project; encouraged learning and working in Unity, working in the same room, and making contributions feel meaningful. A better strategy for group coordination would go a long way.

Game Final2
Final

All of this is made possible because I have the luxury of not being in the workforce yet, I am a student. Having a minimum viable product is good but my main objective is knowledge and gaining skill.

I am here to learn, and the best way I learn is to do it wrong with the right intentions.

I count my failures as successes.

I hope these hurdles will aid me in failing faster in the future, because life is like a videogame. If there are obstacles in front of you, at least you know you’re going the right way.

 

-Benjamin Thomas Harbakk

 

P.s
Thanks Team Ettin for making this an enjoyable experience. I hope you fail quickly in your future endeavors. 😉

Advertisements

Using data to improve Gameplay

There have been two official playtests conducted at Uppsala University Campus Gotland for this course of Game Design 2. We have used these playtesting opportunities to great effect, and the tools that have aided us most is the fundamentals that we were taught early in the course. Using the MDA we have throughout the project tried to keep our eyes focused on our Aesthetic goals. These goals define the feelings and the experiences we want the player to have while playing our game.  For the project these goals have included:

  • feeling of being overwhelmed
  • Constantly in Danger
  • Pressured
  • Fear of a relentless pursuer

As described in the Concept Document authored by team Poltergeist. When the team has lost the way and has been struggling with how to balance the mechanics, we have always gone back to look at these aesthetic goals in the context of what the game was supposed to be.

During the play testing we collected data from the players describing their behavior during gameplay, as well as let them fill out a survey so they themselves could describe what they enjoyed or did not enjoy from the game.

Documentation Playtesting Alpha

These were the results we got from the Alpha survey. Most notably the feel of shooting the projectile has a low score, as well as the average for the monster pressure. This data told us that told us that there was something wrong with the balance of the game, and it wasn’t related to the gun feeling overpowered. Feedback and visual analysis of the game-play showed that many players found the level too easy. This was the opposite of what our Aesthetic goals were aiming for.

This was rectified in the next play test, where we exposed players to a more difficult level. We also made the movement of the Monster quicker, so that players rarely escaped it for long before it showed it’s head again, causing distress. We used the same questions to the last survey for certain aspects of the game we wanted to gather comparable data with, and saw a big increase in the feel of pressure from the monster. We tweaked the mechanics of both the monster and the level (in it’s design), we changed their dynamics with the player character, and in the end course-corrected to our desired gameplay aesthetic.

In the end we found a lot of the feedback valuable, and made several changes to the controls, movement, shooting mechanic as well as hitboxes based on the data collected. Playtesting for us has been key in the iterative process of making a quality product, and I doubt the game would be any good without it.

 

-Benjamin Thomas Harbakk

How to use the Animation tools in Unity

This week we were a little short on manpower since one of the members on the team is on vacation. My tasks were more focused on importing and implementing done assets into unity as well as doing animations using the animator, instead of making assets as I usually do. Thank goodness for Scrum am I right?

So here’s a workflow instructional guide on how to import sprites into unity.

The Basics

Pull sprite into unity

Drag and drop all your sprite sheets into the Unity folder of your choice. Try to have a logical sorting method, your programmer (and your future self) will love you for it. You see me dropping the sprite sheet of the protagonist into the “PowerUps” folder. This is a no-go

 

Change Image settings

Select all the spritesheets and (if making pixelart)
Set the Pixels Per Unit to match your desired camera distance.
Set the Filter type to “Point (No filter)
Set the image type to “multiple” instead of “single”. The filter and Pixels Per Unit options are required to have a nice pixelart look, while messing around more with the options is up to you. “Multiple” determines if you want to use the image as a spritesheet or not.

 

 

 

Open each spritesheet in the unity Sprite EditorSlice It

Slice them up using the dimensions provided by your artist, or divide the full image dimensions by the number of sprites per row or column. Hopefully your artist has made the spritesheet using reasonably divisible numbers. This process can be done even faster if the sprite sheets are using the same dimensions as each other, as the slicer remembers the last dimensions used. Small time-saves add up to a lot.

Drag the spritesheets into the scene of your choice and save the animations in your asset folder. Congratulations! You now have an animation in Unity!Move it into scene

Advanced

you can adjust the timing of each animation using the Animation panel (Window>Animation (ctrl+6)). You can see the Animation panel in the upper right in the above Gif. There you can adjust the framerate, as well as add events to specific frames. What this means is you can time certain events to the framerate of the animation, like spawning a projectile or turning on a light:

Rotation powerup light.gif

 

On this asset there is a point light which only activates on the frames where the lamps on the side are “lit”. You can use these “events” in the animation to do a lot of things, and is one of the strongest features of the Animation panel.

Each animation you create has a “Controller”. A controller is like a state machine  You usually only need one per asset or entity, since you use it to control what states dictate a change in animation. If you have several for one object because you imported several sprite sheets for the same object, feel free to delete them.

All this has culminated in these assets finally being imported into unity. The fish is curtesy of Ellen Wetterholm.

Thanks for reading!

 

-Benjamin Thomas Harbakk

Scrum in team Ettin

How a Scrum Works

This is to make the un-initiated understand the basics of what Scrum is, and how it can be used as a framework. Feel free to skip if you understand Scrum.

The basic principles of Scrum is to work in an iterative environment consisting of small teams that self-organize tasks that need to be performed in order to ship a product. Some roles in the team are:

Product Owner– The person or entity the team is working for, and determines the overall priority of features and their order of implementation. The product owner is the one who sets out the requirements for the project. For our purposes, the Product Owner role is a combination of the faculty responsible for Game Design 2, and the Project Manager.

Scrum Master – Facilitates communication between the Product Owner and the team, and ensures that critical meetings can occur. Irons out any hiccups in the production pipeline, keep the team up to date and improve their productivity in whatever way possible. Is the keeper of the “Scrum Bible” and is there to answer any questions and make sure Scrum is utilized to it’s fullest potential.

 

What is essential for Scrum?

Product Backlog – detailed list of features, assets and artifacts that are planned for the product, with varying levels of priority.

Sprints – 1 or 2 week periods that start on Monday and end on Friday, where work is done on small contained parts of the product, planned in the Sprint Planning meeting and reviewed on the Sprint Review meeting, on Monday and Friday respectively.

Sprint Planning – Plan out and allocate time for tasks that need to be done for the current sprint. Each member takes on tasks that they feel they can perform, and estimates the amount of time they expect to be able to put into that task. A Quality Assurance reviewer is assigned to each task, to aid in keeping the task do-er accountable.

Sprint Review – The estimated time for each task is reviewed and evaluated. How well the feature is implemented and notes for what worked and didn’t work are noted down.

Daily Stand Up – Quick 10-15 minute meetings that occurs every workday where the members can share what they worked on since last stand up meeting, and what they will work on next.

Minimum Viable Product– The idea that most steps, assets and parts of the project will contribute to a minimum viable product for shipping. We are not building a car over 12 months by painstakingly crafting every mechanical metal part and putting them together at the end. We are putting a stick between two wheels and adding bits and bobs until it’s safe enough to stand on, and build from there. Iteration is the name of the game.

What benefits have we experienced?

Gif of the Game.gif

What I deem the most valuable aspect of Scrum is that it empowers the individuals in a team to find work they would like to do. Most work is “grabbed” by the individual who wants it, and in most likelihood the person most capable to complete the task. The process is more satisfying than to be assigned a task, even though that might happen to tasks that no members want to tackle every now and then. Overall it leads to a more gratifying workload where you work on things that you feel a slight excitement for, most of the time.

It rewards strong willed and motivated people with a good sense of progression and development. If using good documentation it’s easy to see how much work has been put into the project, and get a sense of satisfaction. In our project specifically I have been very happy to be able to test out my assets through every step of the way and detect problems early in the process. From this I have had enough time to change the work pipeline to prevent a lot of work from being wasted. These changes include:

30x30 and 60x60

  • Size of the Player Character  compared to other objects
  • Size of Tiles
  • Types of Tiles that need to be created
  • Size of the Big Enemy
  • Distance of camera from play-area
  • Visual design of certain objects (Testers pointed out the Shield Pickup looks like a mine)
Powerup-v1
Early Shield powerup.

These changes are especially important to me as an Artist, since re-scaling assets is tricky and doesn’t work for Pixel-art most of the time, and re-drawing high detailed art leads to a lot of wasted time. Through iterative development most of these issues were discovered organically, using low-effort art assets. But development is more than just art, and we also worked on these issues:

small gif of shooting

  • Constant change of player movement mechanics
  • Focus (or non-focus) on lighting for game-play mechanics
  • Mechanics of aiming and shooting

Through iterative development where we could constantly test these aspects of the game, problems would be discovered and eventually resolved throughout the process. This might have saved us from many hours of wasted work, or work being put into a faulty product.

So what’s the Verdict?

One of the biggest strength and weakness of the framework is that it puts a lot of trust on the individuals to find and do work. Sometimes people do not feel confident enough in their own ability to tackle a problem, and tasks that are within their skills fall to other members who might be better suited to handle other problems. A well functioning team can compensate and make sure that everyone does tasks that are suitable for them, but this can sometimes be tricky.

Scrum works best in a team of self-motivating, closely knit and interdependent teammates that hold each other accountable and are excited about the project. Individual work is highly valued and easy to see, and feeds back into the motivational aspect of wanting to do work for the group. Quick feedback loops and visible progression, both in the moment and over time strengthen the feeling of cooperation towards a common goal. It is a valuable tool, but it can be abused intentionally and accidentally.

-Benjamin Thomas Harbakk

 

EDIT: Here is the Comment I made for this week’s assignment

Pixel Perfect in Unity

Artefacts-and-other-issues

This week has been a adventure in Pixel Graphic Minutia behavior in Unity. I made some animations for the protagonist for our game, and wanted to test them out in Unity, to make sure everything was appearing and behaving as expected. This is when I saw it; the visual bug.

There are clear black lines of pixels showing up in certain frames of the animation. What makes it worse, is that it is inconsistent in that it doesn’t always appear on the same frames. In addition, the pixel outlines of the sprite itself sometimes gain thickness in certain frames. This is especially visible on the engine behind the sub.

 

Up and down animation sub
There were no artifacts visible in the PNG of the spritemap, and the line thickness of the black outline is mostly consistent in the frames

What gives?

This thing became an obsession, since it was making every animation put into unity look amateurish and dirty. What was causing it? I started troubleshooting, thinking that both of these symptoms were the same issue.

Searching online for keywords like “Unity, black, pixels, animation, frame, artifacts, outline, thickness” in different combinations.

Since the the outline was inconsistently bad, I tested these theories

  • The sprite moving over the background was to blame
  • The lighting we used was causing some issues
  • The sprite location on the z axis compared to other objects was causing it
  • The “object” of the player had a bigger hitbox/rigidbody than the animatio

None of them proved to be the problem. I eventually figured out the outline issue is a bug in Unity, and made a workaround;

Outer Frame Sprites

The “slice” tool for sprite sheets in unity was randomly picking up stray pixels from the image above or below the frame of the animation. This was not a mistake on my part; all the sprite frame borders were clean. My sollution was to increase the distance between the frames in the sprite sheet by 1 pixel each (resulting in a 2 pixel increase between frames). This would become a lot of wasted data in a bigger game, but the workaround is functional for the scope of the project.

Protagonist-sub-boost-fixed

Sprite line thickness

This problem was bigger in scope.

Here’s a simple way to put it: Imagine you are Playing a game like The Witness. You are looking at a painting on the wall in-game. If you stand close to it, the “Puzzle Tile” will take up X am amount of pixels on the screen. The “Puzzle Tile” has dimensions of 840×420, but where you stand it only takes up 420×210 pixels on-screen. This seems self-explanatory, but it was hard to understand in a 2d world where the camera is orthographic. It applies to Unity orthographic camera as well.

Gif-of-camera-thing

Why does that matter?

In Unity you can decide where the camera is supposed to be, and define it’s position on the Z Axis. This will effect how big your sprites and assets will appear on-screen, and isn’t that visibly distinct unless you’re making pixel art. When using pixel sprites every pixel counts, and if the camera is a certain distance away from the screen it will not display correctly. What happens is that that your display will try to “fill out” the gaps where pixels should or shouldn’t exist, causing inconsistent animations and “pulled” pixels. To properly display pixel art, you need to calculate how many pixels should be in one “unity Unit” based on the Orthographic camera position and the vertical display resolution. My equation was simply;

Pixels per Unit= Vertical screen resolution / (2 * Orthographic camera position)

or

1080 / 10 = 108

Which means that my “pixels per Unit” for every art asset put into unity should be 108 to be properly displayed at 100% resolution compared to camera placement.

After putting in the fix, I got this result:

Sollution-to-artefacts
Lower image is before fix, and is still having pixel-bugs in the frame, while upper image has the fix applied with no visual bugs in the outer frames or increasing line thickness in the animation.

-Benjamin Thomas Harbakk

 

EDIT: Here’s my Comment for this week’s assignment

Pixel art and pre-production

The game development team Ettin (which I am a part of) decided to make a game based on the concept document from the team Poltergeist.

Depth first tileset
Temporary Sprite tile experiments

The concept is called “Depth”, and the core tenants of the project feature a giant fish creature chasing a submarine through underwater caverns.

The Lead Artist and me quickly decided that we wanted to make the game using Pixel-art. It was a realm we both had little experience, and were eager to learn more about. This is what I learned from my first week of working with pixels for the project.

Planning is Everything

When working with pixelart it’s important to consider a few things;

  1. What is the resolution of the screen the art will be viewed on?

    This becomes a big part of what style you might achieve. Do you want your game to look retro, and what kind of retro in that case? There is a distinct difference between pixel graphics for the Atari 2600 (typically 192×160 with a limited color spectrum) and the Super Nintendo (with screen resolutions from 256×224 – 512×448, and sprites being up to 64×64 in size). Decide this early!

    For simplicity we decided that our resolution would be 1920×1080. We started working on test-sprites in native resolution. We quickly discovered that this gave the sprites a vector-line feel. This makes sense, since each pixel is literally 1 pixel on the screen as-is. To fix this, we decided to make art assets in a certain resolution, then chose a value to upscale it with. Depending on the look we wanted, the original resolution would differ.  On the left below is a tile made in 30×30 upscaled to 120×120, and on the right is a tile made in 120×120. We wanted something in-between this, and eventually settled on making art for a 960×540 display, which means we would upscale every asset created by 200%.

    30x30 and 60x60
    Left- Upscaled 30×30
    Right – Native 120×120
  2. What is the size of the Player Character and the enemies?

    One cannot start making assets before this becomes clear. The size of the hero comparatively to the enemy and the environment has a big impact on Gameplay. I recommend only having temporary assets in the game until this is determined. We had to do tests and mock ups to tackle this aspect. You can see one of those mock ups below, courtesy of Hampus Serrestam, our Game Designer;

Depth Interface Mockup

This mock up was made with Paint, in 1920×1080. The Lead Artist (Ellen Wetterholm) and me then measured the different sizes of these cubes to use as the baseline for the assets. Of course, almost none of them have stayed the same throughout the process. Luckily we haven’t wasted much work, due to being hesitant to work on uncertain aspects of the game, and instead work on things that we had a bigger degree of certainty. The submarine has been resized 3 times since the start of the project. If animations and sprites were made for it before these changes, tens of hours of work would be wasted. Playtesting these aspects before committing to sizes was of utmost importance.

3. Why make the game with pixel art?

For us there were several aspects;
Consistency – If the two artists on the project are working with the same constraints and art limitations, the end result will have a better cohesiveness. Of course, we aren’t working with SNES era color limitations, or the same limit to sprite usage, but the message still holds true.

Artistic look – We both agreed that we wanted the game to have a retro feel and look, and not look like a game made in Flash. Not because those games are worse, but they have a certain feeling we wanted to avoid. This is a good example of what I’m talking about;

Tempala

Learning Outcomes – I believe that there is a lot I can learn about making good art assets, color theory and abstraction by making pixel art. Pixel art is about squeezing as much meaning and detail from small squares on a screen as you possibly can, letting the brain of the player fill in the gaps you left to be filled in. It’s about tricking the observer to see more than there actually is, by implying detail. It’s a lot like traditional  painting in that way.

In the end I simply enjoy the medium and even though it is a common one in the Indie scene, it will set our game apart from other students’ versions of the same concept. Though it has some hurdles that might need addressing in a future blog post.

-Benjamin Thomas Harbakk Signing out

 

Edit: Here is the Comment I made for this week’s assignment