Samael Kärvemo

• Home

Traits

Deep-thinker: I carefully think things through when I do my tasks and aim for balancing efficacy with efficiency.Problem-solver: I like indulging myself in logical as well as philosophical thinking puzzles and find the best approach of solving problems.Realist: I strive to hold an objective view about most things as I know that feelings can easily cloud judgements.Team-player: When working in a team, it is important for me that everyone feels included and are feeling well. If tension exists I don't hesitate to clear it out.

Career

I am currently looking for paid work opportunities and flexible when it comes to location and working hours!These are the positions that interest me most:- Technical Designer
- Gameplay Scripter
- Gameplay Designer
- System DesignerHowever, I am open for other propositions as well.

Curriculum Vitae

References will be provided on request.

• Download

• Home

Contact

Feel free to contact me using the form below!

• Home

Thank you

I will get back to you as soon as possible.

• Okay

Trial of Odin

General

Links

• Itch.io
• Blogger
• Vimeo

Concept

Trial of Odin is a 3D puzzle game where you control a female seer known as a “Vala”. The Vala is equipped with a magic ability allowing her to put objects into stasis, causing them to float mid-air while being frozen in time. This is the core mechanic of the game and is key to solving all of the puzzles present in the game.

Background

This game was made as part of the educational program of PlaygroundSquad (A Higher Vocational Education), using the in-house engine known as Tengine, developed by Tension Graphics.We had a total of 9 weeks and were 11 students working on this project, with the addition of our sound and music team, which consisted of 2 people from a different institution.

My Role

My own role for this project was as a designer where I had the following tasks and responsibilities:- Level & Puzzle Design – Concepting of puzzles & level layouts as well as making blockouts in Maya.
- Scripting/Tweaking - Placing out game objects in the scene and tweaking values.
- Quality Assurance - Playtesting, feedback collecting and reporting of bugs.
- GDD - Designing the document layout as well as writing of detailed descriptions of mechanics and other technicalities relevant to the project.
- Project Management - Writing time estimates, moderation & booking of meetings, etc.
- Documentation - Creation of technical tutorials and various documents to improve the pipeline.

Challenges & Solutions

Challenges
**1. **The engine we used did not have any sort of interface that we designers could use to build up puzzles and make them work.
2. About half-way into the project we came to understand that we had over-scoped our project and needed to quickly downsize it.
**3. ** We noticed a pattern where implementation of tools and importing of levels was a recurring problem where people had to ask our programmers on how it was done.Solutions
1. Our programmers created a scripting tool that allowed us designers to create and place out puzzle elements in the game environment by editing an INI file. All game elements were implemented by defining the position and rotation of each object using this method.
2. We held a meeting where we discussed what could be done where we concluded to only keep 6 of the areas planned and thereby cutting the rest. In the end, we all felt that this was for the best and were happy with the fact that we had acted quickly.
**3. ** I made some technical breakdowns on issues such as: "How to import levels into Tengine" and "How to import and use Python scripts in Maya", and shared those with the team.

Playtesting

We held playtesting sessions with many people outside of our group in order to get as objective and constructive feedback as possible. Here are some of the feedback that was brought up and what we did with it:
1. “How does the player know what can get picked up?”
2. “Add indicator for when the [stasis] bubble is ready to get picked up.”
3.* “More clear UI (Aiming, Health, etc.)”*
4.* “Make the camera move a bit with the character depending on the direction they are moving.”*
5.* “Weird controls, can’t aim up/down, echoes problems of previous tester.”*
6.“You should be able to aim towards the direction where you are pointing the mouse.”
7.* “Hexagon Room: unforgiving, might get the player stuck!”*
8.* “Not obvious to player that the stasis can be broken mid-air while throwing.”*Here is what we decided after considering the problems above:
1. The rocks all look identical and are quite eye-catching, so staying consistent with those is enough to show the players that they can always pick those up. At certain points in the game, the player needs to pick up and throw enemies to progress. We want the players to draw that conclusion by themselves, instead of us telling them.2. We thought this was a good idea and was eventually added. You can read about how it works in the GDD: “8.1.3 Pick up Indicator”.3. We voiced this concern to our UI artists and after a few iterations, settled with something that was stylized, yet clear to the player.4. This was briefly considered but eventually scrapped due to time constraints.5. Our whole level is completely flat, there are no changes in elevation at all, which is why we did not feel the need to add the ability to aim upwards or downwards. That said, the controls are indeed ‘quirky’, there is no denying that. We always had this concern in mind but decided to go with it anyway. Given that this was a school project, we wanted to experiment by trying out new control schemes that felt different. Some players hated it, others loved it. It was nonetheless highly appreciated by our programmers, due to it being very easy to implement.6. We actually do not have a mouse cursor visible at all, which is why this comment is relevant. We tried a version of the game where the cursor was visible and it was horrible. The cursor was constantly in the way and/or could not always be found. It felt more like it would burden the player more than helping them. We took the less is more approach and hid the cursor and it undoubtedly meant less work but also provided a better playing experience to the player.7. We got this concern several times and it turns out to be a cursed problem in puzzle design. If the puzzle is too hard, players lose interest; if the puzzle is too easy, the puzzle feels pointless. This puzzle was neither easy nor hard, put no pressure on the player, could be completed with relatively few steps yet required careful logical thinking. That said, we had people that solved it in less than 30 seconds.There are a few possibilities why this was a problem only to some.
a) Some players are not that into puzzle games and wanted easy puzzles so that they could clear relatively fast.
b) The players felt pressured and/or distracted during playtesting and therefore avoided testing out possibilities and thinking out of the box.
c) The players wanted to avoid embarrassment for not completing the puzzle fast enough.There are a few other possibilities of course, but those were the ones I thought of a lot at the time. Our solution for this issue was to do nothing, since we thought it was a great puzzle that we were immensely proud of.8. We added this to the “How To Play” guide. Other ways of explaining this to the players was a bit too intrusive and/or time consuming so we settled with this solution. We also noticed that players often figured this out by themselves eventually.

Game Design Document

Writing the GDD was a joint responsibility shared between both designers. However, the layout and structure of the document was done by me and I also wrote the majority of the text body, about 75%.My goal was to create a source of relevant information for everyone in our group. Readability was especially important, since we had a lot of neurodivergent people in the group.I used colour coding to mark notes that were relevant for each role.
Programmers - Orange
Artists - Blue
Sound Designers - GreenEvery time text was added or changed, I used comments to highlight segments in yellow in the document. This way, everyone in our team knew were to read to always stay up-to-date.Click to see GDD

Gameplay Trailer

Watch gameplay trailer here >>

Up For It

General

Links

• Itch.io
• YouTube

Concept

Up For It is a 2.5D co-op platformer game featuring two complete levels, where the objective is to cooperate to reach the platform with the flag at the top-center of the screen. The catch is this: the players can only pick up and move blocks of the other player’s colour but only stand on blocks of the same colour as themselves.

Background

This game was made as the first major group project at FutureGames that was made in 4 weeks in Unity. Since we didn’t have a designated artist, we used pre-made assets that our school bought and went with a low-poly cartoony style that we thought captured the playfulness of the game concept. Our team consisted of 6 people.

My Role

My role for this project was primarily as a game designer, where my tasks included the following:- Gameplay Design & Prototyping - Iterated the design with the use of paper prototyping and continuous testing in Unity.
- GDD – Designing the document layout as well as writing of detailed descriptions of mechanics and other technicalities.
- Level Design (2nd Level) - Making of blockout as well as setdressing of second level.
- QA – Playtesting and bug reporting

Challenges & Solutions

Challenges
1. We quickly came up with a fitting concept that we thought would fulfill the criteria, but we were unsure whether it would be fun to play.
2. Our initial idea was yellow-lit and our teachers were sceptical to the concept at first, saying that the concept was a bit lacking.
3. As I was designing the second level, I got feedback that we should avoid having too much noise in the background since it detracts from the experience.
4. We had planned to make a visual timer in the background that would let our players know when they would lose by having a gradual change in the environment. For example, making the scene slowly turn dark or making a sun slowly setting. We eventually found it to be too involved and taking too much time to implement.Solutions
**1. **We tried out the game using paper prototyping, coming up with rules as we went on and it quickly became clear that the concept was solid.
2. We expanded on the idea further by highlighting the scalability of the game, presenting ideas that we could add to the game to make it even more exciting. Although, we unfortunately did not have time to add this into the final product.
3. I started thinking about having more of a clean layout and instead of a valley, ended up choosing a sea that stretched all the way to the horizon. In effect, I had to delete the valley structure that I had worked on for days, only keeping some minor details that was independent from the valley structure. I still wanted some sort of background, so I added some cliffs and islands in the background to make it more interesting. I often asked for feedback to make sure that I stayed on the right track.
4. We cut the timer completely and settled on the game over state simply being the stacking of shapes reaching the top of the screen. This saved us a lot of time as it was an easy fix for the programmers.

Game Design Document

Due to my past experience, I was put in charge of creating the layout and structure of the GDD document. I put considerable effort into making the document easy-to-read and easy to find relevant information quickly, especially for our programmers.The document was written in Microsoft Word, which was a first for me at the time. I ended up writing about 75% of the document.Click to see GDD

Gameplay Trailer

Watch the trailer here >>

Kathy Rain: Director's Cut

General

Links

• GOG.com
• Steam
• Globe
• YouTube

Concept

Kathy Rain: Director’s Cut is a remake of the critically acclaimed 2D point-and-click adventure game Kathy Rain (2016), where you follow Kathy, a reporter in-the-making who starts investigating the suspicious circumstances revolving the death of her grandfather. The remake now features expanded backgrounds, support for multiple widescreen formats, new and refined puzzles, soundtrack and even major expansions and alterations to the story.

Background

This game was a remake project of the original Kathy Rain (2016) that I worked on during my internship and temporary employment at Clifftop Games AB. The game was originally made in an older version of AGS, or "Adventure Game Studio", an open source IDE and engine used to make point-and-click adventure games with C++. The decision to port the game to Unity was made early and allowed us to greatly improve the overall pipeline and giving us the expandability we needed to more easily add features to the game and adapt it towards consoles as well as PC. We settled on using the tool-kit known as Adventure Creator for Unity, since it was known to be easy-to-use with most of the features we needed out of the box.

My Role

My role for this project was as a Gameplay Scripter where I had the following tasks and responsibilities:- QA – Playtesting & bug-finding/fixing, etc.
- Scripting – Implementation of characters, scenes, cutscenes, UI, puzzles, dialogue and other assets.
- Documentation/Reporting – Writing templates for working documents, reporting bugs, suggesting improvements, etc.
- Project Management (SCRUM) – Making regular time estimations and plan ahead to meet deadlines.

Challenges & Solutions

Challenges:
**1. **It was easy to overlook some aspects when implementing a new scene. For example, forgetting to add background music.
2. As we started to splice and edit some voice lines, we noticed that it became increasingly hard to keep track of them, and knowing which voice lines contained which dialogues.
**3. **We noticed that we ran into technical problems that was recurring.
4. We quickly learned that the built-in tool for creating animations was suboptimal and made it hard to preview animations.
5. It was very hard to tell the actionlist nodes apart from one another, due to them sharing the same bland grey colour.Solutions:
1. Since all scenes where implemented roughly the same way, I created a breakdown document that we could go through and then be certain that all aspects in each scene had been covered.
2. I made a document where I listed all of the sound files I had edited, how I edited it, the original file name and the new file name.
3. I wrote a document that I shared with the team and wrote down the known issues and how to avoid and/or solve them.
4. We bought PowerSprite Animator, a powerful but simple tool from the Unity Asset Store that allowed us to make sprite animations much quicker.
5. There was an option that allowed us to colour the nodes to our liking. We chose to do this for the most commonly used nodes:
Wait - Orange
Play Animation - Deep Blue
Stop Animation - Deep Red
Move To Point - Light Green
Play Dialogue - Cyan
Play Sound - Yellow
It made it much easier to work with as well as debugging.

ActionLists, the visual scripting solution used in Adventure Creator.

What I learned

During my time at Clifftop these are the areas I got better at and expanded my knowledge within:
- Adventure Creator, most notably the visual scripting tool: ActionLists, mainly used for creating cutscenes.
- Unity and C#, creating scripts for certain mini-games and other systems not supported in ActionLists.
- Debugging, making use of the debugging tools (such as breakpoints and watch values functions) in Visual Studio to locate bugs in the code.
- Jira Software, using the tool to quickly report, prioritise and estimate the time of issues. Also commenting on and updating issues owned by others in the team.
- Documentation, creating structured documents in order to improve the pipeline and more easily track changes not tracked with Jira.
- Perforce, our version control solution. Learning best practices for resolving conflicts as they emerge by using the accompanied tools.
- Feedback, giving detailed and constructive feedback on others work as well as suggesting improvements.
- Communication, upholding clear dialogue, mainly through text. This includes writing detailed reports on issues and improvements to the game.

Breakdown

Scene Implementation - I worked a lot with scene implementation, which included the following subtasks:
- Characters - Creating prefabs of characters placed in the current scene, while keeping it multi-purposed to be used in any subsequent scenes as well.
**- Cutscenes **- Scripted events that halts gameplay and is used to progress the story of the game, usually not triggered by the player directly. Animations, Movement, Dialogues and Sounds are usually the main components that make up a cutscene that is ordered and executed using ActionLists, AC's own visual scripting tool.
- Interactions - Same as cutscenes, but is usually triggered as a consequence by a certain action that the player made. For example, using a key on a lock.
- Navmeshes - Defining the walkable areas of the playable characters and also how the scale of the character changes.
- Music/Ambience - Implementing and playing the correct music tracks and ambience sounds. This is usually unique to each area.
- Conversations - Setting up dialogue for every topic and item presented to the characters in the scene.Animations - Animations also needed to be created inside Unity by first importing the sprites and then keyframing those sprites into an animation in the Unity format. To save time on this task, we bought a tool called PowerSprite Animator, which made it easier to preview and work with the animations.Localisation - Implemented fonts that included characters used in various languages, such as Polish, Russian, Portuguese, Chinese, etc.

Timing was an important factor when creating the cutscenes and making the characters walk, talk and trigger animations. I could mostly get the original delays and times directly from the AGS versions, but at times, this was not as obvious as finding it as a line in the code. Scene: Lakeside Cabin (Nightmare)

Trailer

Watch the trailer here >>

Astral Shift

General

Links

• Blogger
• Globe
• YouTube

Concept

Astral Shift is a 2.5D platformer game where you get to control a character equipped with the ability to pass through walls and obstacles. While inside a wall however, the character will not return to physical form until they have fully withdrawn from the object.

My Role

My role for this project was a lead designer, where my tasks included the following:- Gameplay Design – Initial Concept & Refinement.
- GDD Documentation – ~90% of the document.
- Level Design & Setdressing – Level 4, using Unity & Maya.
- Project Management – Setting up/Moderation of meetings, writing of miscellaneous working documents (Asset Breakdown, Variables, Bugs, Meeting notes, etc.)
- Quality Assurance – Playtesting, bug finding, reporting, feedback gathering

Level Design

I started working on a level in Unity by using the Probuilder plug-in while having the following goals in mind:Platformer puzzles that utilizes the core mechanic in various ways.
- A spiraling level design where the player starts in the middle and progresses outward.
- Giving a challenge to the player, more so than the levels before it.I then had this iteration process:1. Add new platform challenge, ending with a checkpoint (green area).
2. Test it, make changes until the experience feels consistent in terms of difficulty, length and space.
3. Let others play it and give feedback on the experience.
4. Make changes based on the feedback received.
5. Iterate!

Challenges & Solutions

Challenges:
1. As designers, we had no method to tweak values in the game.
2. It became apparent early that our pipeline was overly complicated and that it would take several weeks before we could implement all of the basic platforming mechanics into our game. This was mostly because of the limitations of the engine and partly because of the tools that came with the Devkit for the Playstation 4, that we were all new to.
3. We eventually ran into a problem where the Tengine exporter (used to export levels and models into a special Tengine format) failed to export our final level. This was caused by a memory cap that apparently even the developer was unaware of.Solutions:
1. Our programmers created a custom tool for us to use in-game to directly change out the values we wanted. We also created a dedicated document where we could request features from the programmers to add to it.
2. We created a prototype version in Unity that was fully playable after 3 days of programming, allowing us to test out gameplay and make early decisions about the design. In the end, the Unity version could only be used for prototyping due to various circumstances revolving the project.
3. We had to strip down the visuals as much as possible while still trying to retain a consistent level of detail throughout all of the levels.

Game Design Document

I was once again put in charge of the structure and layout of the GDD document and experimented with using a different font to make the reading experience more enjoyable for the team.I wrote about 80% of the text body.Click to see GDD

Gameplay Trailer

Watch the trailer here >>

Laborated

General

Links

• Blogger
• Globe

Concept

Laborated is a first-person stealth game where the player needs to navigate through an interconnected underground research facility in order to escape. The objective is to find specific objects that needs to be collected while at the same time avoiding getting spotted by guards.

Background

The game was made as part of the education at PlaygroundSquad (A Higher Vocational Education), located in Falun, Sweden. It was made using the in-house game engine known as Tengine, developed by Tension Graphics. We were 8 students working on this project, with the addition of one additional person from another institution, who provided us with appropriate sound effects and music.

My Role

My role for this project was as a game designer, where my tasks included the following:- Level Design - Construction of mockup level in Maya based on sketches.
- Project Management - Arrangement & Moderation of meetings, time estimations, creation and maintaining of various documents.
**- GDD Documentation **- Maintaining GDD and creation of document base structure.
- Quality Assurance - Playtesting and reporting of bugs.
- Gameplay Design - Improvement of mechanics through tweaking of values and playtesting.

Challenges & Solutions

Challenges:
1. As designers, we had no way of manipulating values in the game.
**2. **The concept started out as over-scoped given the time frame (5 weeks).
3. Module pieces did not line up or connect properly with each other in addition to obvious issues with material and textures not being displayed properly.
4. The pipeline was unnecessarily clunky due to the lack of supported features in the engine.Solutions:
**1. **Our programmers provided us with a simple tool where we could change values in the game by doing some light scripting inside a Json file.
2.1 We shaved down the concept as much as we could while still maintaining the core concept.
2.2 Focus was put on simplifying the AI as much as possible.
2.3 Simplifying and reducing the number of rooms and space covered in the level design.
**3. **We had to manually go through the level, repairing all clipping, hole and texture issues.
4. Our programmers developed tools that allowed us designers to manipulate values in-game in the form of .ini files.

Design Questions

Q: What was the core concept of the game?
A: We wanted to create a stealth game that involved avoiding NPC’s, exploration and elements of horror. It’s not that scary, though.Q: How do the guards work?
A: All guards follow a preset path that covers a certain area of the level that goes back and forth between two points indefinitely. The guards are equipped with flashlights, from which a cone of light is clearly visible. If the player character walks into this cone of light and stays within it for a certain amount of time, the guard will notice them and result in a game over. The guards will almost instantly turn towards the player whenever they cross their field of view or gets too close.Q: What is the objective(s) of the game?
A: Collect all of the items that are located throughout the level and escape through the exit.Q: Is there a story/theme?
A: Yes! In fact, there is a story that we had plans to explicitly tell, but due to time constraints, were not able to. In effect, the story is mainly told through hints in the environment. This is probably not enough to result in a coherent narrative that all players will catch up on, however. In short the story is about a small girl(13-16 y/o) who finds herself trapped in a research facility and decides to escape. But in fear of no one believing her, she decided to collect proof about the heinous experiments that scientists are conducting on children in the facility. When the game starts, she has already escaped her cell and the guards have already been called to find and capture her.Q: What is significant about the level design?
A: We wanted to create an interconnected level with as few dead-ends as possible. We always wanted the player to have an option on where to go without feeling discouraged. Even though the map is fairly small, it is fairly easy to get lost in since it is hard to know which rooms have been explored. To help with this, we added: signs displaying the level layout, the player’s current location and signs pointing towards the exit.

Game Design Document

The responsibility of the GDD was shared between both of the designers in our group as we cooperated to make the document as detailed and up to date as possible. It was the first time for both of us to write a comprehensive document for a bigger game project as well as to be read by a bigger group.We chose Google Docs because of its usability as well as neat features, such as commenting on certain text segments, which really helped us with correcting unwanted ambiguity and various readability issues.Some sections of the document has a breakdown below them that contains information only applicable to a specific role. We made this in the form of bullet points, for quick and easy digestion.I personally wrote about 60% of the entire text body.Click to see GDD

Eldritch Dungeon

General

Gameplay screenshot from late development. Still WIP with some placeholder art and minor bugs.

concept

Eldritch Dungeon is a 2.5D rogue-like deck builder game where the player is slowly driven insane, with devastating consequences.

Background

The game was made by 3 individuals studying Game & UX Design at Futuregames Skellefteå in northern Sweden. We simply wanted to make our own rogue-like deck builder game using the Unreal 5 engine. It was made specifically to highlight each of our own unique skillsets that we later could feature on our portfolios.The game is inspired by the likes of Slay the Spire and Darkest Dungeon.Third party assets we used for this project:
- Roguelike Deck Builder Toolkit created by Knut Overbye. Used to create core functionalities for our game.
- Midjourney, An AI that creates artwork using prompts. Mainly used for creating images for cards & characters, but was also used for inspiration.

My Role

My main role for this project was as a System Designer
- Scripting - Implementation of the Sanity system and number tweaking.
- System Design - Card balancing & synergies, concepting of sanity system and mechanics.
- GDD - Head of structure and content for our Game Design Document.
- Excel Worksheets - Creating a framework where we could quickly concept cards & Sanity values, change variables on-the-fly and import it to databases in Unreal.
- QA - Playtesting, reporting and fixing of bugs.
- Co-Playtest Host - Accompanying fellow game designer during playtests of our paper prototype playthroughs to lend additional support keeping track of numbers, explaining rules noting down feedback, etc.

Concepting/Paper Prototype

Even though we knew early that we wanted to make rogue-like deck builder, we were unsure of what direction we wanted to take it. Our first drafts consisted mostly of mind maps, post-it notes and moodboards and got more defined as we discussed and shared ideas with each other. Eventually, we created a paper prototype that allowed us to play the game, realise what made it fun and find out where things broke without having to start building on anything. This was essential, since we had not gotten access to the RLDB toolkit we needed to start building on the actual game.

Card List

We needed a place to store all the cards in one place and an easy way to create and iterate on them before we could start playtesting with them.I created our card list with a few goals in mind:1. It must be easy to distinguish cards from one another.
2. All team members must find it easy to create new cards following this format.
3. All team members must understand the effects of each cards with the information given and be able to implement it into the game.I then started the iteration process of just making small changes early, and then asking the rest of the team for feedback on it, making sure that I was heading for the correct direction very early on.Parallel to this, I concepted on cards that I successively added to the game using this format, which I also invited for feedback on. All the cards needed to fit our theme and feel we wanted the game to have.

Sanity Meter

The Sanity Meter was the one mechanic that separated our game from other roguelike deckbuilders and was also the mechanic/system I had sole (technical) responsibility for.The fundamentals of the system needed to be thoroughly thought through before we could start implementing it, since it would be difficult to change the foundations of the system later on during development.The fundamentals of the sanity meter was:
1. The player has a Sanity value that drains as they play.
2. The player will start as completely sane, giving them extra bonuses at the very start of the game.
3. As the value of Sanity decreases, various effects are added/subtracted while stats gets altered and difficulty increases.

Blueprints

As I earlier mentioned, the project was built using RLDB toolkit, which was a completely modular tool using only blueprints in Unreal. Instead of a documentation, video tutorials and a discord channel by the creator of the tool were the only source of support we had to work with, aside from the tool itself of course.To understand how it worked, the most effective method was mostly first to watch the tutorial videos available and then to start poking and experimenting directly with the blueprints using debug tools.A lot of time was put into reverse engineering blueprint code to get a good idea of how the framework actually worked under the hood and the best ways we could use it.I made it a personal habit to put comments where I had edited code in order to quicker get to the root of the problem for whenever it was time to debug it.

General Development

Eldritch Dungeon mid-development gameplay. The sanity meter value changes, which can be seen in the middle of the green bar and in the upper left corner of the screen.

GDD

I was indeed in charge of GDD structure and content once again, just like all my other projects. It is the most fun GDD I have ever worked on and looks pretty neat. However, it will be kept confidential until the project is completed.

What I Learned

Excel: I barely had any prior experience (aside from Google Spreadsheet) and had a lot of fun learning how it worked and what best ways I could use it. Making things readable and pretty was not easy, and even though I am not entirely pleased with it, I have become more accustomed using it.Unreal Engine 5: I learned a lot of new functions, tools and features that the engine has to offer and is honestly too many to count. Even though it is a lot more complicated than other engines, it has become a new favorite of mine.Personal: Taking care of your body and mental health trumps making the "best game ever made". If it means burning yourself out, it is never worth it.

Zoo'n Out

General

Links

• Itch.io
• Google Drive

Concept

Zoo'n Out is a 2v2 team racing game where players compete to get ahead on a relay obstacle course that provides points on each checkpoint reached.

Background

The game was made by 9 students: 6 from Game & UX Design, 2 from Project Management and 1 from the Mobile Platforms from FutureGames in Skellefteå. It was made as the second official game project of 7 weeks. This project was a bit special compared to the first game project where our mentors had made preparations to make the project simulate the conditions of working on an established game company with HR, marketing, development teams and a client with a vision for the project.

My Role

My role for this project was mainly as a game scripter and designer.
- Concepting - Sketching & concepting of possible levels, camera angles and gameplay.
- Scripting - Implementation of level mechanics (Spinning arm, moving platforms and buttons) as well as menus and HUD.
- Quality Assurance - Playtesting, reporting and fixing of bugs.
- Gameplay & Level Design - Improvement of mechanics through iterative testing and tweaking of values.

Process

My main focus during this project was to design and implement modular level mechanics and features that could work independently from the core mechanics. The mechanics could then be implemented in order of priority without becoming a blocker in the pipeline.I first started sketching on my own ideas in Miro, then opened up a discussion with the other designers about the implications of adding said feature, usually pros, cons, and ease of implementation. The more "puzzle-y" mechanics were inevitably scrapped, while the more casual and easy-to-implement mechanics were the ones favored which also ended up in the final product.See my horrible sketches in Miro below.

Challenges & Solutions

Challenges:
1. We did not want the game to be too punishing, thinking that it would be frustrating, even confusing in some cases for the the more inept players.
**2. **When we changed out the character models to proper ones instead of capsules, it was hard to distinguish which team one was part of.
3. Early on we had the vision of creating a puzzle platformer game where the two teams had to stop and solve a puzzle before getting the door to open. We had a few puzzles planned that we thought would fit rather well. However, this proposal was rejected by our client, saying that the racing aspect should be in prime focus.
**4. **We only had 1 dedicated programmer in our team, putting a lot of pressure onto them to get the game complete.Solutions:
1. For simplicity's sake we settled on not making any additional punishment for players that fell down the track. Instead, we designed the track in way that always allows players to get back up if they fall down.
2. We tinted the textures on two of the models blue and kept the orange-brown colour on the second team. People rarely had trouble telling them apart as the models themselves also had a certain body type that was easily distinguishable.
3. We had a discussion within the team to either scrap the idea or integrate it anyway as sort of a smaller add-on to the game. In the end though, it was apparent to us that we tried to shoe-horn it into our game and that it went against our client's wishes. We ultimately decided on scrapping them.
4. We had to make several compromises in order to lighten the load of our programmer in order to deliver the full experience asked by the client. We had some people in the team, including me, that did have technical experience and could help with some system implementations. We also downscoped the game as much as we could to make sure that we in the end would have everything needed for a product that met the client's needs and was a product we as a team could be proud of. In the end we did implement all of the mechanics we needed in addition to a few items from our wishlist.

Game Design Document

Since I had the most experience creating and writing GDDs in our team, I was put in charge of the document. I created the structure and colour coding with hopes of getting a minimalistic, easy-to-read document where it would be easy for everyone in our team to find the relevant information. My primary goal was to make it readable for those in the team so that we all know about what has been decided regarding the game design.We used Microsoft Word to write this document, since it was easier to share it between everyone in the team because everyone had gotten Office 365 accounts through the school. The prominent function of Word was that, just like Google Docs, you could comment on certain segments that needed discussion. This helped us quickly update the document without needing to spend too much time on each issue.I ended up writing about 80% of the final document body.Click to see GDD

Gameplay Trailer

Watch the trailer here >>

Vrock Racing

General

• YouTube

Concept

Vrock Racing is a dexterity-based racing game where the objective is to place first in a race against 7 other NPC. The race track is filled with obstacles that the player needs to dodge in order to keep up. For this, players have access to various maneuvers by which they control their ship. Namely: Levitation toggle, barrel roll and drifting.

Background

The game is set in the universe of the Swedish book series "Children of the Phoenix". Players race as Farei, an alien bird (known as a Vrock) who is native to the planet of Rikva, who also makes an appearance in the books.It was made by 10 students, 6 from FutureGames Skellefteå (Game & UX Design) and 4 from Visual Magic (VFX). It was made as the third official game project with a 6 weeks deadline.We also had the pleasure of meeting and holding a dialogue with the creators of the book series which helped us stay true to the source material.For this project, we used Unreal Engine 5 with the AG Racing Kit, which we used as a base for the game.For source control, we used Perforce.
For task tracking we used Trello.
For Brainstorming and Concepting we used Miro.
For communication we used Discord

My Role

My roles for this project was as a Product Owner and Technical Designer with the following responsibilities:
- Project Management: Holding daily standups, time planning and making sure that communication was upheld, especially cross discipline. Also keeping an overhead view and vision of the project overall.
- Scripting: Implementation of various features such as AI, player lap count & position, UI & Menus
- QA & Bug fixing: Playtesting, reporting and fixing of various technical bugs.
- Feedback: Giving detailed feedback to gameplay, art and UI.

Process

Since I was put in a management role for this project, I had my responsibilities split up into management and development.

Project Owner: As a project owner & manager, I was mostly in charge of communication between the art and design team, since we were in different classes and classrooms. I also got to onboard the artist from VM, where I showed them our first playable prototype and what our plans were for the project and what we expected from them.I set up a Trello board for everyone in the team to use, except for the artists, who wanted a board of their own since it would otherwise be too messy. My job was also to make sure that everyone was using the Trello and kept it as updated as possible to keep good track of our progress.I held in most daily standups where I also kept notes of points of importance that was brought up during this time. I was also aware to not keep the meetings too long to affect the hours spent on the project.Whenever there was doubt or ambiguity about something concerning the project that concerned art, then I would write it down in my notebook and make my way down to their classroom to discuss it. It was also to get better insight on the progress from their perspective and the problems they faced and to come to terms on ways to solve them.I felt it was important to have the exchange in person from time to time, since it is hard to gauge the full situation without all the context. I think this helped the development of the project in the end since the flow of information between the disciplines became more fluid and allowed us all to stay on the same page.

Technical Designer: As a technical designer, I was in charge of making sure that the systems for our minimum viable product worked as intended. These were some of the systems I ended up working on:7 AI-controlled racers: Even though the AI was advertised to work out of the box with a simple tweak of a number, it was not that simple. Due to an early decision to not use the built in spline system that controls a lot of the in-built systems, it needed a bit more tweaking and reverse engineering before actually getting it to work properly.AI Pathing: For the AI racers to know how to navigate the track correctly, a separate spline was set up that controlled how early they were suppose to turn in order to not touch the walls and lose speed. I soon noticed that fewer the nodes meant fewer turns, which in turn meant that the AI racers held their speed more consistently throughout the track.AI Obstacle Avoidance: Unlike most racing games, we had actual obstacles set up throughout the track, that were also modifiable in size and position. To solve this, I set up a simple system where the AI could use the same maneuvers that our player can. Some of which are barrel roll and levitation toggle. I simple set up a system that throws a line tracing straight forward that detects the object in front of it and determines the type of obstacle. If it is a pillar, it activate the barrel roll. If it is the default obstacle that afflicts a stun, activate the levitation toggle, or if a shield power up is available, activate the shield. It needed some tweaking to turn out the way we wanted, but the end result is highly satisfactory.Player Position Tracking & Lap Time: Another thing that needed fixing was the player position and lap time tracking. This seemed to be broken, even in the sample scene we got. It needed a lot of reverse engineering in the blueprints in order to work, but was mostly based on conversion and math errors that comes with float values. After some trial and error it was eventually resolved.

Game Design Document

We decided to use Microsoft Word for the hosting of the game design document, due to its ease-of-use tools and collaboration features.My contributions were mostly making fixes to the layout and filling in more details for all the mechanics. In the end contributing about 50% of the document body.Read the full GDD here >>

Gameplay Trailer

Watch the trailer here >>