Game Info:

NOTE: BONSAI' 98 is still heavily in development

My Contributions

Game Overview & Design

BONSAI '98 A cozy and relaxing sandbox game where you unless your inner creativity to grow and decorate your own dynamic bonsai dioramas the way you want!

Pivot

BONSAI' 98 initially started off as a vision to make a plant shop simulator. As it was just a two memeber team back then, Me & my friend Martin spent a lot of time ideating and designing how the core systemic design of our growth system would tie in well with rest of game mechanics. But due to an oversight on scope, the project underwent a complete transformation to become the sandbox it is today.

Design Pillars

Core Loop

Controls

Solution

Since the game was focused a lot around "Modelling" and setting up your own dioramas and actively editing your bonsai tree, we realized the answer to our controls were right there present in all the popular 3D Modelling software. So the controls were set up as follows:

Quests

Bonsai '98 is game that focuses a lot on the intrinsic motivations of the players. We believe that the players would really want to spend time working on their dioramas mainly because they enjoy the process and want to do it.But at the same time, it is our duty as the developers to motivate our players extrinsically and reinforce their actions through positive feedback loops. This is where the Quest System comes in.

Solution

The current Quest System keeps track of all player actions and based on what actions are present on the current active quests, if completed, the player is rewarded with a set experience points. A Data Table is used to write in all the quests.

Rewards

The player is rewarded EXP based on the completed quest, and once the player hits a target experience, you level up and are given rewards. The target experience is the reset based on a simple exponential progression curve.

Scraping

Scraping is a mechanic introduced to allow players to simulate deadwood bonsai techniques such as Jin (神) and Shari (舎利).This is achieved mainly by using multi layered materials. This allows you to then simply line trace to the required object and then draw onto the render target to shift between the different layers of the material.

Player Behvaiour and Design Change

While the intention for the mechanic was mainly as mentioned to simulate dead barks on your bonsai, during a playtest it was noticed that many players were having a lot of fun just drawing cute pixel art on the tree!One of our initial design pillar we were working with was "Embracing Mistakes", so when we first got the scraping system in, there was no way to redo or paint of bark you have scrapped off. But after gathering player feedback and responses, we decided in order to allow for creativity to flourish - we had to move away from the vision on Bonsai '98 being a simulation game and more of a sandbox. We even added an undo and redo button!This has been an extremely successful minor direction pivot and we have found our players spending a lot more time enjoying the process of making their bonsai

Future Plans

Scraping is a mechanic introduced to allow players to simulate deadwood bonsai techniques such as Jin (神) and Shari (舎利).This is achieved mainly by using multi layered materials. This allows you to then simply line trace to the required object and then draw onto the render target to shift between the different layers of the material.

Game Info:

My Contributions

Game Overview

In The Last Blue you play as a young girl who finds herself lost within an ancient shrine. Solve Puzzles, by learning a new language with the help of a friendly spirit and by observing the various murals that seems to hint at secrets of the shrine.

You might be wondering - "WAIT WHAT? LEARN A NEW LANGUAGE?"

Yep, we decided we wanted to make a whole new language system and teach it our players!

The Journal

As you can see in the core loop, the journal system is a major mechanic in the game that acts as the interface between the player and the overall game world, which is closely tied to the language itself.The journal acts as a dictionary and is what the player uses in order to keep track of the words they have mastered in the game.The players also uses the journal to solve puzzles, decipher mural meanings and also understand what the spirit is trying to communicate

In order to understand how the Journal functions, we have to dive a bit into the anatomy of the language itself.

Solution

Hence for the final design, while we kept the "Major Glyphs" - the ones that determined, whether something was a interrogative, declarative or imperative, the "Minor Glyphs" were restricted to just three - Nouns, Verbs and Adjectives

The design of the language itself shined only thanks to my amazing fellow designers: Thomas's linguistic expertise and Reyn's world building and narrative

Prototype and Iteration

During production, while the back end of journal data was being handled by our programmers, I quickly prototyped a journal interface where the player would be able to make use of the journal like a real world "pen and paper" and type in guesses for encountered glyphs.

Solution

So after play-testing, it was decided that we are going to handhold our players a bit more. The players will no longer be able to type in their own guesses, but instead they would be provided with options that they could choose from a drop down menu to try and guess the meaning of a word.When the right guesses are made for a full sentence, it is validated with a blue color and the individual words get their meanings filled in the dictionary section of the journal.While the validation and multiple choice solution did result in encouraging a more "brute force" style of play among some players, this did solve the major issue of the players not able to understand the narrative and interact better with the spirit companion. This was a setback we were willing to accept for an overall improved and refined experience.

The Journal Widget itself would handle the data from sentence guesser to display it for the players.The Journal is split into two sections:

To keep the journal modular, it was split into multiple smaller widgets which would then be added to the main journal widget.Each of the child widget would populate itself with data based on when the player interacts with a glyph they encounter in the world. Each time the journal updates, a UI pop up shows up to alert the player.

Since the journal itself had a lot of moving parts, this would have been impossible for me to design and implement without our programmers. Basil's robust back-end support, functionality and expertise and Markus's easy to implement designer friendly C++ solutions and data handling are what made this happen as well as it did.

The Spirit

Design

When researching the fundamentals of learning a new language we found out that probably some of the best ways to guide a player through this would be:

For the first point, we made use of Murals with glyph descriptions. The second point is where our Spirit AI comes into play. The Spirit is also a key part of the narrative. Afterall, the Last Blue is not focused on telling a story about the player character, but instead more about the Spirit and the Shrine.In order to make things easier for Rasmus, I mapped out all the functionalities of the Spirit and it's behaviour patterns as we progress throughout the game in accordance with the narrative

The State Change Tool

Solution

I made a simple trigger tool here that allowed us to quickly switch between the different behaviour tree actions and states of the Spirit AI while also controlling things like VFX and animations of the AI. Placing this out in the world allowed me to control the pace of the AI easily without having to mess with the C++ and Behaviour Tree set up by Rasmus

Spirit Speech

Solution

The Spirit speech was made so that it does not interfere with the flow of the game at all, but instead, the State Change Tool could be used to force the Spirit into a Speak mode which then brings the spirit to your proximity, display the glyph (which gets automatically registered into the journal along with a new entry prompt), and continue to it's next state. This allowed the player to spend some time in the journal to try and decipher what the spirit just talked about and not get trapped in a dailogue view with the spirit

Tutorial Tool

This was a really simple tool which our level designer Eddy could use to place out the different tutorial prompts that we needed to onboard the player to different mechanics of the game. Control over the text and prompt duration was given to the user of the tool.

Reflections

Game Info:

My Contributions

Game Overview

VAMPOWER is a survivor-like with tower defence elements, where you play as the lone underling of an evil vampire overlord as you fight off waves of heroes and local peasants as you try to protect your Master's HeartThe aim here was to make something with a satisfying progression and an addicting core loop

Design Pillars

Ideation Workshops

As the product owner of the project, other than just regular systems and tech, I was also tasked with conducting our ideation process - and this had to happen at a rapid pace since we were expected to produce three prototypes at the end of the two weeks with just half the team.

Fleshing it out

Now, that the main ideas were chosen, the designers focused on a more in-depth deep dive of answering certain questions about the game we were going to make. Going through these steps allowed all the designers on the team to be on the same page when it came to the core vision.We talked about moods and emotions, target audience, design goals, USP, risks and a simple game loop. The individual responsibilities for the prototyping phase were also decided here

Prototype to Production

Prototyping

Solution

Well easy, the solution was to prioritize the loop we wanted to test. We could have tested a simple progression prototype, but we knew survivor-like progression have been already tried and tested by a lot of games in this genre. But what we did not know is how the Tower Defence idea slapped onto a survivor like would-turn out.So that's what we did. We focused on the minute to minute gameplay loop and immediate player actions.

Prototype Task Split Up

For the prototype, I focused on making three different types of enemy AI based on what they would target. The targets were:

While the enemy did the same type of damage as the player and did not scale, this prototype still allowed us to test the overall viability of the project.

Moving to Production

Solution

The only way to deal with this was to plan and prepare a well structured documentation that dived deep into each of the systems, micro loops and flow of data that were needed. We had to co-ordinate closely with the programmers to make things easier for the both of us.We started out by mapping out inheritance structures, common stats and modifiers that will be used across the board.

Mapping out these important stats and how were going to use them were cruicial for all aspects of development of VAMPOWER. After all the numbers were going to decide exactly how fun the game is going to be.This was especially crucial for the Meta Progression systems - that is your "Master's Heart". We wanted the player being able to choose what type of modifiers their run must have based on The Master they decide to go with!

The Weapon System

Weapons are a major part of any Survivor-like game, so the decision to make it all auto-fire was a no brainier. We wanted the player to focus on just the movement and positioning to fight off the hordes.

Solution

The solution we decided on was to make all the weapons be child actor components within the player. This allowed us to focus all the functionality of the weapon within individual blueprint - and thereby allowed for easier allocation of responsibilities as well.

Weapon Communication

Design & Upgrades

Design

Splitting up the player classes into three, made it easier to ideate weapons under the same three categories: Melee, Ranged and AOE

Upgrades

Solution

What we decided to go with was a simple weapon stat based upgrade tree with each weapon having 5 levels of upgrades.While this did damage our player fantasy a bit of having unique and meaningful upgrades, it still allowed us to achieve a relatively strong power curve easily and focus on the uniqueness of individual weapons.

Damage Calculation

I made use of a simple damage calculation function that took into consideration the different stats and output the final damage.This was also set up in blueprint function library so that it can be called from any of the weapon directly. The best part? This same function was used by the enemies and ally structures and minions! We were able to do this as we planned ahead with the inheritance, data and stat flow between unit types

The Day Night Manager

Functionality

Solution

The technical solution used here was to have a blueprint actor that worked by itself to keep track of the day/night cycle, which day the game was on as well as work by itself as an event dispatcher to send out different events based on if it was day or night.This allowed for whatever systems that needed to make use of the phase of the game to subscribe to these events and then perform certain actions as and when it shifts between the day and night.

Framework

Night Phase (Prepare)

Day Phase (Attack)

Reflections