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();

entity.accelerate(GRAVITY);

entity.update();

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

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.

enum State { STATE_STANDING, STATE_JUMPING, STATE_DUCKING, STATE_DIVING };

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

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

@JadeKapa

 

 

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 BAD 

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.

THE GOOD

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

@JadeKapa

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

@JadeKapa

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

@JadeKapa

 

 

 

Post-Mortem Project-DMCATakedown

Introduction

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

@JadeKapa

Project - DMCA Takedown

Recently I was tasked with merging the worlds of video games and art by integrating a specific artists' works with Super Mario Brothers world 1-1. For this project, I have been assigned to artist Bridget Riley, an artist born in 1931 London, England, and is most known for her Optical Phenomena (OP) art.

Untitled [Fragment 3/11] (1965)- Bridget Riley

Untitled [Fragment 3/11] (1965)- Bridget Riley

As seen above, in her painting Untitled [Fragment 3/11] it's easy to see the reason why her OP art is so well known. I feel that the simplicity of the work itself contributes even more to the complexity of the techniques and final product when it all comes together. It's clear that each dark line on the canvas relies on all of the other lines on the canvas to convey the true work. Much in the same way that a painter relies on their ladder to reach high spaces, if it weren't there the work could not be done. 

Untitled [Fragment 1/7] (1965) - Bridget Riley

Untitled [Fragment 1/7] (1965) - Bridget Riley

From here the only real question to ask is "How would anyone transfer this kind of art to world 1-1?" As Bridget Riley once said herself: "I work "from" something rather than "towards" something."(Riley, B. 1968) So I have these two things, Bridget Riley's works and World 1-1. If I were to successfully take this kind of illusory art style and transfer it directly into world 1-1 I feel that I wouldn't be doing the art justice. 

"My paintings are, of course, concerned with generating sensations, but certainly not the exclusion of emotion. One of my aims is that these two responses shall be experienced as one in the same." (Riley, B 1968)

To accurately replicate this style of thinking inside of a predetermined World will be difficult, I do however have the art style as meaningful justification for the use of illusion to trick the player. This kind of though process gave me the following palette and WIP tile set.

Project - DMCATakedown Tile set  (2016) Tylah Kapa

Project - DMCATakedown Tile set (2016) Tylah Kapa

As is quite obvious, the tile set does not utilise the stark white that Ms. Riley uses in her works. This was changed out of pure consideration of the player, as Bridget Riley's paintings ar already rather abrasive, to my eyes at least, having this scheme repeated and moving rapidly would be far worse. Of course there is much more I could to with this tile set, like try to incorporate the lines more into the 3D blocks, rather than simply a border and shading as indication. To have this properly done would take some time.

Project - DMCATakedown Ptototype  (2016) Tylah Kapa

Project - DMCATakedown Ptototype (2016) Tylah Kapa

Above is the work in progress prototype I have for this project. as you can see, the player character also takes on the same colour scheme, though has white eyes, so as to indicate the location of the sprite. my hopes is that the player won't have significant trouble seeing the player character, though the sprite is obscured enough for them to be hesitant of their movements and decisions. The red background will eventually be replaced with the opposing lines seen in the tile set above, however, for the sake of clarity I'm going to keep it there until all of the objects are placed. 

The creation of a simple prototype platform engine has taught me a lot about the way Game Maker Studio operates, and I hope that I can go on to use Game Maker for various projects in the future.

 

Tylah Kapa

@JadeKapa