Dev-Blog: Love-Hate The Sheets

Let’s talk about spreadsheets. Over the course of this trimester, I have had to use spreadsheets a lot for one of my units. This has be a huge issue as I hate spreadsheets!

But the silver lining is that spreadsheets are actually amazing! And I don’t mean in the overzealous use of the term amazing where everyone uses it for things that are not literally amazing. I mean in the formal Oxford Dictionary use of the word “Amazing”. I have been filled with wonder and, most certainly, surprised at the power and functionality of sheets. To give an example;


This is a sheet is part of a submission I made for assignment 2 in my Rational Problem unit. This sheet allows the user to calculate a window of opportunity for a hero too:

  1. distract a guard,
  2. run down a hallway,
  3. Or use a cannon to launch themselves over a gap!


That was certainly a surprise, and just a simple example of how powerful spreadsheets are. They allow the user to plan out a formula to see if all the variables line up which is truly a great tool!
Image result for spreadsheet memes

By why do I hate sheets so much? Maybe it is because I fear them? There is no flashy way to do something in sheets, no way to wow someone with my sweet sweet asset skills? Or maybe I hate sheets because they can be unintuitive and sometimes down right dumb! But this is no excuse not to use them. To the contrary, this just proves to me (maybe not to you) that sheets should be used wherever it is possible as it is usual to hate or fear something you don’t understand. I would say in the case of fear that it is perfectly normal to fear something you don’t understand as the lack of understanding results in negative space where you are unable to function effectively. But hating something you do not understand is not useful at all. So What do we do about this hate? Well we write a blog and figured out that there are many reasons not to hate the thing we do not understand. I forget where I was going with this.


Well let’s look at some of the ways I have been able to use sheets outside assignments, because in the context of assignments the commitment and responsibility can cause friction. This results in not wanting to interact with the friction causing thing. The main use I have found for sheets that make me hate them less than others is their ability to store data in functionally logical way. This method of organizing data into rows and columns allows for some neat data storage. As an example I have discovered the ability to import data using sheets in the form of CSV files (CSV stands for Comma Separated Values) and have the interesting ability to easily read into programs such as the Unreal Engine in the form of data tables.


Data tables are a fantastic tool to be able to handle a lists of data that need to be accessed by a range of systems, this way it can also be easy for designers to change values without having to poke around in code and change values in stored in scripts.


Epic Games,. “Data Driven Gameplay Elements”. N.p., 2016. Web. 16 Dec. 2016.

Epic Games,. “What Is Unreal Engine 4”. N.p., 2016. Web. 16 Dec. 2016.

Oxford,. “Amazing – Definition Of Amazing In English | Oxford Dictionaries”. Oxford Dictionaries | English. N.p., 2016. Web. 16 Dec. 2016.

Wikipedia,. “Comma-Separated Values”. N.p., 2016. Web. 16 Dec. 2016.


Train Heist is a 12 hour project, it was my first solo unity 3d project, and overall I see it as a success. The goal of the game is to make it to the train engine. Alive. This is quite easy as none of the enemies shoot back, but the idea is there. The main focus on the game was to introduce an interesting reload mechanic like that seen in Wolfire’s game Receiver. Due to the time restraints, my game is, by far, a lot simpler, but I feel that I captured the overall feeling.

This was a great short project that pushed me to keep it simple. This was due to the one week timeframe what I decided was about 12 hours, so I kept the project to that. The success of this project demonstrates that my current skill level is enough to successfully complete very small short projects. However, I hope that as I continue to make games that I will be able to work just as functionally on longer projects as I was able to with this one.


There were several obstacles that I faced during this project and I have outlined and analysed two below:

The feeling of speed.


How to get the player to feel like they are on the back of a moving train? Simple! Make everything but the train move! Unfortunately this was not my first approach. Initially, I tried to use physics joints and forward movement to get the train to actually move forward but this ended up with the train flicking around like a whip. Now this was an interesting thing but nowhere near what I needed. The answer to the problem was to make the environment move around the stationary train, and to add a small shuffling motion to the carriages to simulate real movement. This was quite a good thing for me to discover on my own and it reminded me that games are made up of tricks and cheats, and that the most straightforward answer to a question is not always the most functional or successful answer. This is a really important lesson for me to take into future projects.

Sweet, sweet noclip.


The largest problem that I encountered in this project was that when Unity’s Standard Assets first person controller is standing on a moving platform it can, and often will, ignore collision. Part of the problem is that a lot of the time when you have one collision object rotating into another collision object they will not collide. This can, obviously, be a huge problem if you are expecting to be able to stand on a rotating object. To manage these problems I feel you just have to be aware of their existence, so that you can assess what the response should be for the object resting against the rotating one, so that you can decide how that interaction should play out. That may involve making the resting object a child of the rotating one, or having the mesh rotate independently of the collision. Ultimately, I have learned that some research and planning should go into every project. So that simple issues that may arise will already been known and easily mitigated.


Drury, Ben. “Train Heist”. N.p., 2016. Web. 16 Dec. 2016.

Unity Technologies,. “Unity – Manual: Colliders”. N.p., 2016. Web. 16 Dec. 2016.

Unity,. “Unity – Game Engine”. Unity. N.p., 2016. Web. 16 Dec. 2016.

Wolfire Games,. “Receiver – Wolfire Games”. N.p., 2016. Web. 16 Dec. 2016.

Post-Mortem: Everyday Knight Fight

Post-Mortem: Everyday Knight Fight


Everyday Knight Fight is a game inspired by the puppet-style combat of the game Toribash in which the players control a humanoid puppet by manipulating joints through simple state changes. This, coupled with the pausing of the physics simulation in a turn based fashion with a “We Go” active physics section between player turns, allows for an intuitive ability to manipulate torque and velocity resulting in somewhat elegant yet chaotic turn based action game.

How Everyday Knight Fight is different from Toribash is the addition of native (not modded) weapons and armour. The players must overcome, break, or circumvent the armour of the opposing puppet in order to be able to damage their opponent, and gain points.


What went right

Asset integration.


The biggest problem with asset integration is a lack of understanding of the differences in unit size, export orientation, and file type, Fortunately I have developed a solid understanding of these areas in programs including Unreal 4, Unity 5, 3DsMax, and Blender. The best way to manage asset integration is a combination of avoidance and preparation. To do this:

  1. Avoid using unfamiliar file types wherever possible,
  2. when working in groups include file type rules in the documentation so that all parties are aware of the file types to be used,
  3. when using file types that are unfamiliar do your research,
  4. and test the files on an external project or branch to avoid causing unforeseen issues, before adding them to the approved file types.


Turn based system.


This took a lot of rewrites to get right, but once I had come up with a tested system I feel it was quite functional. A lot of the issues I that I found myself running into where from poor planning on my part coupled with a lack of knowledge. This changed quickly once I had made a list of what needs to be activated/deactivated at the start and end of each turn and what functions needed to be part of Update vs PhysicsUpdate. For future management of such issues, my suggested fix would be listing the active/non active parts of the project in a game loop diagram to allow for a visual representation of turn functionality ahead of time.

Joint state system.


Replication the functionality of the Toribash joint state system went very quickly. I had changeable joint states within the first hour of production by utilizing the Unity Physics joints, This allowed for flexibility as I could rapidly create joints, add my script, link up the game objects, and the joint would function. Management of this kind of system simply comes down to having a good list of the hierarchy that you plan to implement.


What went wrong


The problem area that took up the most time (one that I had not expected to be such an issue) was physics. Because of the naturally spaghetti-like nature of hierarchies, I rapidly begun to have issues of Physics joints simultaneously being too strong and too weak. This caused an unwanted behavior of joints moving too fast or not being strong enough to move at all. After many attempts to limit the max speed at which the joints could move I found that I just did not succeed at making the system as robust and as functional as I had wanted to within the time frame of the project. The cause of this issue is simply a lack of understanding of the limitations of the Unity physics system. While there is no direct problem with the physics system itself, some of the ways in which you can interface with the system are unintuitive, and in the case of the physics joint motors (used to drive the joints in a particular direction dictated by joint state) it is inherently problematic. To manage this problem in the future, where possible, I would avoid large hierarchies of joints (to minimise the problem) or write your own joint solver to give yourself greater control over the system without the pitfalls of the default joints.



Autodesk,. “3Ds Max | 3D Modelling & Rendering Software | Autodesk”. N.p., 2016. Web. 16 Dec. 2016.

Blender,. “Blender.Org”. N.p., 2016. Web. 16 Dec. 2016.

Toribash,. “Toribash – Violence Perfected – A Physics Based Fighting Game.”. N.p., 2016. Web. 15 Dec. 2016.

Unity Technologies,. “Unity – Manual: Unity User Manual (5.5)”. N.p., 2016. Web. 16 Dec. 2016.

Unity,. “Unity – Unity – Overview”. Unity. N.p., 2016. Web. 16 Dec. 2016.

Unreal,. “What Is Unreal Engine 4”. N.p., 2016. Web. 16 Dec. 2016.

Blog: Hi, I am Ben

Games programing from the perspective of an animator

As an artist, I came into game development from the perspective of an animator working in Adobe Flash (now adobe animate [Lee]) for 2d assets and animation, and [] for 3D assets and animation. From very early on I knew I wanted to be a creative; trying my hand at animation, writing, painting, and sculpting. This all seemed to push me towards the idea of working with games but I was unsure how to make the move into game development. So starting a degree in animation with a focus on character animation, but finding that I preferred asset development, predominantly 3d assets to character animation. This also lead me to discover that I also enjoy asset integration, taking a finished or prototype asset and working through the problems that come along with integration of those asset into the engine in a functional way; making the animations function, checking assets are displaying correctly, finding issues with compression, etc.


Going through a Bachelor’s Degree in Animation at SAE Qantm was overall a great decision: it taught me how to work in a team, how to write documentation, and do planning for projects. It gave me a place to start networking with other creatives, and study subcultures and creative practice. These are all skills that I am grateful for, but I feel that I learned more directly about animation myself outside of my assignments, than I was taught. If this was due to the drive given to me by my desire to do my own work, and rebel against the assignments that I felt were not teaching me new things, or simply my drive to learn and create I honestly do not know. If you were to ask me if I would have learned more about animation without the Degree I would not be able to give definitive yes/no answer, as I just do not know myself enough to make that judgment call, and to do with the extras, the place to study culture and network. I have now started a bachelor’s degree in games programing, that gives way to the same units that encouraged networking and cultural study. So I possibly would have gained the same take away that I have done from the animation degree, but also quite possibly not, as I would have been amongst a different group of students, that could of/would of warped my personal development during that time, and possibly changed the entire outcome of those areas of study, and the personal developments that I have made about myself and my professional attitude.


Moving forward, I have made the push into programing for games, I attribute this decision greatly to doing the “Introduction to scripting unit” as an elective during my animation degree, and a large part of that was my teacher for that unit, who helped me to understand the basics of programing far beyond the semblance of understanding that I had predating that unit. Now I have found that I enjoy programing even more than I enjoy asset creation. So how does coming to programing from an animation background change my approach to other things compared to other students? Well I can only really make statements that directly apply to me, and are purely my opinion.


I have an advantage with assets obviously, as I have the background knowledge of an animation degree. But the biggest advantage that I have is that I have done this uni thing before, I have a solid understanding of how the units work, how assessments are marked, how to talk to other students, when to start working on assignments (ps. the same day it starts). I know that a lot of times I don’t take my own advice, and that I overscope everything. But I know all these things that I did not know when I started my animation degree, so in that way the biggest advantage I have boils down to experience, I have spent time learning how to work in a professional manner, I have learned to ask for help when I need it, also I have learned that you can learn more about something by trying to teach someone how it works. So my final point is that I have spent the time to learn.

This gif is an allegory for learning something new. There is nothing actually stopping you, but sometimes you just need someone to let you in.


Blender,. “Blender.Org”. N.p., 2016. Web. 15 Dec. 2016.

Lee, Rich. “Welcome Adobe Animate CC, A New Era For Flash Professional | Creative Cloud Blog By Adobe”. Adobe Creative Cloud. N.p., 2016. Web. 15 Dec. 2016.

The One Key Mechanic

For this blog, I will be talking about the GDC 2016 talk given by Ojiro Fumoto, on the development of his game Downwell. I will be looking at how he approached the design of the game, why he pushed for all the mechanics to be multi-functional, and some tips that I can apply to my own future projects.

At the start of development Fumoto had a concept in mind, and idea based around the unpredictability and downward progression of the game Spelunky,  but for mobile devices, and played in portrait orientation. No documentation, no design documents, just an idea, and a working project. Additionally, Fumoto decided to limit the possible inputs to three buttons, left, right, and jump. This decision to limit input came from Fumoto’s personal experience with action games on mobile devices and his opinion that the more inputs the harder the game would be to control. Once the prototype reached a playable state, Fumoto began to search for a way to make the game more dynamic in the sense that the current level progression was two simple. After some experimentation, Fumoto decided to proceed with the idea of having the player character fire projectiles from there feet in a downward direction only while the jump button was held. From here Fumoto begun to base the entire game around this downward firing mechanic, of witch he iterated on, and designed around to keep it at the heart of the game, the mechanic is called Gunboots.

The way that I would describe Fumoto’s design method is this;

  • The Idea; First have an overarching design goal – Spelunky on mobile.
  • The Prototype; create a project of the necessity’s you initially need to move toward that design goal. Take inspiration from games you play and apply similar ideas to your prototype.
  • The Core; After some iteration toward your design goal, find the core of the game, update the core and your idea to work toward a common goal.
  • Design and iterate; Be creative, try, fail, and apply inspirations.
    • Test; play with the prototype, apply your design ideals to it, see where it is not working, find the core problems.
    • Experiment; Pick a problem. Try different ways to fix that problem. Apply the design ideals to the experiment and see why it douse not fit.

This is how I feel Fumoto approached designing Downwell, with hands-on, hard work and lots of trial and error.

One of the most important elements to Downwells deign is the idea that no one mechanic has a single use, Fumoto relates this idea to this quote from Shigeru Miyamoto “A good idea is something that does not solve just one single problem, but rather can solve multiple problems at once”. As you can hopefully gather from the quote, and the design of Downwell and many of Miyamoto’s games. Having multi-functional mechanics lead to interesting dynamics in the game where you can use the same element to approach many situations, often reducing the overall mechanics in favor of fewer more fleshed out, more dynamic mechanic driven situations for the players to encounter.

To close out I will list the two main things that reinforce methods that I already use in development, or I had previously unconsidered but will strive to use in the future.

  • Start with an idea AND a prototype; An idea is just that with ought some form of physical being, making a prototype can be just what you need to kick start and idea into a full development cycle.
  • Find the core and work around it; Fumoto had worked on the project long before his discovery and pivot towards the Gunboots. But as they fit the hole he had found in the project and added the spark needed he focused development around the Gunboots as the core of the game.


Gunz vs Burn

This week I played these two games GUN GODZ by Vlambeer and Burnband by Tom Boogaart

Gun Godz is a fast paced, doom-like, first person game with a pixel-art aesthetic, and fast gameplay. Where Bernband is also a pixel-art game but your only goal is your own curious sense of exploration.

They are very different in the way they encourage you to play, yet the same in the way you feel a sense of gratification, as you begin to learn the layout of the games. In both games, it feels good to explore, but for different reasons; exploration in Gun Godz is a necessity in order be able to find the exit and resources like health packs and ammo, and having a good understanding of the layout’s is a must in order to be able to get a better time score on the levels. Burnband does not have this need, you explore because that’s what you want to do.

The dynamics that arise in Gun Godz, compels you to become familiar with its level’s, so that you become better, you become a running gunning god of gunz.

The dynamics that arise in Bernband, on the other hand, rewards you for exploring because you want to discover. Because you want to become familiar because you begin to care about the world as it slowly (with its sweet, sweet microcosms, vent shafts, and character), involves you in it heart-beat.

“Dynamism is Revolution” – Hocking (2011)

After being tasked with watching “Dynamics: The State Of The Art” by Clint Hocking and being asked some questions about the talk, here are my answers.

Why does Hocking think dynamics are so important?

As highlighted in the final words of his talk “dynamism is revolution”. So by breaking down the meaning of the words.


The theory that phenomena of matter or mind are due to the action of forces rather than to motion or matter.


A forcible overthrow of a government or social order, in favor of a new system.

And to splice these separate but aligned meanings into a sentence you get something like this; A phenomena of bottom-up social mindset from action, constrained by circumstance. To describe this sentence in a way that reflects Hockins opinion of the importance of dynamics, one could say that the meaning of the phrase “dynamism is revolution” is to say that; dynamics are important in the way that they do not enforce meaning, but give meaning a reason for being, that each individual to their own understanding the dynamics will resolve their own meaning from them.

So to answer the question: Why does Hocking think dynamics are so important?

Hocking believes that dynamics give the constraints that produce deeply personal meaning. So without dynamics you cannot create content that produced deeply meaning full experiences.

Summarize at least one of Hocking’s examples of a game’s dynamics.

In the talk, Hocking explained the dynamics of Tom Clancy’s Splinter Cell: Chaos Theory(2005), and how its dynamics are the fundamentals of “Chaos Theory” those being, sensitivity, proximity, and fragility. How the game produces this is by putting you in close proximity to sensitive systems, that can have a catastrophic cascading effect, and reinforcing the importance of these with the fragility of the situation. Distilling the feeling of “on the edge of Chaos” that the games design was aiming for.


Hocking, Clint. “GDC Vault – Dynamics: The State Of The Art”. N.p., 2016. Web. 17 Oct. 2016.