Category: Game Development

Posts relating to game development, from work in progress project to tutorials and demos.

Refactors Galore

by Jonathan Carterin Blog, Game Development, Progress UpdateLeave a Comment on Refactors Galore

Refactors Galore

Its been a few months since my last update on the project. So here’s an update on the progress so far.

The Refactoring

Moves

Before this refactor I had the 1 move implemented in a way. That being the persona attack skill use ability. When attempting to implement the guard move for a party member I found that the old implementation was far too limiting. So I refactored it. The new setup uses an interface for the logic shared between each move and a class implementation of every move the user can have. I managed to refactor the move I had before in to this new setup and implement a guard move without any issues which was good. Since then I’ve started implementing other moves such as the support skills. 

using CarterGames.Common.Events;

namespace Gameplay.Actions
{
    /// <summary>
    /// Implement to make a new move in the game for a party member or enemy to use.
    /// </summary>
    public interface IGameMove
    {
        /* ————————————————————————————————————————————————————————————————————————————
        |   Properties
        ———————————————————————————————————————————————————————————————————————————— */
        
        /// <summary>
        /// The type of action the move is.
        /// </summary>
        GameMoveType ActionType { get; }
        
        
        /// <summary>
        /// Raises when the move is completed.
        /// </summary>
        Evt MoveCompleted { get; set; }
        
        
        /// <summary>
        /// Any ctx for the move to use.
        /// </summary>
        object ActionCtxData { get; set; }
        
        /* ————————————————————————————————————————————————————————————————————————————
        |   Methods
        ———————————————————————————————————————————————————————————————————————————— */
        
        /// <summary>
        /// Performs the move when called.
        /// </summary>
        void PerformMove();
        
        
        /// <summary>
        /// Resets the move when called.
        /// </summary>
        void ResetMove();
    }
}

Slot Navigation

While its still not fully complete, I’ve also refactored the slot navigation system to be more flexible that it was. Beforehand it was a bit of a mess with the whole wildcard solution, honestly it was a bit over-engineered. With this refactor the system is much better, but while writing this post I noticed some bugs with the wild option, so there is still some work to do there.I was also able to use this system in the persona skill select display as well. Before I as using a different setup for that which felt a bit dumb.

Minor Bits

Some extra refactors, not full systems but some improvement include:

  • Target Manager > Sorted the resetting when selecting skills, as skills like support skills can target the party instead of enemies.
  • Turn Manager > Updated the turn manager to track complete turns and the ability to loop around to the start again.

Party Buffs

In Persona you can buff or debuff combatants in Critical chance, Attack/Defense/Agiligy & reflection walls to repel single attacks. I wrote a system to support this on combatants in the last month. The system took a bit of time to implement properly but I was able to get it working eventually. I also sorted the UI for the setup which appears over the combatant when they have any buff or debuff applied. These buffs are also set to only last a number of turns and will expire on the turn when there are no uses left.

And yea, there are some UI bugs and missing art on the character stats now…. Lots of little bits to fix 🙂

Project Cleanup

Behind the scenes I’ve also been doing a lot of cleaning up. There were a lot of prefabs and old art in the project that wasn’t being used anymore. I managed to clear up all the old prefabs and improve the structure so there is a prefab for the model as is for menu’s etc. While the other is for the actual persona model for the game scene when summoning the persona.

I also renamed all the assets to match a naming convention I use a work which is mostly for the art side but with some extra conventions for prefabs and scenes. The convention below if you’re interested:

That’s about all the big news I have for now. I’ll still be working away at this project when I get the time. But I am taking at-least 1 day off a week to just chill and do nothing game dev related. With an extra day off for the rest of the year more or less I’ll be taking that fully. I’ve been slowly getting through Person 4 Golden on those days so far, been good fun. Held off on Persona 3 Portable once Persona 3 Reload was annouced officially as that’ll be much more engaging to play when it comes out next year. Its looking awesome so far, really looking forward to playing it on release day, may even take a day off to play it xD

Early Combat Setup & Party Members

by Jonathan Carterin Blog, Game Development, Progress UpdateLeave a Comment on Early Combat Setup & Party Members

Early Combat Setup & Party Members

There’s been a lot of progress since the last update I made so I felt like it was about time to post another update. While the actual combat is still on-going all the logic up until the point of actually doing the damage to the enemy/enemies is all set at this point which is great. A summary of all the new stuff since the last update:

Party Members

The player can normally have up to 3 additional characters with them in a battle. I’ve started the structure this month with party member & party member manager classes. The party member implements the ICombatant interface that I use to define a fighter in the battle. The ICombatant stores stuff like the character data & persona held for each party member with a setup to allow the wildcard player to switch persona held. Below is the current class for that, but I imagine it’ll have extra properties in the future:

using Data.Personas;
using Gameplay.Characters;
using UnityEngine;

namespace Gameplay.Combat
{
    public interface ICombatant
    {
        string Name { get; }
        bool IsEnemy { get; }
        GameObject Obj { get; }
        PersonaData Persona { get; }
        CombatantStats Stats { get; set; }
    }
}

I’ve also been working on some more models for the characters. For the party members etc, I’ve decided to make my own instead of copying any from P5R. I’ve also decided at the same time to allow the user to choose between a male or female protagonist. I’ve started the setup of the velvet room scene to accommodate this. The UI is placeholder here for now, but it is all functional at setting the value in the save data for the player selection. I’m hoping to have animated characters in the windows when you change your selection over each of them as well as a name & description of the character.

I’ve still got to define some of the characters and I’ve only got a few made so far, so I’ll be making more over the coming months. The data for the characters is still a bit work in progress:

The last main bit I’ve sorted for the party members is the UI for the party stats. This was pretty straight forward to setup with the existing setup. I also added the smaller UI for the inactive party members as well as the animated stat visuals when hovering over skills in the persona skill select screen. The portraits for the characters are the only thing left to do here as and when I get around to making them.

Combat

While I’ve yet to do damage, its all set now to use an ability. I’ve got the data for the damage, hit + the weakness checks and even spawning particles for each effect. I had to do a fair bit of work in the backend to allow the user to select all enemies or just one based on the skill selected. The UI is also now pooled to allow for re-using of elements, though the heart UI is still a little bit off, so that’ll be worked on at some point.

When you use a skill, the UI updates to show the skill name used for a few seconds before hiding. If the skill is just one target it’ll play on the one you’ve targeted while multi hit skills are currently slightly staggered like they are in P5R. I know some skills hit all at the same time but that’ll be easy to update as and when. I’ve also sorted to removing of Hp/Sp for using a move. You’ll note there a drastic difference between the two screenshots around this paragraph. That’s a bug I’ve nto gotten around to yet, but the player’s starting health is 100 and I’d used a few skills to test before so it was on 90 before using Giant Slice which take 9hp off 100 Hp base (9%) resulting in the 81 remaining.

I also updated the enemies & battle system managers. The turn manager now correctly determines the right player party member to start the fight based on their persona’s agility level. The party manager allows the active data to be received from the turn manager instead from a static class like it was before and the enemy spawner now spawns into slots based on the number of enemies in the wave. This has been set to a max of 5 currently like in P5R.

Minor Bits

Other than that, I’ve been working on a lot of minor bits which I’ll list out below:

Control UI

As you’ll have seen in some of the screenshots already, I’ve setup a controls system for the game. This translates any control I’ve setup based on the active input device. So if I were to connect a PlayStation or Xbox controller, the UI would update to show the controls for that scheme. I’ve yet to add the controls to every screen, but it is all working and pretty each to add where needed. Even the root options screen uses it now.

Skill Weak/Technical Text

There’s now a UI element for when a skill will hit & Weakness or Technical hit any enemy.

View Persona UI

I’ve upped the colours a tad as they were a bit dull. Though I’ve still got to fix a few bugs with it, the display for level and xp being one and the other being the obvious model scale issue.

Backend

  • Player held persona’s now use a variant of persona data that is saveable. Before I was using a direct reference to a scriptable object. But that kept breaking between sessions. So there’s now a variant with implicit operators to convert between the two versions.
  • Minor bug fixes to sheet downloading & persona skill custom editors so they show cost again. Also fixed the instant kill display to only show one set of costs for the skill.
  • Imported a lot of old models from game jams and other projects to use as persona’s in the future.
  • Started work on a new persona data maker to aid with making persona’s as the sheet is a bit of a pain to handle when it comes to this. We’ll see which workflow works out best as and when.

That’s it for this update, but lots of progress which I’m pretty happy with, hopefully I can keep this up going forward with more combat stuff in June/July. See you all in the next update.

View Display & Fixes

by Jonathan Carterin Blog, Game Development, Progress UpdateLeave a Comment on View Display & Fixes

View Display & Fixes

Another month has passed since the last update, and I’ve been mostly focusing on the UI displays and fixing a few bugs as well as some general organisation. I haven’t been able to dedicate much time to the project for the last few weeks, as I had the Save Manager to finish up for Carter Games by the end of April.

Preview

Below is a short video of the current progress made on the project as of writing:

View persona UI

The UI hasn’t changed much on the front-end, but behind the scenes a lot had gone on. I’ve spent the time to improve the UI Polygon setup that I’m using for the odd shapes in the UI. The new setup lets me drag points in the editor space and the graphic is then drawn using those points. I’ve also made it so this updates in edit mode so it’s easier to visualize. The upside being it’s easier to edit and less buggy. But I still need to do a little bit more to it. As it currently doesn’t scale with the bounds (width/height) of the graphic.

A screenshot of the unity editor with a element of the persona UI selected showing 4 points highlighted as gizmo's

With this new UI polygon setup I remade the UI for the skill strengths & weaknesses. Mainly to have the extra length for the text. I couldn’t quite match the text perfectly with Persona 5’s text as the font has a few layers to it. That and I couldn’t find a font close enough to match it, so I went with the readable option. This turned out okay and I refactored the display code to toggle the sections correctly when needed.

A screenshot of the view persona display with a skill highlighted.

The next new part was the navigation of the UI. In Persona 5 you can inspect each skill and move around the slots for each persona. This wasn’t the easiest system to code despite it being simple in theory. I ended up with a data structure that split the slots in the columns with an option for wildcard slots that could be accessed from specific slots. I reused the old selection UI from the skills select screen and refactored it to allow for 4-directional blue backgrounds. This was done so as in the game you would see this highlight in the direction you were navigating in.

With this I also implemented the inspect display which I had already laid out to show the skill in more detail. This display updates as you move around the skills and hides is no skill is currently being hovered over. Some of the more general fixes such as toggling user input listeners at the right times were also adjusted. As some of them were listening on start instead of when the screen was opened.

Another notable change is the model preview. While it is still early days, I was able to get the model to spawn in and rotate with user input. The model is stored in a new model system that replaces the old one I had from the 1st day of working on the project. The main upside of the new setup is that I can easily get & re-use models without spawning them all in on start.

The final main change is the ability to switch personas. Using the newly released Save manager 2.x I was able to make a save object for the held persona’s the player has. Currently this is the container class but down the line it will be the raw data for each persona. There is still a lot to do with this system as is, but the ability to switch between all held and select a different persona is now possible which is the key thing.

General organisation

The only other progress of note is a major clean-up of old code. While a lot of the code base is still scrappy and a bit messy, I have spent the time to remove scripts that I want to re-do or are for systems I’ve yet to actually focus on. Structurally the code is split into categories based on what it is about. So, data structures or scriptable objects are in a “Data” folder. While general systems, gameplay specific systems & UI all have their own folders. Inside these folders I have the code split by mechanic. Namespaces wise they all now use the base folder which does name more namespaces, but a more structured setup which I like, for now.

Closing thoughts

Given this has only been a small amount of progress, I’m still happy with it so far. I’m hoping in the coming months to be able to get into some of the gameplay. Implementing the enemies, moves & actual combat. So hopefully more exciting stuff to come! I’d expect the next update in about a months’ time.

Persona UI, Its A Lot Of Work

by Jonathan Carterin Blog, Game Development, Progress UpdateLeave a Comment on Persona UI, Its A Lot Of Work

Persona UI, Its A Lot Of Work

So it’s been about a month and I felt it was about time I updated you’ll on the progress so far. I’m still working on the UI setups at the moment as they are required for the rest of the project to really function. Have been hoping between this project and another on and off all month. So I’ve only actually worked on this for about 10 or so days this month but the progress is worth showing.

Menu Management

With the amount of UI there is to do I needed to make a menu system that would let me switch between different menus with ease. Before I had a manager class that did this on context, but that was getting really messy really quickly. Instead of continuing with the messy setup I decided to refactoring it into something more useable.

The new setup is entirely static and is called in the displays logic for the active menu. The active menu then controls what buttons open what displays and runs the logic to open the new one and close the current if needed. Using an interface to keep it simple. So far this solution is proving to work quite well. Though I imagine I will, have to come back to it at some point and make further adjustments. An example of the new menu controller API in use to close one display & open another:

// API - uses type to open/close menus, with each being registered on the scene opening. 
// MenuController.OpenMenuCloseThis<TOpenMenuType, TCloseMenuType>();
// Below would switch from the skill select UI on the active persona to the detailed persona view display. 
MenuController.OpenMenuCloseThis<ViewPersonaDisplayController, SelectPersonaSkillDisplay>();

Persona Inspect

This is by far the most complex display in the entire project. But so far it’s not going too badly. I’ve managed to get then reveal mostly working and sorted a setup to show the active persona’s data. But there is still a long way to go. One of the challenges of this UI is the fact that it changes each time it’s opened or modified. With boxes randomly changing sizes etc. I have a feeling I’m going to need to work more on the UI polygon script to make it more reliable for all the use cases that are gonna crop up in the future.

P5R

My Version So Far

Some other bits include a popup description display that appears when inspecting the persona skills. I have setup a mockup for this display on the UI which works, but it needs to actually populate with data and appear still which it currently doesn’t. The other main progress is the stat level bars, these are a tad annoying as the actual “fill” is not set the actual value due to the background needing to take up more space than the fill. Currently I have the background taking the actual space while the fill uses a reduced size. But I still want to see if I can get it to update without needing such a workaround. There still a lot to-do on this display but I’m hoping to get it functionally working by the next update.

Data

In my last post I went over some of the data stuff I was working on with Google sheets, this is still an ongoing task with instant kill, healing and some passive skills still to work out and implementation for. Its tricky as a lot of these skills are very specific and working out a generic structure to store the data is proving tricky. But I am hoping to have the data done by the next update or two as it will be needed before I get fully into the gameplay and move implementation. I did fix a few issues here where data wasn’t updating object in the project, but I did some refactoring here and there to make the implementation on the dev side a bit easier. Most notable was the battle stats, so “Str, Ma, En, Ag, Lu”. The main change was to change the data from a struct to a class and to store all the data in a custom SerializableDictionary instead of individual values for ease of access. With getter/setter methods to access specific values by stat type. The code now looking like this:

/// <summary>
/// A container class to hold a persona's battle stats.
/// </summary>
[Serializable]
public class BattleStats
{
    /* ─────────────────────────────────────────────────────────────────────────────────────────────────────────────
    |   Fields
    ───────────────────────────────────────────────────────────────────────────────────────────────────────────── */
    
    [SerializeField] private SerializableDictionary<PersonaBattleStat, int> stats;
    
    /* ─────────────────────────────────────────────────────────────────────────────────────────────────────────────
    |   Constructors
    ───────────────────────────────────────────────────────────────────────────────────────────────────────────── */

    /// <summary>
    /// Makes a blank battle stats class.
    /// </summary>
    public BattleStats() { }


    /// <summary>
    /// Makes a new battle stats data with the dictionary entered.
    /// </summary>
    /// <param name="data">The data to set.</param>
    public BattleStats(SerializableDictionary<PersonaBattleStat, int> data)
    {
        stats = data;
    }
        
    /* ─────────────────────────────────────────────────────────────────────────────────────────────────────────────
    |   Methods
    ───────────────────────────────────────────────────────────────────────────────────────────────────────────── */

    /// <summary>
    /// Gets the stat of the type entered.
    /// </summary>
    /// <param name="statType">The stat to get.</param>
    /// <returns>The stat value.</returns>
    public int GetStat(PersonaBattleStat statType)
    {
        if (stats.ContainsKey(statType))
        {
            return stats[statType];
        }
        
        return -1;
    }


    /// <summary>
    /// Sets the stat to the entered value.
    /// </summary>
    /// <param name="statType">The stat to edit.</param>
    /// <param name="value">The value to set to.</param>
    public void SetStat(PersonaBattleStat statType, int value)
    {
        if (!stats.ContainsKey(statType)) return;
        stats[statType] = value;
    }
}

Misc

In the last post I also covered affinities and their display. I mentioned i wasn’t going to do the two versions. Well I’ve changed my mind on that and now plan to implement the extended boxes in the future. The display just looks really off without the background behind the text. So expect an update on that soon. Otherwise progress is good and I’m pretty happy with how the project is going so far. Even played a little P5R to get some reference material and had to stop myself playing xD

That’s about it for this update, see you all in the next one.

So Much Data

by Jonathan Carterin Blog, Game Development, Progress UpdateLeave a Comment on So Much Data

So Much Data

Data Handling

After the first day I was spending time working on the data structure for all the data needed for persona’s which is a lot. The skills stuff I did on day 1 is great, but when thinking about it further I knew I’d need a way to generate a lot of skills and items without needing to do it all manually. As that would just take far too long and I would hate it all by the time I had created each skill by hand. This meant I needed to looking to ways of automating the data creation with some tool. For this I looked to see if there was any way to make a google sheet readable in Unity. Thankfully there was a nice short tutorial on downloading data to a csv format in Unity. I managed to make a system based on that, that would download a google sheet tab to a .csv file that I could then read and convert into the sciprtable objects as needed.

The code is nothing special here and is rather rigid as I made it purely to make scriptable objects and not for general game data use. Though down the line I may looking to make a system like that. But the good thing is that it works and makes handling skills & later the custom personas considerably easier.

Affinites Display UI

Other than that I did a bit more UI work and setup a display for the persona skill affinites. These being the skills they are weak or strong to etc. The display in persona 5 is fairly dynamic with two states for this, one for no text but unkown affinities and another for when there is an affinity. But, due to a lack of good screenshots to mock it up with and the hassle of mathcing it for each icon I’ve decided that for my version to just use the one version and just update the text.

The good news is the unknown state that I’m matching from persona 5 look spretty accurate and cool. See the left for how it looks currently. Note that there is a white background behind it in the final UI setup. I haven’t worked on any of the logic for hooking this up yet, but the data it will use will make it easy to just update the affinity text if it is revealed.

Organisation & Cleanup

The final progress for the day was a bit more clean up with some commenting & script organisation. I improved the polygon ui mover script to auto start/stop and to only run when active and started a better structure where mechanics are grouped together instead of all the ui in one parent folder and all of the data in another as it makes it harder to find some bits of the codebase as it grows in size.

Whats Next?

Mostly more data xD, yea I’ve yet to get the healing skills in as of writing as well as about half of the passive ones. This is due to the varying data that I’ll need to store. There is a chance that I may have to hard code some skills in with no data just due to how specific they are, but I’ll keep trying to make a good structure before going down that way. I also plan to get some early setup for the turn management for a 1 v 1 to start with and then a x v 1 as I plan to have a full party of 4 for the player to use, matching the source game. It’ll probably be a few weeks before the next update as I do have to work on another project at the same time as this and that one has a more rigid deadline to hit.

Project Start, Persona Summoning & UI Tests

by Jonathan Carterin Blog, Game Development, Progress UpdateLeave a Comment on Project Start, Persona Summoning & UI Tests

Project Start, Persona Summoning & UI Tests

A personal project where I replicate the Persona 5 Royal Turn-Based Combat system as best I can for fun.

I was able to get a full day more of less to kick the project off with a bang. For the majority of the day I was focused on implementing some of the bits I wasn’t sure would work to prove the concept to myself before committing to it fully. I’m glad to say its looking good so we’re all go. To the left is a little video of the setup I made today. However I will be reworking all of this as I rough coded this together and it is a mess.

Whats setup:

  • Basic player & animations
  • Players stats + UI
  • Player persona
  • Persona skill select UI
  • Target select UI

I spent the tail end of the day doing some clean up of the code in preperation for the larger project. Today this was the persona skills. I knew each skill would be more of less the same in structure so I made a base class with the meta data and then specific inheritors for each type like attack & support etc. In doing this I made a custom inspector setup to make it easier to make new skills. A preview of this can be seen to the side.

The custom editor logic handles things such as the icon & name of each skill as well as elements such as the cost of the skill, as some skills use a percentage of the players health while others use a pre-defined amount. For the icons I’m just using some placeholder art I got from FlatIcon for now but I will likely change these down the line. Below are the icons I currently have for each ability:

I’ve already setup a system where you can access each of these icons in code in a static class by the type they represent. Following a similar setup for other data bits down the line should make working with such a large data set more steamlined, but we’ll see how that goes when we get to it.

Tower Defence Micro Project

by Jonathan Carterin Game Development, Personal Projects, Portfolio, ProjectsLeave a Comment on Tower Defence Micro Project
Professional Projects

💠 Merge Seige
💠 Bitcoin Tycoon
💠 Merge Motors
💠 Merge Mobile
💠 Merge Conquest
💠 Memory Match
💠 Gunsmith

Carter Games

🌸 C.W.I.S
🌸 Multi Scene
🌸 Build Versions
🌸 Detective Notes
🌸 Leaderboard Manager
🌸 Crushing!
🌸 Save Manager
🌸 Transform Colours
🌸 Audio Manager

Side Projects

🌹 Persona 5 Royal Combat
🌹 Common Library

Game Jam Entries

🌻 Dead Tired
🌻 Break An Egg
🌻 No Presents For You
🌻 C.W.I.S
🌻 Oh Gnomes
🌻 Jump Drive
🌻 Lights Out
🌻 Displace
🌻 Quacking Time
🌻 Unicycles Take Over!

Student Work

🌼 Micro Arcade
🌼 Techno Baron
🌼 Tales Of Orelia
🌼 Meltdown Mayhem
🌼 Low Poly Adventure
🌼 Microgame Collection
🌼 Maze Solver AI
🌼 The Shadow Within

🎲 Tower Defence Micro Project

A small test project where I created a few turrets from Emperor: Battle for Dune in a tower defnese styled game.

Summary

Role: Sole Developer
Team Size: 1
Engie: Unity
Platforms: PC, Mac, Linux

Day 2 Build

This was a small project where I’d replicate the mechanics of some turrets from some of my childhood RTS games to test my skills a bit. This is the result, I only worked on the project for 2 days as there wasn’t much time to work on it before I started other things so here is just what I managed to make in that time.

Day 2 – Additional Turrets & Code Refactoring

Main Progress:
– Turret rotation Improvements
– Rocket Turret Projectile Improvement.
– Gun Turret Added.
– Popup Turret Added.
– Refactored targeting & shooting to use Interfaces.
– Expanded the map to show off each turret.

Known Issues:
– Turret animations fire off 1 more time than they are meant to.
– Rockets disappear if the target is dead.
– Enemies don’t make it to the target location.
– Turret rotation is erratic sometimes.

This day was focused on improving the rocket turret and adding 2 additional turrets, the Harkonnen Gun Turret & Ordos Popup Turret from Emperor: Battle for Dune. The gun turret is a very simple model as the turret was the only main change from the rocket turret. I got my copy of Emperor: Battle for Dune working this time so I could get a good reference image for both new turrets. The gun turret is by far the best for the dummy enemies so far. The popup turret was a little harder as the turret pops up from the ground when a target is near and then shoots in 3 shots in quick succession. The challenge was mostly with the animation states as it had a lot more than other two turrets. Overall a decent day of work.

Day 1 – Initial Project Setup, Basic Turret & Enemies

Main progress:
– Turret rotation to target.
– Turret shooting.
– Turret idle motion.
– Enemy NavMesh.
– Enemies move to target.

The turret here is based off the Emperor: Battle for Dune Atreides Rocket Turret, I used screenshots that I was able to find online to make a basic model of the turret and then based the movement and shooting from memory. I learnt how to use Blender to model the turret, I had good experience using 3DS Max but my student licence ran out for that a while back. Fortunately there are some great guides out there that helped me get to grips with the interface and I’m quite happy with the model as a is and plan to try and make the other turrets from same game in the future.

Micro Arcade Development

by Jonathan Carterin Blog, Final Major Project, Game DevelopmentLeave a Comment on Micro Arcade Development

Early Developments

20th – 26th Janurary, 2020

The first week was mostly focused on getting everything setup ready to go for the project, this included getting important documents started, researching solutions to potential problems that may come up during the project and beginning to prototype some of the core features of the software product part of the project.

I started this week by completing the project proposal, a formal document that is required before the project can be officially started. This document summarised what the project was about, some of the aims and objectives and a basic risk assessment to start things off.

On the Wednesday I had the 2nd part of the FMP presentation, this went into more detail about what is next for the projects and how we should be conducting our weekly workflow. They recommend 33 hours a week on the project, which makes sense as it is a double unit. I decided to dedicate Monday, Tuesday, Thursday 9-5 & Saturday 11-7 to the project, making up 32 hours consistently. Then making up the remaining hours each week either on Wednesday afternoons, Friday mornings or on the evenings on the dedicated days.

Later in the week I focused on designing the games for the cabinet. I decided upon a simple 2-layer verses pinball game to be the retro game, it’ll be high score based with lives and bonuses for outlasting your opponent. The modern game is going to be a co-op bullet hell game with 3 parts and a final boss.

Lastly, I worked on the menu system and prototyping the first game. I hope to have the first game feature complete by week 3 and have it tested and ready to go by week 4/5. The menu system is fully setup and works as intended, it is not polished at the moment but that will be worked out as the games get developed.

A Few Weeks Later…

1st – 9th February, 2020

So, this weekend the cabinet got its last piece, the perspex screen. However, there is still a little more to do, as I made a mistake. There has also been a lot of work on the software project since my last post so here is where we are at currently. The main menu has had a lot of work, with a selection of canvases running the system. This is by far one of the biggest parts of the project as it controls all of the settings and game access etc. Below just shows the hierarchy as it currently is along with how the menu system looks right now.

There is still a lot to do on the menu system as the game settings, credits reel & joystick sensitivity needs sorting along with the artwork and sound. This will be worked on periodically while I work on the main games.

Pinball Progress

There has been a lot of work on the code side of things, getting the main systems sorted for the game. Currently I’ve got the following completed:

  • Player Flipper Controls
  • Ball Spawning & Movement
  • Bumper
  • Game Scoring
  • Game Types
  • Game Win States
  • Game Over Screen

Considering I took most of the last week off to take part in a game jam, I feel I did quite well on getting the main mechanics coded. Speaking of game jams…

Game jam???

I took part in the CGFX 2020 game jam last week (Feb 3rd – 7th). I made a game called Displace, where you take photos with a camera to get rid of obstacles and rob the bank. There wasn’t much of a game to show really, due to how much I could do in one week, but the concept is there, and it won the award for most potential which I’m pretty happy with. An extra thing the game does is it saves the photos you take in the game so you can view them afterwards, including the ones the enemies took of you. You can see the game and give it a try by downloading it from it’s itch.io page linked below.
https://carter-games.itch.io/displace

More Cabinet Construction

So, this brings us to this weekend. Where I got the last bit for the cabinet, that being the light strip perspex. But there is a little problem here! This been the fact that it is not quite tall enough for the gap. So, it’s time to get inventive. I have a few ideas to solve this problem:

  • White electrical tape layered up either in front of the Perspex or on the same line as it
  • Modelling wood, cut to size and put on the bottom edge to fill the gap
  • Some kind of corking, not sure if it this idea would work though
  • Get a new bit of perspex, rather not do this though.

I’ve also got a bit more cable management done, having the power strip attached to the back of the monitor mount and a hole in the back board for the power cable to go out of so the box can be closed off and just have a power cord coming out the back.

Last Prgress Update

9th March, 2020

Game Menu

This has had a lot of work and still has a fair bit to go, but a lot of the ground work is there. The script that controls this is by far the biggest script of the entire software product, currently being 585 lines long. There are still a fair few features missing from the menu; currently the game selection is being re-worked to accommodate more than two options & the game settings need implementing entirely. This is work I plan to do before classes on Fridays from now on as I’d like to get it done before April as the last month will be super busy with post production, deadlines & running.

Progress Report

So, on the 2nd of March I had my first graded assessment, this being the progress report. This report had been worked on for the last few months through ungraded mini-reports designed to help make this report easier. 

Ultimate Pinball

So, the first game was planned to be completed by the end of February. Well that didn’t fully happen….Not to say it wasn’t complete, but there were a few missing mechanics that need adding and the game could use some tweaking/polish. But due to the tight schedule and scope of Operation: Starshine (the 2nd game) I had to focus on making that game for March so I can still deliver the two games. Speaking of…

Operation: Starshine

While only 9 days into development progress is good for the new game. Currently all the ships the player can choose to have their stats setup on start, can shoot both their weapons and move around the scene. The movement still needs locking so the players can’t escape the camera and shields need to be added as well as some basic artwork and stages. So basically, a lot to do still 😊.

Cabinet Paint Job

The last major progress has been the cabinet itself. As of today, I’ve got an extra £60 which I can put towards the cabinet. I’m planning on producing some artwork this coming weekend to be printed on to vinyl, giving the cabinet some much needed colour. Other than that, I have painted the sides, back and top black to give the cabinet a two-tone colour effect.

What will run the cabinet? Raspberry Pi?

by Jonathan Carterin Blog, Final Major Project, Game DevelopmentLeave a Comment on What will run the cabinet? Raspberry Pi?

With the cabinet already mostly done. I had to figure out what on earth was going to power it. Now that isn’t exactly a hard question as pretty much any computer can run the cabinet, it’s not exactly demanding kit for modern day computer hardware. However, I don’t exactly have a spare computer from the last five years lying around so It was time to get creative…

Raspberry Pi?

I remembered that I had an old Raspberry Pi from back when I did computing in school. While it felt like a long shot, I gave it a try. It worked, but one thing struck out instantly, it was terribly slow! Doing a little digging, turns out I had an original 2012 model B. The latest Raspberry Pi was the model 4 B which was close to being a full desktop. So naturally I ordered one of those. A few days later I had the 4 B working with the cabinet. But that wasn’t the last hurdle…

Trial & Error

While the Pi worked, it wasn’t able to run the builds from Unity natively. This was a big problem, as the builds needed to run on the cabinet. So, back to google I went, after some digging, I found several solutions which had varying chances of success. The first method I tried was using Quora, a poorly documented tool that would be able to run x86 applications. However, this seemed to either not work or I mucked up somewhere with the install. Considering everything I was doing was command line, there wasn’t much if any feedback the whether or not I was doing it right. So, I decided to leave that option there and try another one…The next one being WINE, which was a package that could actually be install from the package manager and was made to run windows programs on Linux. One large and seeming undocumented problem, it only runs certain windows applications, you can’t run your own. At least I wasn’t able to find a way to do it, next solution… The last method I researched involved making universal platform builds in Unity and doing some command line to get them to run on Linux. I decided to not even both with this method purely based on the forum discussions alone. It was a big no! Those who tried it and got it working only got around 5 frames per second, on a blank project. Now there were other solutions that may have worked, a good example is Exagear, which seemed promising, but based on the previous attempt I decided to leave the Pi there as performance would seemingly be a big problem with it.

Conclusion

So, what is running the cabinet? Well, my current laptop, an old HP 15-inch notebook from 2013/14 makes a good fit for the role. It can run unity games fine, can run a monitor without needing its screen raised, has all the right ports etc. So that is what I’m going with. By far it’s not an ideal solution as means there is some extra setup for the cabinet that requires the back panel to be removed every time, I want to run it. But it should work for the project. I’m sure if I keep the cabinet after University, I’ll find the time to put a compact PC into the cabinet to complete it.

Making a Bartop Arcade Cabinet

by Jonathan Carterin Blog, Final Major Project, Game DevelopmentLeave a Comment on Making a Bartop Arcade Cabinet

Introduction

Making the arcade cabinet was one of the biggest parts of the project. Not only is it a decent size physically, it also is the platform that I’m making the games for, so it needed to be right.

The Design

The design for the cabinet was based on the rough shape of a bar top arcade cabinet. I decided against making a full size one as it would’ve been tricky to move and cost a fair bit more to make. Considering I was doing this project totally out of my own pocket it needed to be as cheap as I could make it while still been good quality.

When it came to getting actual measurements, I used a Legend of Zelda bartop cabinet writeup as a guideline. I mostly used the diagrams to figure out the dimensions I would need for my cabinet. As I was going for a more modern cabinet rather than a retro one, I purchased a budget BenQ 16-9 1080p monitor for the screen. This meant I had to widen the design to suit the monitors dimensions. This actually resulted in a more ergonomic design as the 2 players have a bit more space between their controls.

Materials & Measuring

The material for this project was simple 9 ply, plywood in big sheets. I believe they were 4’ by 8’ but don’t quote me on that. We got 2 sheets cut in half to make squares, due to this we somehow managed to get one for free as the checkout lady, who looked new to the job, but had nice two tone dyed hair got confused and only charged us for the one piece. I’m not complaining as made the materials a tad cheaper.

Measuring each part of the cabinet out was a relatively simple process, having the example project helped getting the right measurements, but measuring it out was tedious as the tools I had to measure with. That being an oversized set square, a bandsaw rail attachment with angles on it and a pencil which was barely visible to me due to my partial colour blindness.

Cutting out the pieces

The next main step was cutting out the pieces. Most of the pieces were simple to cut out as they were 24” wide and varying heights. However not all the pieces were so simple. The sides proved to be difficult as the bandsaw couldn’t get to the line to cut out the shape, the table saw was no better. We ended up getting close with the bandsaw but cutting it out in random shapes in steps and then smoothing it out using a mounted router.

Cutting the first peice of the arcade cabinet on a bandsaw

Assembly

Assembling the cabinet together was a puzzle really. It was more or less; get this piece to fit here, at the right angle and with the right depth so it looked good. We put the sides on first so that it could be used as a base for the rest of the pieces and gave the structure some rigidity early on. The bottom piece was a simple fit with a few supports on the interior of the cabinet, though that was the only quote on quote easy piece.

Image of the side panels cut to size and shape.
Cabinet Side Panels Attached Image

The next piece was the control board, where the joysticks and buttons for both players would be. This was a hard piece as the drill we were using couldn’t handle the cuts for the larger buttons and couldn’t reach over half the buttons on the board. Because of this we ended up using a more powerful hand drill, with one of us drilling while the other held the board as still as possible. This worked surprisingly well all considering. We made two mistakes. The first been the top row of buttons which were there for menus and confirmation in the games. They were supposed to be all in a straight line, but a mistake on measuring meant that the outside hole was slightly higher than intended. We hid that mistake by matching the hole on the other side and making it look natural. However, the left players joystick hole also went a bit weird. While cutting the board wasn’t quite flat on the table and we had a few minor scrapes on the edge which left a not perfect hole. We planned to hide this with the provided covers for the joysticks and left it at that.

After that was probably the next hardest piece which was the monitor. The monitor I had brought for this project was a 21.5” 1080p BenQ monitor. I got this one as the reviews for it on Amazon were good and it had the Vesa 100 x 100, Vesa been a universal wall mounting size format with several variations, most monitors you buy will have them. I planned to use these mounting holes instead of the base that came with the monitor when mounting it into the cabinet as it would be easier to maintain. The piece itself first needed cutting. It was the standard 24” wide but needed a hole in the piece for the monitor screen to show through. I went with the monitor been behind the board, so it added a little depth to piece which was needed. The biggest challenge here was getting the mounting right, which ended up requiring a lot of little pieces to get the mounting screws far enough away to not cause damage to the monitor while also holding it firmly in place. As with the majority of the screws in this project we used a wood glue along with screws to hold everything in place. The exception here is that the monitor could be removed from the piece if needed by unscrewing the 2 screws either side holding it in place. This may prove to be useful later on if I decided to repaint the cabinet.

Next was the speakers. To save on cost and as I happened to already have some, I reused an old Design Tech project that I did in Year 11. This been a RKAmp4 kit which we assembled as part of a speaker project. Now I kept mine and the sound quality is actually not too bad for a simple kit. It does have a downside that is phone signal interference is picked up, but this is something I may be able to fix in the future. The board itself and the speakers all still worked, it did need a heatsink to stay cool, which was mentioned in the documentation for the product when used with high power (12V). Conveniently the amplifier which was the component that needed cooling had a small hole big enough for a screw to go through. So, we attached a left over heatsink which we had found some time ago and mounted it in the optimal position for cooling, drill a hole for a screw and attaching it with a screw through the hole in the amplifier and the heatsink. The speakers were mounted in 2 holes which were cut out with the drill, which took a while as the drill had trouble with the layers in the wood. We managed to get around this by cutting until the drill bit broke through, then flipped the board over and cut in from the other side and meeting in the middle. The speakers also got a little screen which was bit a meshed metal which is just there to protect the speaker from being poked. All the parts were just screwed with standoffs on the PCB board directly to the wood, with some cable management and clips to make the connections to the board less likely to fall out.

The last main panel which is the top front piece is currently not done as I didn’t have the bits for it. This is a part that will be added in part 2. The remaining pieces, those being the back and top pieces were just a simple fit into place with screws so they could be removed as needed. The top had its edges cut at angles so they would end up flush to the front and back pieces.

Painting & Decals

After the main assembly was done it was time to paint. I went with a grey colour for a start, with 2 coats on pretty much every piece, I could always get a new colour and change it later on if needed. I do plan to add some artwork to the sides and control board in the future. This been either acrylic prints or something similar that I can just glue to the pieces with minimal tools to hand.

Conclusion

For a 6-day project, this went rather well. Now its not fully complete, hence this been listed as part 1, but the majority of the work is done. Currently the list of things still to do is:

  • Paint one of the joysticks hole covers white, so it matches the joystick.
  • Attach the joystick covers to control board.
  • Design & print the artwork for the cabinet, though this will probably be done during the unit.
  • Find & attach an opaque material for the top front piece as well as some LED scripts to light it.
  • Drill some holes for air flow
  • Decide on the system to run the cabinet, this being either my laptop or a raspberry pie or something similar.
  • Install internal plugs on an extension bar so the cabinet can be turned on and off when powered at the wall or with a button or switch on the back of the cabinet.