Vektor Maf

Vector math is one of the first and probably most important topic that I covered in the first week, as vector math will lay down the groundwork for a lot of the other mathematics I'll perform throughout my career. Using these planes to describe direction and magnitude, or a vector, particularly within a three dimensional space, is something that I feel particularly comfortable with.

Describing coordinates according to world space, space relative to an object or relative to the camera view is an easy concept to understand, though finding out when I should use which space is likely something that will simply take getting used to.

I'd like to use the information I currently have in order to create a small 3d Vector mathematics library that I can use in the future if it's good enough. It should be relatively simple, though just implementing hard coded formulas that perform in the same way is definitely very easy, perhaps I'd be able to find a way to make the functions within the class calculate using the different spaces?

It's something that I'll probably have to explore a little bit more while creating the library, and then report on what I've done in the future.


Tylah Kapa

The First Week Back

Well it's Monday again, and the living's easy.

It's been one action packed first week back, that's for sure. Laying down a framework, expectations, learning new things and going camping. I finally have a small chance to gather my head and organise myself.

So for studio this trimester. I, as a programmer, will be separated from the designers in my cohort, as we begin our specialised learning. Up until this point, designers and programmers had about the same amount of knowledge, but now that we are separated we now have a chance to study techniques and problems unique to programmers.

One umbrella term for one of these techniques is Artificial Intelligence programming, AI as it's commonly known. AI is a very common thing I'll have to program throughout my career as a programmer, be it for enemies or allies in a game, or perhaps even something completely unrelated to games, though I doubt I'll ever stray too far from the path I'm on right now.

I've already made very simple AI before that just takes points in the world that the enemy should move to and moves to it. But I never felt like I actually ever learned how to properly program AI, and now is my opportunity to do it.

With this comes some new mathematics and programming techniques I'll learn, these include Vector math, particularly 3D vector math, Matrices, and creating a mathematics library for ease of use and deeper understanding. Using things like pathfinding and finite state machines effectively will come when they do.

Though for now, that's about as much as has happened in the past week. A more in-depth blog about matrices and vector mathematics and their applications will be coming up soon.


Tylah Kapa.

Particle Systems are EzPz

So for Tanty, I found that all of the particle systems I wanted people to make were unsatisfying and sub-par. Which is when I took it upon myself to make this particle effect. This particle effect is meant to represent all of the destruction you are causing in Tanty. The red is the character straining themselves, while the purple in and black in the centre flies towards the center of the screen, giving the player a visual representation of where things they pick up will travel to.

Power Particle Effect

Power Particle Effect

It's pretty good.


Tylah Kapa

Dash! a-ah Savior of the Universe

Ball Star Battle is a project that I'm primarily trying to simply improve my coding practices with. I'm attempting to use more coding patterns more effectively, I'm trying to do more in less lines and I'm trying stuff that I'm ju7st not used to yet.

On of these techniques that I'm not used to a coroutine. For Ball Star Battle, characters must be able to dash, and at first, I believed that it would be rather simple for me to increase the movement speed of the character, or add force in a particular direction. Which is, shamefully, what I did initially do. Trying to come up for a better way of implementing dashing, I came across the use of coroutines, which I haven't used in practice before.

IEnumerator dash(Vector3 direction) 
         myState = PlayerStates.psDashing; 
        Vector3 startPos = transform.position; 
        Vector3 tarPos = startPos + (direction * moveSettings.dashDist);  
        int dashDuration = (int)(moveSettings.dashDist / moveSettings.dashSpeed);  
         for (int f = 0; f < dashDuration; f++) 
            if(myState != CharacterController.PlayerStates.psDashing){ 
            yield break; 
                 myState = PlayerStates.psDashRecovery; 
            transform.position = Vector3.Lerp(startPos, tarPos, moveSettings.dashAniCurve.Evaluate((float)f / dashDuration)); 
           yield return null; 
        myState = PlayerStates.psDashRecovery; 

This IEnumerator is named dash, and takes a Vector3 Direction as an argument. This IEnumerator will be invoked when the player presses the dash button, and is not already dashing, or recovering from formerly doing so. The dash direction is calculated before the IEnumerator is invoked, by finding the direction that the player is trying to dash in. The IEnumarator finds the target position, and lerps between them over a set number of frames.

By passing information through an animation curve, I've found that modifying the speed of the dash is extremely easy, and modifying the variables used in this script enables other components in the script to alter the speed or distance that the character can dash. In general, this block of code has saved me a lot of time putting out other areas of the tyre fire that is the rest of this game, and I can leave it alone knowing that it will definitely do what I want it to do.


Tylah Kapa

Hey, this thing just happened, do you care?

Pretty much sums up what an event system does. 

I was unfortunately unaware of this programming delicacy at the time that I'd created the character controller that I'm working on for Ball Star Battle. However, that doesn't stop this amazing piece of code from saving me spaghetti cooking time in the future. Here's an example of how it's done in C++.

void Physics::updateEntity(Entity& entity)


bool wasOnSurface = entity.isOnSurface();



if (wasOnSurface && !entity.isOnSurface())


notify(entity, EVENT_START_FALL);



Example of starting an event in C++ (Nystrom, R. 2014)

The code above is a short example of an entity essentially yelling out that it's falling. Once an entity has invoked and event, optimally via an event manager, the event manager will then notify anyone that cares about that particular entity falling that the entity is falling. The entities that care are called observers, and they do with the information given to them according to the way that they want to. 

A prime example of an entity invoking an event would be unlocking achievements. A player might be sending out a lot of events for an event manager to give to other scripts throughout the game, when the player completes a particular action, the player might then invoke an event that only the achievement script is listening to, which would then go ahead to unlock the achievement. The information that the player sends when that particular event is unlocked might be expanded to include the system's date and time which can then be utilised by the achievement script to show when the player unlocked the achievement to the outside world. This system is used in contemporary games and consoles.

Invoking events is a very simple, clean and easy way to pass information around multiple scripts, having certain scripts listen out for events and then proceeding to do what they want with the information provided in the event can certainly pull a great weight off of my shoulders when it comes to making my general coding skills better. I plan to incorporate this pattern into Ball Star Battle, so that I can get a clear idea of how and when to implement it properly.

In fact, with the help of others, I've begun implementing event into my game, the script for my event manager may be found here.


Tylah Kapa

A peek into the future

Recently, I've been getting more and more into being a project manager, trying to get into the groove of it, and looking into what being a project manager would entail.

As it turns out, the closes industry role that I could find to what I know to be a project manager is a producer. Looking a little bit deeper on what it is to be a producer, I found this article from Ernst ten Boch, a former producer/project manager at Blizzard Entertainment, a thorough and interesting blog on his opinion on what a good game producer is.

Boch, in his article, says that he refers to the team that he produces for as a flock of sheep, constantly needing to be kept in line, walking forwards and well-fed. He also says that he believe that a producer is a jack-of-all trades, as a producer doesn't have be be good at any one thing while also handling the pressure of keeping this herd in-line.

I've also read elsewhere that a producer is more a facilitator than a dictator, that a producer should always seek out problems within a team and resolve them or facilitate them if it's a personal issue. A producer should always seek the team's approval of this facilitation, especially if it affects workflow, or deadline expectations. In short, the producer is the guy that makes sure everyone is happy, and be to get the work the are assigned on time. 

While I do love the sound of doing that, I know that I myself am not very good at talking to people, or ensuring that everything is okay, especially for a larger team of people than I'm working with now, 4-6+. While being a jack-of-all trades appeals to me, and I've said so in a previous blog, I believe that I'd like to be more personal and specialised with the processes involved, rather than a conflict settler or work arounder-er. So perhaps if I took a step down, and started to look into Lead Programmer, someone that still does the same sort of thing as a producer, just on a smaller, more programming related scale.


Tylah Kapa

Why Audio is Pretty Damn Important

For no real reason lately I've had some kind of epiphany about how great game audio really is, that is to say both the soundtrack, foley and feedback audio. So now I have about 17 game soundtracks sitting on my phone, all of them amazing in their own rights. The thing is that feedback audio and bgm, though players don't often realise, are one of the most important assets that a game could have. A game could look bad, and play terribly, but that splat sound you hear when you throw what looks like a banana against a wall still makes you feel awesome when you do it.

Often times I don't notice that kind of sound in games, but I see now that it can make or break everything for me. There's things that I can expect to hear when I walk forward or drive a car into a lightpost, and whether I know it or not, if I don't hear those things somewhere amidst that awesome rock track composed by some cool dude, then I'm going to feel disappointed, no matter how cool it looks.

I learned all of this in the last project that I completed, Tanty, found here, which was intended to focus on player feel and experience. In Tanty, you're able to fling objects around, smash them against walls, smash doors open, and in some cases, these audio assets didn't get into the game, and that was disappointing, both from a Project Manager, Developer, and player point of view. 

When initially passing over what assets we wanted for the game, we wanted unique collision sounds for the many different objects within the game, as hearing a thud as compared to a bump when you throw a computer tower could make all of the difference between positive and negative feedback, particularly for a game that was meant to focus on player story and experience. However, inevitably hoping that all of these sounds will be completed and implemented looked to be severe over-scoping for the amount of time that we had, and had to be cut for simple placeholder sound effects from bfxr,net. 

But we did what we could, and a lot of chair rolling, box dropping and voice cracks later we had some audio that we were somewhat happy with. These sounds replaced the easy placeholder audio for something a little bit more satisfying and less abrasive to hear. Feedback ended up looking much better in later play tests.


Tylah Kapa

State Machines and Me

Fighting games, a menacing thing for players. A nightmarish entanglement of code for programmers. Introducing the "new-fangled" Finite State Machine!!!!

But really, for the past week or so, I've been working on a simple fighting game alongside a friend and this game requires a rather comprehensive characterController for the level that I'm at. After about a week, I got sick of looking at my spaghetti code, and decided that I wanted to look for a much better way of managing the many states that a fighting game character can iterate through in a fighting game. This is where Finite State Machines come in! Now, finite state machines aren't new to me, but if you aren't sure what they are:

Finite State Machine Diagram  (Nystrom, B. 2014)

Finite State Machine Diagram (Nystrom, B. 2014)

In my own words, an explanation of what a finite state machine would be: If you think of water, for example. Water has three different 'states' that is can appear in, these states are Gaseous, Liquid and Solid. Water can only be in one state at any one time, and certain parameters must be met before the water can move between these states. This is, in essence, what a finite state machine is, just with more states that an object can be in. For example, fighting characters will have many states that they can be in, these include jumping, falling, attacking, attack recoil, blocking, block stun, stunned, etc. Any on character can only be in any one of these states at any one time, and can behave differently, just like water, depending on the state they they are in.


Using Enumerators to Declare the states that this character can be in (Nystrom, B. 2014)

I've utilised the finite state machine in the character controller that I've made, and I'm much better off for it. using finite state machines makes it much easier to moderate what character can do what and what time, without juggling millions of bools to make sure that they can do it. I've noticed how badly held together my code is, so I'm trying to make strides towards better coding practices, making sure that I use finite state machines where necessary is on of the easier steps forward that I could take, but a step forward regardless.


Tylah Kapa

Teaching a new dog new tricks

While programming, I've found it difficult to program with usability and ease of access in mind. However, I recently stumbled across an extremely simple way to simplify my code for both myself and anyone who wants to use it.

    public class MoveMentSettings
        //Variables that relate to the movement of a character
        public float moveSpeed = 5.0f;
        public float gravity = 9.8f;
        public float jumpVelocity = 10.0f;
        public LayerMask ground;
    public MoveMentSettings moveSettings = new MoveMentSettings();

This simple block of code is great, it creates a dropdown in the Unity inspector and groups all of the variables that I want to pertain to that dropdown to be manipulated. The variables shown above allow for the manipulation of gravity, jump velocity and movement speed values, ultimately changing the way that the character plays.

It's not anything new to many people, but a great thing to know for programmers who are working alongside a team.

Tylah Kapa


Life as a Project Manager - Project 3 Post Mortem

Another deadline, another project wrapped up today. All in all I had fun making Tanty, though it could be much, much better, and I'm not too proud of it, it was still fun to participate in it. Primarily, I'd like to discuss how I felt as project manager, and how it relates to what I might want to do in the future. This project is now published and available on here.

As I've mentioned before, for the past few projects I've participated in I've been relegated to the Project Manager role. It's been a great opportunity for me to see what it's like to manage a small team of 5 people, I've toyed around with the idea of starting my own games studio, so I had a chance to evaluate how that might go if I were to start a studio in the future.

The Bad

The TL;DR of it is that I feel that being a project manager on the past few projects, I felt helpless, useless and like I was the reason that not enough work was being done. Feeling that perhaps if I had just pushed a little bit harder for more work, then maybe I could have gotten the work at a standard that I can approve of. However, I can't just blame myself, but I can't just blame my team, all I could really do is get better. The bright side of it is that I do feel that I've gotten better at managing a small team for a small project, I've just been doing it wrong, more or less.

The source of the problem is that I trusted in my team too much. I placed a lot of faith in my team to acknowledge what they have to do and get those things done before the given deadline (a milestone, a playtest etc.). However, I was also dumb, and didn't give them a detailed written outline in the game design document of what needed to be done before that time. Having the written instruction gives me something to point to if the person assigned doesn't get the task quite right or doesn't do it at all. For future projects, personal or group, I will ensure that all of the tasks are outlined in the game design document, or a similar centralised document for game mechanics and have the tasks on that document linked from the description of an assigned task in the group's HackNPlan, a really simple and useful scheduling tool for game development. Doing this, I can keep a close eye on who is actively looking at their tasks and adding to the document.

The biggest mistake I made was being complacent with the work that was getting done. I might have felt that a lot of work was being completed, but the reality was that I or one other member of the group can completed all of our tasks. Therefore I felt that there wasn't much need to rush the other members or push for that little bit more work to be done. I don't have any real power when it comes to choosing who is in my team or making them do work. I told myself that I would push them to do more work if they were lagging behind or not getting work done before deadlines. However, there comes a point when you just can't rely on those members of the team, and you also can't get other members to waste time helping them. It then becomes a case of working around your team and accepting that they don't want to get work done. Of course, in a professional environment, this kind of behaviour should never be present, it really does give perspective, separating those who want to become professional from those who don't. I plan on being more firm with future groups, even if it does mean feeling like I'm being irrational. In the end, it'd benefit everyone in the project to get work done, and more satisfying for everyone if the project makes real progress before a deadline.

In terms of the project, of the things I found to be difficult to work with was the initial concept of the game. At the beginning of this project, it was very clear that the game was uninspired, not innovating, and overall bland. It discouraged many of the team members as we attempted to pitch it and found that it just wasn't working for us. The fact that the concept was not iterated on very much after pitching made it rather difficult to find something positive to hold onto throughout the early stages of development. Quite simply, iterating on the game in those early stages of development, particularly if we know the project isn't up to scratch, is one of the most important things that could be done at that time. Ensuring that all plausible ideas are thrown at a wall and seeing what sticks is the best idea.

The Good

Of course there were things that I liked about this project. The fact that the project was intended to focus on player experience and working around restrictions. This project worked around the given restrictions quite well, despite being unfinished. I also felt that focusing on giving the player feedback via controller vibration and screen shake was extremely satisfying. It was interesting to see player's reactions to the screen shake and vibration. I'm not saying to always focus on player experience, but if you have a feature that you want to provoke a certain emotion, polishing it, ensuring it works, and watching it work is easily one of the most satisfying feelings in game development. The experience you want your players to have is important, what's more important is that it is focused on. When it comes to making games, you'll always want to add a feature here or there because you think it'll give it that touch that makes it just right. In the end, if it doesn't match with the experience that you want it shouldn't be in the game.

After trying to be a project manager for the past few projects, I can safely say that I want to do better as a project manager, especially as someone who is thinking of starting their own studio. Being a project manager this early on in my career, managing a small amount of people can give me life experience for the future. While the projects didn't go perfectly, I got a huge amount of experience just by doing, and that's just the way that I learn best.


Tylah Kapa 







How the cookie crumbles

So for an upcoming prototype that I'm working on we are playing around a lot with the physics in Unity. One of the assets we need to have is a door that can explode when an object hits it, giving the player a certain amount of satisfaction and excitement. Once I obtained this asset, I dumped it into Unity and immediately began plying around with it. I had a basic idea of how it would work. When the objects that the player can throw around collide with the door, the door will spawn in the broken variant of the door and disable itself in order to allow for the pieces to scatter around. These lines of code were simple to put together, the alteration of the prefab itself was the p

After some tinkering we found that adding force to each of the shards to have all of the shards fly out in a destructive manner rather than replacing the door and falling in place is much more satisfying to see and acknowledge that you have done. Below are the results of all of  these aspects coming together. 10/10.

The script for the function above can be found in the project repository here.


Tylah Kapa


Working in a Team

If you're at all interested in working in games, the most essential knowledge you could have is how to work in a team of people. For the past few projects I believe that the way I've worked with a group both as a programmer and as a project manager has developed significantly. 

To me, the most important information I could have is how confident and motivated each member of the team is. As a project manager I can derive who is confident and motivated from who is present, attentive and a primary contributor to group meetings and the project's progress. This is especially obvious on a service that your group is using for discussion. Those that are online, present and willing to discuss the state of the project and the work that they have done are those who are motivated to progress the project to completion. 

When met with members of the group who aren't so cooperative, it's important to handle them with care. More often that not, simply dumping work on them expecting it to get done is never the smart response. to such a character. When I was met with this, presenting them with an amount of work that I know they could not do, and asking them what they can get done in a certain time frame was one of the best things I could have done. People have a tendency to not want to disappoint, if you were to put a load of work in front of me that I couldn't achieve before a set date, I would still attempt to get as much of it done as I think I could do, because I don't want to disappoint you. In my case, doing this tactic got the ball rolling and cogs turning, and ended up motivating the person to do a little bit more and a little bit more each time. 

To be firm in pushing for the maximum amount of work to be completed before deadlines, ensuring that work load is spread evenly and those falling behind are helped is, in my eyes, what a project manager is. If I were to be a project manager in the industry, I would try to adopt these kinds of tactics to create a more positive, motivated work environment. Which would naturally increase workflow throughout the project. 


Tylah Kapa




I want to be....

Dark Souls, particularly Dark Souls' lore most definitely had some kind of impact on me. I walked through countless grueling areas to kill things without really knowing why, to light a big fire, I guess. There was something about it that left me wanting more, and so I searched, in the game, on the internet and it dawned on me. The game had had the same kind of impact on so many others, they finished the game and were left wondering "Why the hell did I just do that?". There's something magical about watching people come together to piece together a narrative others are almost sure doesn't exist, only to find it's much deeper than first anticipated. 

To instill that kind of feeling in others, the lust to know more, or even to take a piece of information and make your own story out of it, is why I want to become a World-builder, or at least be involved in that area throughout my career. Here is a small description of a World Builder Artist, one who is more involved in the art side of world building and creating natural and interesting levels for a particular world's lore. While I'd more like to participate more in contributing to the lore of a world, to design levels around that lore is something that I still find interesting.

Finn Staber is someone whom I coincidentally found while searching for examples of a World Builder. Finn's LinkedIn profile shows that he was, at one point,  Senior Designer/Programmer/World Builder. From the points that he outlines the job with, he had to work closely with the art and animation departments to incorporate lore based assets into the game's world, he also needed to design levels and player-NPC interactions. 

While I find these things interesting, and perhaps more closely related to those feelings that I want to invoke in others, I think that I may reconsider just exactly what I want to do in the industry. For now, general programming is fine, but I'd like to focus more on a particular field that requires programming in the future.


Tylah Kapa


Post Mortem: How 2 Pitch

Recently I finished up a series of pitches for an up and coming group project of mine. For his project, I completed two pitches, one internal pitch for my peers to explain the game's concept and one external pitches for potential collaborators to ask for help with the creation of audio and animated assets. I wanted to look back at the two pitches, compare the general responses from the pitches and what can be done better in the future.


The phrase "Well that could have gone better." should be ever present in a growing mind and this holds especially true for those in the games industry. Making games is rather difficult, and the only way to make it that much easier is to look back, realise your mistakes and make some kind of plan to counteract them. 

The first, our game's concept was very much lost in translation, in turn our pitch was not as strong as perhaps we thought. It's difficult to realise, pitching a concept effectively whilst maintaining the audience's attention is rather difficult. This was most likely due to us whom made the pitch skipping over some major details of the concept in both pitches. Post-pitching, we found questions about our game's concept to be very repetitive, asking about aspects that we had thought that we covered clearly or just weren't in the pitch to begin with. I believe that for future pitches, a prerequisite brainstorm should be made of: Who are we pitching to?, What do they need to know? When do we give them that information? I've found that making a list of things based off of these questions would have been much more effective than simply going up and blurting out things that we know about the game.

Secondly, and one of the most important, some of the team's members were not present during the pitch / did not contribute to answering questions about the game's concept. I found that once our pitches were finished, when it came to feedback or questions about the game's concept, it would largely be me or our primary speaker answering questions about the game. This aspect of the pitch made the entire team look disorganised and grasping at straws for answers to the questions. Whilst it is important for the entire team to take notes on feedback and reactions, it's equally important to show that your team is confident and able to answer questions that maybe others in the group can't. In the future, before pitching I should make sure that the entire team is present, attentive and on the same page as the rest of the team along with designated part of the pitch that they may present. This will help to ensure that the team can help other members whom are struggling with presenting, while assisting in showing to the audience that the team has experience and confidence.

Finally, third, which I find to be personal to me, is that I find that I can get quite dismissive of feedback or responses, which I know is a horrible habit. It's difficult to describe the circumstances under which I do this, though I find that at times when I get up to pitch my idea with the intent of taking down any and all feedback, I find that I'm discouraged. Perhaps that's a more adequate way of describing it. Whilst receiving feedback on my group's concept or pitch I can find myself quite discouraged, especially if I find that I've made a mistake, or someone is pointing something out that I know I clearly should have put in the pitch of thought about beforehand, this holds particularly true if someone is nitpicking the wording in a slide rather than addressing the pitch itself, that in particular I can't help. However, I can still counteract this, I believe that perhaps this discouragement is borne of overconfidence that the game's concept is set in stone and the second coming of Christ when (I know full well that) it isn't. In the future, I think that I will have to give myself a confidence booster, it's important to remember that the people giving you feedback are (in majority) trying to understand your game's concept in order to give you valid input on refining the game before you've wasted time and money. I think that to remove the emotional barrier I'd need to just take notes on the feedback and answer the questions I know the answer to, contemplating all of it after the presentation. Of course, dealing with emotion is easier said than done, however, this should be something that I find easy to correct in further pitches with the right amount of preparation, consideration and confidence in the concept.


If I didn't say it last time, I'll say it again, with all bad things come good things. it just so happens that the good thing that happened to us was a complete revamp of our setting and game mechanics. This was largely due to our somewhat fruitless attempt to consider and refine our game's mechanics in between pitches. I will say though that I'm much more happy with the design that we scrapped everything for, as I think that it's nearly perfectly scoped. That's not to say that I can actually replicate this, I'm sure that it won't be often that I'm backed into a corner with such a bad design that a long hard look at it will allow me to mold it into something that I really like the idea of, and so I doubt that I would be able to replicate this kind of result all of the time. But in the future, this kind of thing can still happen with proper consideration of feedback. 

I'm kind of strapped for things that actually went right with this pitch, and so I think that's about it. I think that from these pitches I learnt first and foremost that having your team there to back you up is one of the most important aspects of pitching, if you have an organised team, you will most definitely have a confident and organised pitch. As someone who finds himself in the project manager's seat quite often I think that it would be important for me to try to get this kind of stuff down and organised beforehand. Other than that, instilling in myself the confidence to mull over important feedback is probably one of the things that I should be focusing on right now.


Tylah Kapa


Small Update

Recently I've been feeling pretty swamped with the project that I'm currently working on, however, I was able to pull out an update to my health bar for a small side project that I'm working on!

To explain really quickly, I've been experimenting with designing, creating and utilising the 2D art that I make. I've been looking into actually attempting to draw characters and whatnot, but I like making inanimate objects for now.

Frames for my health bar

Frames for my health bar

The health bar below is something that I've been wanting to try to see in action for a bit now. The player's primary health is the three green crystals, followed by the player's additional 'Will' in the red and blue crystal.  When the player attacks an enemy, they will gain Will, firstly filling the red gauge and then the blue gauge capping out at ten Will. Will can be used both as a catalyst for stronger attacks and as a secondary health bar. red an blue attacks will be both stronger and bigger alongside making the player somewhat more vulnerable. If a player uses a red attack at ten Will, their Will will be reduced to eight, the player may then use a three Will blue attack to exhaust their blue Will and then only have red Will attacks available to them. 

I'm unsure of how this will work out, as I still have to work out how I want this resource system to feel. I'm wanting the player to feel strong and empowered, though only in moderation. I hope that I can get something cool up and running before long, but I guess time will tell.


Tylah Kapa


2.8 Days Later

It's been about 3-4 days since SAG-AFTRA put out their notification to members that a strike had been initiated. Since then it seems that the struck companies are still to produce a "fair offer" for negotiation between the struck companies and SAG-AFTRA.

The SAG-AFTRA Interactive Negotiation Committee have put out an official statement of negotiations so far saying:  

"We know where out members stand, and we will put a deal in fron of the SAG-AFTRA membership when we have an agreement our committee can recommend." 

The full statement can be found on SAG-AFTRA's website here

To me personally, I think that anywhere is a good place to start, if all of SAG-AFTRA's demands are met in the middle then it would be a huge leap for the games industry. My fingers are crossed for this strike to cause a domino effect within the industry and force triple A companies to clean up their act, specifically their treatment of employees, not just contracted actors. 

In 2015, the International Game Developers Association (IGDA) conducted a survey. The study indicated that of the 65% of the people that were surveyed whom claimed to be permanent employees it was found that they had an average of 2.7 employers in the past 5 years. I'm not sure about you, but to me this may be cause for alarm, we live in a world where too many game developers expect to be fired upon release, and expect to be in perpetual crunch for their career. Those whom look from the outside in can point and pretty soundly say "Well that's just a normal part of Game Development, stop being so selfish." and that is, quite frankly, totally fucked up.


Tylah Kapa


The Voice of God

Often under-appreciated, voice actors of the SAG-AFTRA organisation are finally taking a stand against triple A game development studios, going on strike as of Friday of this week (October 21). 

This came to my attention just this morning after an article written by Wil Wheaton in 2015 which outlined why he supported the concept of striking against these companies. His article also involved a small exercise which, if strictly followed simulated a working day for a voice actor (I tried it, it hurt my throat quite a bit). The strike notice outlines four key demands that the organisation has for these companies:

  • Providing back-end compensation on successful, multi-billion dollar games.
  • Increased payment and fixed time frames on voice-straining recording sessions.
  • Allowing the actor to make informed decisions about whether or not they will take an offered job.
  • Ensuring that a stunt coordinator is present if the actor is to participate in dangerous work.

There are things that I, looking into the process,  believe were basics of hiring a voice actor for their talents. It comes as a shock to me that this kind  of stuff is occurring and is allowed to occur in the professional industry. Quite frankly it's ridiculous, so often do I hear tales of how badly employees in the triple A industries are and it's off putting. I hear of programmers working 20 hour days to fix three bugs which appear again in the morning, I hear of people being locked out of their studio, not even knowing that the night before that their studio was shut down. Now this.

Voice acting/Mo-cap + Voice acting can truly tie the knot together for modern games. Rigorously programmed animations, no matter how hard they try, simply cannot convey the kind of emotion a real human actor in that mindset can. Contemporary, triple A games simply wouldn't be the same without the kind of acting that we see in them today.

I can only hope that this is that straw that breaks the camel's back, it's time for a change in the interest of the well being of employees in this industry. Perhaps that's a little too hopeful on my end, but that's about all that I can do right now, hope that this industry gets better before I'm sent out into it. 


Tylah Kapa


Post-Mortem: Project 2


Today signals the final day of working on this project, a video (board) game. This project was relatively strange, and I didn't particularly have high hopes for it. However, every team had about the same amount of work done to a greater or lesser extent, and so I'm rather satisfied with it. 

Yeahnah: Election Day entailed working on a video (board) game, or so the brief told me. This game was more akin to a card game with FMV game elements, yeah, those cheesy things from way back when. The game had only three players and a set of two decks of cards (incident and response cards). Placing five incident cards in front of them, the players would respond to the incident with their response cards, input a code into a computer with the companion app running on it and voila. 



What exactly went wrong in this project? Were there things that I think could most definitely have been done to a higher standard or just better in general? The short and long of it is yes, there was quite a bit that I think could have been done better, as with all things game design things are bound to go wrong, take the time you think you can finish your project in, double that, and double it again and you'll have your time frame (or so I've been told). 

Firstly, my group found ourselves quite stressed and short of time. Without pinning blame, this was most likely because we didn't have any counter-risk documentation, or documentation that indicated and solidified to us the direction of the game that we are making. Having a basic schedule simply wasn't enough for us to keep entirely on track, and so our personal organisation let us down. However, one of the most glaring problems is that one of our team members felt unmotivated to do work, which most definitely didn't help to oil the dry brakes of the project. In the future, especially if given a larger project, with slightly more time, I would like to expect basic game development documentation such as a Game Design Document, a Schedule an Art-Bible so on and so forth. Rough outlines of these documents should be made promptly after the pitch. Even if the documents are rough outlines, the documents will be refined and expanded as the project goes through it's iterations. 

Personally, though this isn't directly related to the project, I didn't gain any programming experience from this project. As I was preoccupied completing and iterating on what little documentation we did have, alongside the placeholder artwork for the cards, I didn't get much opportunity to take Unity by the horns and check basic preliminary points off of the brief, particularly when attempting to have an inactive member of the team do some kind of work. However, I know that I definitely could have done much more work than I did, so in the future, I should actively seek out work where none seems present, not just trying to stay on par with the amount of work that others have done, but perhaps trying to go somewhat beyond that. Making scheduling documentation would likely help me accomplish this, and so I'd like to ask my team to get stuck into rough documentation early in the project. 



However, just as there's bound to be negatives, there's bound to be positives. It's one of the inevitable traits of game development projects. While I don't think that this project went exactly the way that I, not my team wanted it to. In general, the project itself after the deadline felt underwhelming.  

I believe that amidst all other aspects of the project, out team's play-testing most definitely stood out. I feel that our team's play-testing, when the game was play-tested went rather well. After rounds of play-testing, rules would always be  altered and shifted to suit the group's vision of the game, it was always a pleasant experience to see the game being played by others, no matter how bad the game actually was. Clearly, these kinds of on the fly changes can only be made swiftly with physical media, such as the cards that we were to handle. In the future, if I'm to make physical media I would like to uphold those swift rule changes after each play test. If I'm working with digital media, though it may be harder, it would only make it that much more essential that I watch those whom play the game and take notes on their answers to a given questionnaire or their behaviours in the game.


Whilst I can't say that I'm happy with the end product at the end of this project, I can say that I'm satisfied with the design experience that I gained from it. Working with a physical medium, such as cards, especially as someone who is familiar with, and enjoys games such as Magic: The Gahering and Yu-Gi-Oh, I found it interesting to develop a PvE card game. I also come out of this project with much more respect for designers of board games and the like. Overall, I'm disappointed, yet satisfied with the experience of this project.


Tylah Kapa



Project 2 - A running gag

Pitching an idea to your peers can be extremely nerve wracking, even though I wasn't the one speaking, I still felt the tension as we threw our brain children at the audience. Unfortunately, we hit a brick wall, our pitch was met primarily with confusion and criticism, and so we didn't get out of our pitch the feedback that we'd hoped for.

However, there were many lessons I can learn from pitching my ideas to my peers. First and foremost, pitch only the essentials. "Be ruthless with the information you convey." as it was so well put by my facilitator. These words reign true, especially when given a time-frame to pitch in. I made the mistake of thinking that, as a team, we should display that we had fallback ideas. My suspicions didn't get the better of me, and this make or break rule I allowed to be violated. In the future when I nail down ideas I will ensure that only those ideas are pitched unless I'm really up the creek without a paddle. Ensuring that your timed pitch is clear and concise is key. Which brings me to my next point.

Your ideas will never be as clear as you think they are. It's the reason why rule books are so robotic, and technical. Why that guy over in the corner always questions what you say, because you're not being clear with your words. This is also proven with a 5 minute pitch. Seeing other team's pitches concise, yet unclear really nailed the lesson. Some people just don't seem to understand, no matter how clearly you think you explained it. When pitching, keep industry lingo to the minimum, and time saved to the maximum. In the future, I'm going to try to script my pitches using less flowery words, or technical words, trying to write my ideas down in as few words as possible, while ensuring they still convey clear meaning. Which also runs into the final point.

Pictures! Pictures speak a thousand words, an age old saying, especially when you're  trying to explain how your board game will be laid out or the zones of your card games is set up. Diagrams will be your deities, even if you open up paint and slap some rectangles on a white canvas, anything that shows what your ideas are without words is a savior. When it comes time to pitch again, I'm going to be using diagrams as much as possible, no clutter, just simplicity.

Oh and the most important pitching tip. K.I.S.S keep it simple, stupid.

Tylah Kapa





Post-Mortem Project-DMCATakedown


After an extremely short week of working on this project, it's time to hang it up in favour of something somewhat more unique with more of, and new challenges to overcome in the future. In the interest of self-improvement or self-discovery, it's always a good idea to find the aspects of your project that may have gone very wrong or very right. 

To briefly outline the project, Project-DMCATakedown is a short, one week project that entailed the recreation of Super Mario Bros. World 1-1 with the art style of Bridget Riley, an Optical Phenomena artist. This project would attempt to retain the mechanics and level layout of the original game, only intentionally leaving out or altering mechanics if I believed that the artist's style called for it. 

The Bad

Considering how long I had to complete this project, and what I got completed in time, I'm quite satisfied with the outcome, and believe that I may attempt to refine it in the future. Though I don't believe that there were particular aspects of the project the went 'wrong' per se, there certainly were aspects of the project that weren't optimal.

Mario's movement mechanics were not fully complete/ true to Super Mario Bros. Because the project entailed the replication of the mechanics of Super Mario Bros., it would have been ideal to have these mechanics implemented properly. The exclusion of the polishing of these mechanics can primarily be boiled down to the underestimation of the scope of these mechanics which then resulted in a lack of time to understand them, affecting my ability to implement them. I realise now that if I'm trying to recreate mechanics or a player experience, I should look into the games mechanics and how they work in tandem to create the experience.desired. For similar projects in the future, I will prioritise learning the game I'm trying to replicate first with proper allotted time to do so, while still feeling confident that I can implement all of them correctly. This should be balanced out with other work on the project, such as getting a basic framework laid down, or placeholder artwork for the game.

Not all items/assets were implemented into the game. Super Mario Bros. World 1-1 holds various introductory game elements such as basic enemies, mechanics and items that are conveyed to the player via practical experimentation. I did not implement the Koopa enemy or the star item.  Whilst relatively simple to implement in concept, Again, I feel that this comes down to poor time management. A schedule should be made for the future, followed more strictly in addition, focusing less heavily on this side project I'm working on would be ideal, especially in the future, while working with peers.

The Good

Overall, I feel that this project was quite successful, I set out to this project with the goal of learning some more development tools, and feel that I did just that. My asset creation, with consideration for tone and player interfacing has improved somewhat, whilst my knowledge of the Game Maker: Studio engine has increased tenfold, alongside my knowledge of Game Maker Language. Aside from perhaps asset creation, nothing in particular went so well that I could hold it up on a golden pedestal. However, I do still believe that I learned valuable development tools and processes that will help me in the future. 

From this project, I can't say that I now know for sure what exactly I would like to do within the games industry. I've learned so much within the past year, only working on solo projects that I find it difficult to separate all of the areas of game development into specific sections. If there were three to four areas that I would like to work in, or enhance would likely be 2d and 3d asset creation, a broad knowledge of programming, focusing perhaps on shaders or player mechanics. These categories within themselves are vast, though that's about as specific as I can get at this point in time.  

Tylah Kapa