Wednesday, February 10, 2016

Finite State Machine for Game Dev Part 1:The need for a finite state machine

Today I'm writing about a subject that's been on my mind for quite a while now, and by quite a while I mean literally years.I want to talk about state machines, how I became interested in them, how they are extremely useful for Game Development and more importantly how I came to create one on my to use in my games.

Even tough the subject has been on my mind ever since I learned abut them about 5 years ago I haven't got around to actually make or even thinking of use one for my games. Why? we'll several reasons, but the most powerful of all, every single implementation I could either find or come up with on my own was clunky, confusing to write,  even more confusing to understand and worst of all confusing to read when used; so in short by using FSM my code would get even more difficult to understand than without them! That's why I ran away from them on game development until now.

This past few days I've been working on a simple game with some boys and girls that should be done in a few days called: Ephimeral Body

"Ephemeral Body" Title Screen

So mechanically this game is nothing special, it's a simple platformer, way simpler that THE original platformer AKA Super Mario Bros. So we started working on it, the movement was done in a few minutes and then: we wasted hours trying to make the animations work properly! The characters would keep on walking on the air, or wouldn't play their attack animation at all even tough the event was registered or so many other animation problems that we didn't notice until our character stopped being a red square on the screen.

Something like this


Sure this might be all avoided with experience and maybe we were just pressured by the deadline to actually think things trough, but this is a very common issue that I've encountered many times in my life, even way back when I was just learning to code and naively tough I would make a Super Smash Bros. clone in a few weeks, only that time around it took me days to figure it out. And I'm sure I'm not the only one, some of my students wanting to make platform games fall into the same pit, and many of the indie games I've encountered even fairly polished ones tend to have this problem too.

So I tough to myself this can't be right. I began thinking about that finite state machine again, that simple yet beautiful mechanism that allows software designers to lay out the states of a system in a human comprensible way. It looks something like this usually:



Or more interestingly like this (more of that in next blog entries):



It's a diagram so useful for game design that I every time there's a game to be done that's one of the first things that begin to wander my mind with questions like How many objects would I need? What states would they have? What's their behavior? How do they affect each other? All of which can be easily solved with a what system design calls a state diagram.

And so I began working on simple extension that would allow me to tinker with state machines in a simple comprensible way, and after a few hours of work I finally was able to re-implement the work we had done and that ugly movement from above turned into a more fluid transitioning like this:

Much better

The most important aspect of this however is that this new re-implementation took me only a few minutes to code with only a few lines of code. That is of course after several iterations of the state machine's inner workings, all of which I will explain in this series of entries.

But for now that's it this. In the next entries I will explain what I was looking for in a state machine, how I implemented several versions of the state machine, all their advantages, disadvantages and the final version I decided to stick with and why. Next entry more specifically I will be discussing the use of a switch based state machine. So, until next time!

Saturday, January 31, 2015

Depression Quest

In this entry I'm gonna be analyzing a small, free to play game that I found on Steam: Depression Quest.



I first stumbled across this game a few days back and it immediately caught my attention. It's a very short story with the objective of making the reader feel in the shoes of a person struggling with depression, in the creators own words "we want to illustrate as clearly as possible what depression is like , so that it may be better understood by people without depression". I found this to be a very noble cause and certainly a step in the right way towards making games achieving more than just entertainment. However due to the nature of the game I've found some controversy regarding whether this should be considered a game at all.

In the next few paragraphs I intend to first, explain why it can and should indeed be considered a game according; and second, I will attempt to deconstruct it's mechanics to find what makes this experience what it is.

Before I proceed however I'd like to clarify specially that I'm not deconstructing this game in an attempt to diminish the experience; all the opposite. I believe that by deconstructing and analyzing games as this one I can go forward into understanding how to create experiences like this and thus create better games that are able to transmit important messages such as this one.



About the game:

The game itself is very simple mechanically,  it could be stripped down to basically being a text based story that uses hyperlinks to allow the player to choose the next course of action. The game starts with the next screen. 



It presents an introduction to the character's current state in life, as well as background information that's meant to give us a solid idea of the character's life style, personal relationships, etc. It is however in the next screen when we find a few more mechanics that help setting the tone the game is trying to achieve. Now this screen contains all the elements that make up the actual game experience.


From here it's quickly noticed it contains three main parts. First we have the text, the actual "adventure" that we're reading upon. Below that we can find a series of  available choices for the character to take. So far nothing out of the ordinary; however upon looking up the first choice it's not selectable. The screen above it's the first one when we are presented with choices and we are already restricted, and that is precisely the point of the game.

What the game is trying to achieve is to make the player understand that depression it's not a choice, people struggling with the disease don't get to choose the first option, because they simply can't and they express this mechanically within the game, effectively using the mechanics within the game as a metaphor for what the disease it's like.

Moving on to the next part we have three paragraphs that are meant to show things the current player's state. They define in this three sections three main aspects of the player's life, the mental state, the therapist and the medication state. 

I would like to continue further on what I think about it and how I think it could be improved, however this being an analysis rather than a review I will continue to deconstructing using a game design framework. But first, let's tackle the elephant in the room. 

Is this even a game?

To answer this question I had to go back to re-reading one of the first books on game design I read and that I fully recommend: Rules of Play.  As the books attempts to explain the most basic concepts on game design one of the first subjects it tackles it's precisely the question of what a game is. The authors of the books analyse and present the definitions of game as presented by eight authors. While it is a good read I will not get into the details of it and just jump right into the conclusion they reach in an attempt to probe Depression Quest can indeed be considered a game.

According to the authors of  Rules of Play "A game is a system in which players engage in an artificial conflict, defined by rules, that result in a quantifiable outcome"

Now let's dissect that sentence and try to apply it to Depression Quest.

1) Is Depression Quest a system? 
First of all we have two different approaches to this question. As a computer program it certainly could be considered a system consisting parts such as variables, procedures, etc. that make up the game executable. But more importantly Depression Quest it's a game system: it contains mechanics (as the ones I explained before) that serve the purpose of creating a dynamic experience that is intend to express a certain aesthetic.

2) Does Depression Quest have players?
While it may seem an obvious question it is still worth noticing due to the nature of the game that the simple fact that you can choose your own path turns you into a player. Take for example a book: when you read, are you 'playing' the book? Because the book it's certainly a system so, so far Depression Quest might as well be a book. Well... no, the main difference between reading a book and playing a game like this one lays in the fact that you get to choose what happens next. As  simple as it may be this small mechanic turns this in a completely different experience as you are no longer a passive reader, you get a word on what's happening in the story and you are left to choose the character's destiny.

3)Is Depression Quest artificial?
This is an interesting question. In the first screen at the beginning of this entry you can clearly see the text "(non) fiction". My answer to this question would be: While depression it's not artificial at all but rather a very real struggle for many; Depression Quest is indeed an artificial experience, one meant to artificially make you feel, a real situation. At the end of the game you are back to your normal life, you are not really the character you read about.

4)Does Depression Quest have a conflict?
Depression Quest, has indeed a conflict, it may not be as obvious as let's say Mario trying to defeat Bowser. It doesn't have an enemy to defeat or a location to reach. But it does have a conflict in the form of trying to tackle the everyday issues, in this case the conflict is all about you as a player trying to choose the best outcome for your avatar while limited by the effects of depression.

5)Does Depression Quest has rules?
At a very basic level, yes it does. Again, as this game genre has so much similarities to a book it might be mistakenly considered as a similar experience however looking back at the play screen we have at least one rule that serves the game experience, that is the fact that you can't choose some of the choices. Another 'invisible' rule is the fact that the more depressed the character is, the less choices you have.

6) Does Depression Quest has a quantifiable outcome?
Now this one is problematic, the short answer is: No, it doesn't. However in this point I have to disagree with the definition. While a quantifiable outcome may be a huge deal with some types of games; as games have evolved further we have many games that don't have something like that and still manage to be considered games. Just think let's say: The Walking Dead, Thomas was Alone, Silent Hill.

So. to sum up everything. I believe that despite it's serious nature and it's simple mechanics; Depression Quest is and should be considered a game, or as they put it an interactive experience, one that does a good job expressing it's point.


Classification

I would like to classify the game using an MDA variation known as MGD. More specifically I'd like to apply the 'types of engagement ' part of the framework.

In case you haven't heard of it. MGD similarly to MDA pretends to classify the game experiences by the type of experiences the game is trying to achieve on the player, for this purpose MGD uses 10 types of engagement types and  it's sub-variations. A game normally has two or three of this however there's one that's more predominant. To find out more about this framework follow the link. 

In Depression Quest case I'd dare to say it classifies as:

1) Drama:
More specifically as tragic drama. However I should make a note, I don't classify it as tragic drama due to the nature of the game but rather do to the fact that according to MGD, a drama based experience is "The experience or observation of the fates and fortunes of life." and more specifically tragic drama tends to focus on sympathy, which is what the game designers where trying to achieve.

Conclusion

I believe Depression Quest is a very good game that does a good job at what it sets out to do. As simple as the mechanics are, it's not hard to see trough them and the meaning they are trying to convey to the player, the fact that is a text based game makes it very easy to create the content of the game without having to invest too much time, money or resources. 

Still I believe there is room for improvement, while the main mechanic of the game does a good job expressing the fact that there are things you just can't do, as a player you reach a point where you ignore those options all together making it loose some of the effect it had at the first screens of the game. Same could be said about the three paragraphs at the bottom, their location as well as the fact that they are merely informative and don't really serve a purpose to the game make it very easy for the player to ignore them completely.

Finally, as an aspiring game designer what this games leaves me is: Simple mechanics when used to serve the game aesthetic feeling can have a huge impact on the game experience, especially when used as metaphors for what you're trying to convey. 

Sunday, September 28, 2014

Day 7: I made a game in 7 days

So final day is here! I was hopping to make some other small changes to the game but I don't wanna risk not delivering in case a game breaking bug appears so here it is finally I introduce you too

Action Average Joe



I hope you guys enjoy it. I was planning to have a windows specific compilation with Haxe but something went wrong with the compiler. So here you can play the flash version and open it with your favourite browser/flash player:

http://www.mediafire.com/download/40d4q75hrtwel4i/ActionAverageJoe.swf

Please let me know during the day if you have any troubles running the game. I hope to find out why the compiler won't let me compile to windows during the day so you can have a more decent version of it.


Please let me know your comments about it!

Saturday, September 27, 2014

Day 6: Almost done!

Man day six already! Everything happened so fast, today I used most of the day on finishing up the game graphics I needed for the game to be in a deliver state, then I took care of the sounds and the music and finally I was able to work a little on some small menus to navigate the game so you don't jump right into it, nothing fancy.

Well there's not much to be said at this point, the game works very well.. it's got a few minor optimization issues but they don't affect affect the gameplay so I think it can be delivered with them.

Last screenshot before tomorrow's release!



I'm excited to get your opinions on the game.




Friday, September 26, 2014

Day 5: Drawing all day

So.. I got most of the graphics done today! I still suck at drawing but I think I'm pretty comfortable with the result. Today's work involved some coding but it was just some minor adjustments to control the animations so it's not that much. That being said I'll just leave some random screenshots I took while working today. Hope you guys like it.







Yes I know I suck at drawing but let's see how this goes!


Thursday, September 25, 2014

Day 4: I built a lego house

No really I did.. well it's actually just the level that's made of tiny lego-like pieces.

Today was.. a busy day so I really didn't get much work done, but I'm happy with what I did, despite some few more nasty trick I had to make today the code seems to be working very smoothly at a constant rate of 58fps with a few drops to 40 here and there but nothing too serious.

I finally have some tangible changes to show! Check it out

The platforms are not ugly red rectangles anymore! Now they're ugly lego platforms! I really wanted to get done those damn platforms today because as you will discover in time they're not just pretty visuals, one of the game mechanics depended on the platforms working nicely and smoothly (which they do now).

So yeah.. to be honest this day I didn't worked that much on the game but I'm happy I could get at least that done. Now tomorrow the plan is to keep working on the graphics and maybe start to find some sounds! If nothing goes wrong I think I'll be able to deliver with no problems.

Oh in case any of you are wondering, and if you need it I'm using Piskel for my pixel art, why am I doing Pixel art? well as I said before I suck at drawing so it's easier for me to edit some small images pixel by pixel than actually draw the stuff, I'm not saying my pixel art is good, it's just.. the best I can do given my abilities.


Well that's it for today! Good luck to all my fellow developers once again! See ya tomorrow.

Wednesday, September 24, 2014

Day 3: Yes it backfired!

So day three already! We're almost halfway through the competition and goddamn it the decision I took of jump right into the code did backfire on me. As I said yesterday I wanted to use this day to finish up the game mechanics into a state of almost everything done, so I could concentrate on making the graphics and finding good sounds.

I think I owe you guys an explanation on my game. First here's another screenshot of the game:


Yes, that's my work from today, I know it looks almost exactly the same(plus some debugging windows HaxeFlixel provides) but I swear! I got work done today!.

My game's basic premise as I said on the first post was to keep on that fantasy of becoming someone or something else. So the main character(the blue square) who at first it was supposed to be a kid but now it's a toy as well can take upon different modules/powers/costumes that change his way to attack the enemies and sometimes even simplify his way to move across the screen (it's actually just one costume that does that but I don't wanna spoil the fun before you get to play it). The objective is to protect the little pink square down there(other toys) from the enemies and kill as many of those damn green squares as you can. Pretty simple!

Alright so the thing is, Haxe being an object oriented language and me loving object oriented programming I created something like this for the basic game structure.



And it was all good in my head.. until I had to deal with everything that makes my game work, things like: the collisions, references and cross references, bullets hitting enemies but not walls, keeping a count of every enemy that you killed.. all those tiny details that I generally plan ahead during the design phase(which I skipped on day one). So long story short.. I messed up! and I had to apply some nasty tricks to make it work.Like global variables and pointers that shouldn't be there and redundant method calls...and oh god the performance issues!

So what's the plan now? Well the issue it's not whether it works, but rather the way it works. I love the game as it is now form the player perspective, but from the developer perspective, it's a god damn mess. So tomorrow I'm gonna have to expend some of the time I had planned for game graphics on a little cleaning up of the code or otherwise I won't be able to fix future bugs that might appear or even add some extra characteristics.

So that's it for today! End of day three.. we're closer to the deadline minute!