Maximize Your Learning: Code

One of the most important things a student or teacher could come to understand, is that learning cannot take place in a vacuum. Knowledge simply isn't retained without application. This is why homework exists kids, this is why most jobs will have you learn the trade onsite rather then just put you in-front of a screen with an instructional video, or rather, this is why you don't remember everything from that video or whatever they tell you on your first day, but rather you "get the hang" of it after a few days of being in the thick of it. Trial by fire.

That being said almost any video online discussing learning code will say, you can't just learn code, you have to learn code while making something. Which is.. obvious after the fact. But during it's a difficult and weird idea to wrap your head around.. like.. How can I make something when I can only attain the knowledge to first make it after I've made it. This sounds worse then the chicken and egg problem. If don't have the tools to make something how can it be that the only way to gain the tools is to make the thing?

TUTORIALS
And
The Stages of Learning that Accompany them.
Followed by
The Best Way to Learn From Them

Learning code stage one: No idea where to start

Now, the beginners answer to that is, look up a tutorial. But because often newcomers don't know how to do anything yet, they also don't know what they cannot do, or how difficult specific things are over other things. Or what the advice that guy on the forum post even meant; what are these Array, Global int. and if loop things they speak of?

Learning code stage two: You speak Latin, but your magic seems to work.

The ambitious amateur will often after a time of this learn to look up the very specific features they're being told about and watch multiple videos, and copy what they see onscreen into the program, often mistyping little bits and, not knowing what's wrong, getting frustrated to the point of starting over or quit.

Learning code the Intermission: It's-Not-Working-And-I-Don't-Understand-And-My-Career-Is-Over-Before-It-Started!

This last stage is unfortunately where most aspiring game devs get stuck and then.. well either quit or just stick with the excuse of "coding isn't for me, just can't do it." and then they focus their aspirations to working exclusively with art, writing, sound, design, or whatever small corner of production that looks as far away from coding. And there's nothing generally wrong with that path leading you to what you really love about video games, if you find you love being a producer or concept art, or sound, or animations guy more then you like anything else, that's fantastic. I'm just going to say don't let it stop you from making games. I spent years stuck in these last two stages of learning coding and years of unfinished projects and lost potential lessons because I let this pressure of never getting it to work or never finishing or not being smart enough, or ready to learn something, prevent me from making game. The important thing to learn from this temporary road bump in learning code is that it's one of those things that happens to everyone, and it by no way is a sign from above punishing you for trying something outside of your destiny, it's just a part of learning. You can overcome it. Honestly.

Learning code stage three: Learning in Application 

The best thing about stage three is you can jump to it at any point in your learning process; which does in fact mean, you are not guaranteed to go through stages one or two, you might just have the luck that you find the right tutorial and started with the right project and having everything fall together or apart in just the right way that you learned how to find your mistakes among the code, and the values of different functions and techniques of organizing data, and learned the math to make cool little features that do neat stuff. For some lucky people they stumble onto this stage in development earlier rather then later, but other struggle finding it. I think I've finally figured it out, it's not really a trick but i want to share it with you all because had I been told this years ago I probably would have some games under my belt.

1. JOIN A GAME JAM. Give yourself something external to pressure yourself into keeping at whatever tutorial series you're following and something that'll limit the scope of that project to something complete-able within a few weeks. 

2. INSTEAD OF GIVING-UP, FIND WORK AROUNDS. There's more then one way to skin a cat and coding is no different. Learning what bits are interchangeable gives you insight to the logic behind the specific function bits and syntax in your specific code. This learning feature by feature goal mindset helps you visualize and cement in your mind what the specifics you see in the tutorial are doing and mean within the program, having something constant to apply the short youtube videos to helps you understand the building blocks outside of the specific use displayed. It's like how learning to use a foreign word in a sentence is more useful then just learning a phrase that uses that word. 

3.OR JUST EDIT YOUR DESIGN. Good design is decision making that incorporates all elements of the work, it's not possible to see all the elements of the work before they're formed, so don't feel bad about throwing out the original blueprint you had while you're working. If the project you have doesn't look like it'll be as strong as this thing you thought before you started, go with the newer path you see it going. Especially if this new path interests you.

4. MAKE IT SIMPLE AND INTERESTING, TO YOU. If you're not excited or interested in working on it. Drop it. Nothing great has ever come out of someone who was only half paying attention, and no one has ever learned or remembers the lessons they learned from the school project that didn't interest them, also you'll make yourself miserable; don't let your hobby be something that makes you miserable. There were plenty of times I tried to make mini-games where the idea bored me but they were the only thing I thought I could make using the "beginners" level tutorials I found. And that's deeply frustrating because you want to make something interesting, but it seems like you can't learn how to make those things without making these boring games you don't yet want to make.

5. STOP BEING BORING AND MAKE GOOD SMALL GAMES. There is no reason for small or simple to equal dull. There are hundreds of small games out there that have limited coding and minimal design, that end up being interesting. These are the kinds of games you need to study. Try to think about all these simple features, and think of them in terms of what they could also do. This is where your design and creative skills pay off. You could do something interesting story wise, you could do something interesting art wise. You could just do something that's a kinda neat little mechanic. Just find something neat and small that excites you and make it, once you get that little neat thing, and you understand how you got it and what all your code is doing, then you've made it. Congrats kidos, you're a game dev.

THE BEST WAY TO "STUDY" A TUTORIAL

I'm a massive fan of the, follow with me step by step, line by line, regularly save and test to see if the code is working, kind of learning from tutorials. But at the end of the day, when you're new to a program and you know you're going to be referencing this tutorial more then once or trying to put your own twist on the feature you're learning to code. Backups and notes are a great thing. Now you can make a physical copy of the notes, which is brilliant, easy to access and good for following along. But what I've been doing that I've found most helpful when going through tutorials and organizing my notes/code. Is using something like google documents. I have a file for my code, a file distinguishing between each game program in that, and then i have files organizing between each tutorial, and documents for each tidbit of code with hyperlinks to that time in the video. 

This has been very useful for the long winded videos that near the hour mark, you can break it up into bits, with notes next to the label like, //establishing array in room, //global variables for array, // algorithm for bullet time, ect. This lets you start breaking down the large chunks of code in your head via their function piecemeal rather then trying to remember each step in the recipe as one massive meal you can visualize it as all the small bits of prep-work that go together creating the whole, which will make it easier to dismantle and use bits later to make other features.

Secondly you can copy the code down verbatim into your document so it can be copy/past utilized later for other projects, and you'll always know where it is, and be able to access it anytime you've got a computer. Having this with the hyperlinks to the section of tutorial explaining each bit eliminates the need to search through your youtube history or sit through the majority of the video when only a few minutes pertain to what you need. It saves large amounts of time and also gives you a space to store that new code function you just figured out even though you don't have use for it in your current project. Honestly I'd rather have a dozen small word document files with lines of code in them then a dozen or so versions of the same game because I don't know if I'll want to go back to an old build, especially when most of the code is exactly the same except for a few long coded functions. That might just be me, but I'd rather my builds be stored on the cloud where I can always access and edit them rather then on a single computer, or hard drive. I have lost so.. so many jump drives, and there's nothing worse then the computer bursting into flames and loosing everything you've been working on. 

And those are my tips to learning code the fastest, I went from almost never getting anything working after years of being stuck in the first two stages, to having a working understanding and building a game with my own unique twists that I coded on my own in the span of two weeks. All because of two things, I had a small project with a similarly small (achievable)scope and time-frame to make it in, and I was excited to make it.

That being said, I didn't have any art/animations, and there was virtually no story, or levels, so those are things I'm going to need to learn to do as well. Next time I'll probably have something up on one of those. 

ENTERING A GAME JAM

Short life Update

I'm officially only doubly employed, and in a much better position starting this year than I ended the last; and so I've joined a Game Jam. Because only being doubly employees with two academic essays to write and three custom orders resting on the work bench, I'm sure to have enough free time.

I'm using Tom Francis's "Make A Game With No Experience" youtube Game Maker series as a blueprint for my submission and between everything I'll try to keep track of my progress. 

This is just a quick post to help boost the My First Game Jam's signal and a little encouragement for anyone else looking for that extra little push to get them working.  

And because this is too short of a post I'm going to ramble some in the form of a list.

While I've never finished a project, there is some advice I can offer.

10 MISTAKES TO AVOID MAKING YOUR FIRST FAST AND DIRTY GAME

Or

10 REASONS THIS WRITER HAS FALLEN FLAT ON HIS FACE TRYING TO MAKE GAMES

1. REMEMBER IT IS FAST AND DIRTY

People new to game making fall into this pit without even noticing, it's knowing when to cut your losses and call what you have done. It won't be perfect, that's what Game Jams are all about, so don't worry about making it looked polished. Just like when you write your paper the night it's due, first get a completed draft, then work out your most egregious errors, and keep working away at those for as much time as you have left on the clock. Fix the game breaking bugs, play it though to make sure everything's triggering how it should, and slap something like art over the top of it.

2. FUN TRUMPS SENSE

You'll find alot of indie games fall into the trap of making a game "by the blueprints". Designing and writing events into the game because that's what the creator expects to be in this or that sort of game. Firstly it leads to a dull same-ish genre piece we've seen and mostly forgotten about, and secondly it leads to you accidentally plotting out something that is out of your league. The rule of Keep It Simple Stupid, has never been more applicable and the simplest you can get without fault is a game where, regardless of how short or how badly drawn, the play is fun. This is your first game, don't concern yourself what happens after the queen is taken, or why she's taken, or who you even are for that matter until you already have boxes onscreen that are coded to damage, jump, and follow each other around; and all of those actions are fun. It's a harsh lesson, but if walking and shooting, or whatever, doesn't feel engaging and responsive to the player, if the thing the player has to do in the game doesn't feel rewarding, nothing else can save that game. Do not worry if the dragon showing up makes sense until the act of shooting it is fun in itself.

3. FUN IS SIMPLE

Where rule 2. is "don't design the game before you have the gameplay", rule 3. is "Keep Gameplay Stupid." Complex code and mechanics will do you no good when you're trying to iron out gamemaking bugs for code you've just learned. You are new to coding, you are new to game design, you have a very quickly approaching deadline; look for the simplest game type to code with the simplest tutorial series you can find. The mantra of the gamemaker; simple to learn, hard to master, is your friend. Not just because complex inputs and mechanics take more time trying to animate and balance for your game, but because what you might think to be one of the simplest features is in-fact a metric assload of code that you are sooo not ready to tackle. If you cannot find a tutorial for a feature you want, cut that feature out of the design, this is not your swan-song, this is your very first game for a Game Jam. You can explore whatever features you want later when you've gotten the hang of making an actual game. Recognize what the bare minimum of what you want your players to experience and find what you need to do that, be prepared to simplify or change it. Walk and then jump, or shoot, or punch. Try to make something that only needs the wasd or arrow controls and then one or two other buttons, after that you can explore, even then I wouldn't until the enemies and game features like restart or exit are coded in.  

4.LINES ON PAPER

Art could very well be on your list of "things I'm not good at" but that doesn't excuse you from having to get around to making games. You don't need to wait for a fancy tablet or until you've taken art classes, you have the internet at your fingertips for one, there are more drawing tutorials then there are coding tutorials. And secondly this is a game jam, no one is expecting 3d models or photo-realistic drawings. The mind is an amazing and simple thing, just put two circles on a shape of any sort and image is suddenly recognized as a face. Make the circles a third the proportion of the now "head" and make one eye smaller then the other and congratulations you've made it cute. Now add any sort of other facial distinguishing features, like animal noses or ears, and you've reproduced the household aesthetic of a 5 something billion dollar title. Good art may be difficult to master, but art in itself is easy, forget whatever anyone else told you. As Garfield in his Saturday morning cartoon once said; "It's just lines on paper." The art should be as simple for you as doodling pixel art in paint, feel free to do just that in fact.

5.USE A TOOL YOU'RE FAMILIAR WITH

This isn't the time to be experimenting with a new image or sound editor, much less any new game creation software. Something you've already doodled or tried tutorials with if and whenever possible. This also means to know your design, and know when your tool just isn't suited for that purpose. Yes you could make a 3d game shooter with gamemaker or contruct, but the result is going to be comparable to The Mona Lisa made of Macaroni, impressive in it's own right, but it will always be just a lesser version of the original. 

6. STUCK WITH CODE, ASK THE DUCK

7. SURROUND YOURSELF
The upside of having all of social media a tab away resting at your fingertips is that, despite all of the possible distractions, you are able to 100% capable of mingling with your peers. You'll be able to watch other developers work and see their approach to problems, learn little new tricks that someone does with their code, or at the very least you can pick up the hotkeys and shortcut ins and outs of your program. The easiest way to keep yourself inspired in your craft is to surround yourself with others in the thick of their own craft, leave yourself little reminders of why you love doing whatever it is you do and witness others to keep that creative clockwork turning. You might have one idea for what to do to spice up the mechanics you got from this or that tutorial, and suddenly you see something completely out there done by someone else that gives you this awesome idea that was just so simple you don't know why you didn't do it before.

8. INJECT YOURSELF
It's never enough to just sit on the sidelines, and as long as you're using the duck method appropriately and not just coming to spam forums with questions as they arise, a community of craftspeople will just as gladly lend a hand with a question as they would gladly receive help when they truly need it. Everybody is there because they love what they do and they want nothing better than to hone their skills and have their work become as good as they can possibly make it. Do not be shy, it doesn't matter if you're still working on finishing your first, anyone whose had the experience of completing those first few games understands what position your in, especially under Game Jam conditions.

9. JUST DO IT
Yesterday you said tomorrow, ect. ect. There is no time like the present, if you know what you want to do, do it. If you know what kind of game or what tutorial you want to use, start. If you just know what you want it to look like or you're stuck after getting your basic movement down, start doodling, always be making something. I don't necessarily mean call in sick an lock yourself in your room. But build productive habits, keep to a strict regimen of so many hours a day, whenever you find yourself thinking of or figuring something out, don't save it for later. Get up and do it. If you can't do it, write it down in a notepad. It's remarkable how many game changing ideas you'll forget by the time you sit back down with the folder open. Plus writing the psudocode will help you work out in your mind how all the parts go together and make learning the code and fixing the bugs easier, the more familiar you get with your code the easier time you will have getting it to do what you want.

10. AVOID UNNECESSARY DISTRACTIONS

 ... It's a curse of the hobby to be on the same device we spend all of our leisure time on, but productivity is a habit learned through repetition like any other. Set daily goals and milestones to keep yourself on track and give yourself something to hold yourself to, when you get something done quicker then you expect move onto the next task, some thing will take longer then you expect and you're going to want all of elbow room you can make for yourself. It's great to be able to pump out a game in a week or two when you're chasing deadlines; but to do the work when no one is holding you accountable, when you're at home and ready to relax, that's the kind of diligence that makes a enthusiast or hobbyist into a craftsman. That being said, I'm going to jump back into the thick of it. Expect screenshots soon. Also.. don't do what I just did, if you're going to keep track of stuff kept it short, keep it simple. Screenshots and small blurb write ups if you need something to keep the creative juices flowing.    

Tackling Logic, and the Challenge of coding in "choice"

How does Story relate to Coding?

For pretext first we should discuss Ludonarrative, or simple the narrative elements inherent in the mechanics of a game. It's been discussed before on this blog, but refresher is always good. In the manner that all mechanical actions possible to the player are framed within a narrative act, the play is the story. Interacting with a game, in itself, adds to the game's narrative. This is most easily recognizable when there are different manners in which a player can interact within the world. This can be something so simple as changing which class your character is, or having player action lead to different outcomes for the endgame scenario; to the more vague and small moments of,  did Peach or Bowser win at the flower cup, or did Mastercheif favor the pistol or battle-rifle while saving the earth.

The point being that the mechanics of a game and the narrative of a game are inherently intertwined and cannot be accurately discussed separately, this implications of this as this article will explore, is that if the ludonarrative or playstory (story that's within the actions allowed to the player) has a poor narrative it leads to unsatisfying gameplay.

This isn't limited to the previous discussion of having each action lead to the broader arch as previously discussed; actions not for the hallow sake of themselves but for the overarching theme of the narrative. the previous point is what leads to the distinction of the "annoying mini game" vs side quests or moments of interaction that seem integral to the feel of the game. While Wind Waker is a story about a young islander fighting off monsters in island castles and dungeons, you can't imagine it without being able to sailing between islands. The sailing is an integral part as it's part of exploration.

There's the pretext, this discussion will be about instance to instance puzzles, and the problematic narrative of "choice" existing in what is ultimately a deterministic world. As always, the really hard problems turned out to be philosophy ones; and as always, philosophy has the answer... kinda. 

First we'll discuss a number of approaches to the problem and then discus the divergent instances that compound what appears to be the essence of the problem/solution. 

Que Sera Sera

Determinism is the belief that nothing that happens in the world could in any scenario, not happen. That whatever sequence of events is inescapable and unavoidable. This situation mirrors the reality of created worlds. In any movie or book, the events of the story will unfold exactly as they have before and always will. Similarly in coded worlds, they are integrally tied to the succinct and defined moment of the creator. While in philosophy this challenges most notions of freewill or purpose, in games it's more so an underlying challenge of purpose, but more on that later. In created or coded worlds the experience of the viewer or participant mirrors what the Stoics termed Eternal Reoccurrence. That everything that will happen, not only will happen and is inescapable, but has likely already happened before this instance, and will happen again in the exact same way in the future. Unlike most they did not believe that the inability to change the future would undermined freedom or freewill, because the event and the will linked to the event are separate things. According to the Stoics, if I'm destined to take a nap or not before I go to work, does not have any bearing on if I have the will to take a nap. This is known as soft Determinism. We see this in games in that no matter how many times you play the game the same events will be triggered as they are coded, and after no number of playthroughs can you avoid the hardwired series of events. Of course, this doesn't necessarily undermined hos satisfying the gameplay is, there are plenty of instances of games where there is no way to vary from the set path and yet the game still feels satisfying. Possibly the most famous and revolutionary exploration of this, is of course, The Stanley Parable.

Or, for a more 'on the nose' experience... 

If you haven't yet, play the game.

  The Stanley Parable as it's central gameplay gimmick, is the narrator dictating your movements throughout the game. This is first dictating your movements before they are enacted, playing with the notion of linear progression where the player is completely passive and has their will aligned with whatever appears to be the narrative, but then.. as the level design subtly tempts the player to walk off the directed path or investigate other corners, the narrator dictates the players rebellion. The resulting back and forth, which is really something that has to be experienced, is an exploration of the player's limitation within a determined medium and the very game's limitations within presenting choice. The game is a tongue in cheek in tongue in cheek in-.. spiral into oblivion. Yet while it directly plays with the ideas of player choice, and possibly undermining player choice, at no point in-playing does that choice feel cheapened. Let that sink in, in a self-aware determined 

environment, that makes it's determined nature blatantly clear, at no point does the player feel their actions are pointless.. in a game about showing you how your actions don't lead to anything "special".     

Divergence

All games have in a sense been tackling this problem, where what feels like a lack of player agency is in fact not conveying a sense of meaning behind actions. No player wants to do something "just because" they want to do it because of what it means in the game they're playing. The designer makes choices in gameplay valuable by making them meaningful within the context the game provides. When the choice is meaningful in terms of gameplay (powerup new ability) but not in terms of the story ( person dying = no change on the part of the player's mo) then we have that infamous diagnoses of Ludonarrative Dissonance, or in layman terms, "this part or acting in the game feels cheep, contrived, and just doesn't make sense". 

 Divergent options that viably allow the game to be played differently allow the player to control, have a sense of agency with, and give meaning to the emergent narrative their participation in the game creates. It can be something so small as jumping on top of a koopa instead of jumping past or as complicated as using a +8 great sword with knockback and larger area of effect instead of a +9 dagger with higher dps. Choices become memorable when they stop being the automatic no-thinking-required kind, when they become personal. This is what creates memorable gameplay, this is what makes experiences that stick with us. This element of participation in the emergent narrative of games is what makes video games such a uniquely compelling and personal media to its fans. It's why people end up relating so personally to video games, because their actions and will become a part of the experience-

Gahhh, yeah okay.

So, in the most clear instance of this, we have divergent stories. 

Divergent stories as I'm referring to them are the kind where a primary aspect of the gameplay and theme of the game is a value on specific player choices. This covers everything from the recent AAA's exploration of dialogue options that lead to multiple endings or multiple romance options, to open worlds where there is no specific order to complete mission before the end game, to the choose your own adventure novels of yesteryear. All of these explore the same effect of divergent path in play. The challenge and deciding factor of this effect is its logical presentation within the context. The presentation of the divergent options must be logical, they must follow from the situation of the world as a both sound and necessity to the story as an overarching experience.To break this down to it's simplest components, in a choose your own adventure book, imagine how the writer would create the stream of events. After you've gone the route of the wizard, how would it feel to have the character bludgeon a guard to death rather than petrify him or shoot lightning bolts? No, a thief must be allowed to try to steal, a barbarian to fight, and a wizard to spellcast. There's a necessity for all player actions for the game to present some sort of foreshadowing, something that builds the internal logic that leads up to each moment of player action overcoming the obstacle. When there has been little to no buildup, either because the internal logic is just assumed and taken for granted or because the developers simply couldn't be bothered, we have coined the term "game logic" or more specifically within the point and click community "Sierra logic". There are plenty of fantastical scenarios that occur in games without the blink of an eye, this isn't because we rationally assume we could do the fantastic in real life, but because the game has presented the fantastic in slow building manner that allowed our suspension of disbelieve to keep up with the internal logic of the scene. I do not believe it makes any sense to be able to control my momentum mid-air during a jump, but when I experience this in a game and then experience being able to jump off a wall, the realization of wall jumping is natural. And overcoming that puzzle feels satisfying. 

The same way that building any rich internal lore for stories takes a slow and complex build of internal logic, the emergent story the player creates through actions takes a similarly slow and nuanced build. Without this built suspension of belief at worst case we end up with sierra logic where the game is almost unplayable or at best where what happens on screen doesn't translate to the player as actions that are there own. As game critic and internet personality Arin Hanson "Egoraptor" put in his video essay comparing Zelda titles

"A puzzle is something you have all the information for, the only thing standing between you and the solution is your own ability to put the pieces together in the right way, the satisfaction you attain from solving a puzzle is from the A-HA moment. When the pieces fit and you only have yourself to blame for it. If you're missing a piece, how are you suppose to get to a conclusion a solution?

The satisfaction doesn't come from the door opening, it comes from the puzzle itself...

It's daunting, it's interesting, it engages you, and it's really easy to understand, and because of all this it's satisfying..."

Having all the information in this sense leads to the logistics problem of what amounts to the design equivalent of foreshadowing. Which, might sound impossible. How can a story in an emergent narrative seemingly foreshadow the end at the beginning when the end hasn't been "created" yet? Well, because it's already determined. Back a the example of the choose your own adventure, the key feature is that the story starts out extremely vague, which is perfect for establishing the first Blue Moon, the thing which is unbelievable but form which the player has their first step  into simultaneously believing, building, and being part of a fantastical world. the one crazy thing which all internal logic stems from. my personal favorite from fiction. 

In The Stanley Parable the game regularly plays with what is assumed to be a "reset" state, commenting on the last play through or braking the forth wall mentioning how everything will start over again and again until the player does as the narrator wants. It strings together what would otherwise appear to be alternate endings, separate stories, into a single cohesive narrative. What appears to be an impossible number of divergent paths all basically leading to the same "ending". How is this accomplished? This write up took much longer than I wished and I still have to get some sleep in before work. We'll take a closer look at different instances of gameplay that handle divergent paths next time. Until then; feel free to write about your favorite game that has alternate endings, romance, or dialogue options and why you like it or think it works in the comments. 

Pt 2

And here we go. Epoche talk 1

Here's the teaser for that project I was talking about... Alright I lied. This, as what happens with most of my projects on the drawing board. This is the cut down, hybrid, mutated, then twisted version of the inspiration of what the last project was. Simply because this one had less assets, less artwork, but more coding... Because I'm okay at the art but bad at coding... So.. for the first project I'm going to finish, I've given myself less room to work on the stuff I 'm good at, but challenged myself much more on the stuff I should start easy on... This first beta can only end poorly. But that's okay, that's what game development is.  So without further adieu, I'm going to talk about Epoche.

Epoche is a procedurally generated murder mystery set on a train. Picture the novel And Then There Were None meets the board game Clue, but set in a verb coin point and click.

(if you haven't you should really watch this film adaptation)

 

 

 

PLOT

 

The player starts out taking a trip, after walking around and chatting with a few of the other patrons the characters in the last three train cars realize the lock on the door has been broken and they are trapped to these last three cars. Soon after this the train goes through a tunnel and in the darkness one of the passengers on the train is murdered. From there it is a game of deduction and diplomacy to figure out who the killer is and have a solid enough argument to convince the rest of the passengers on the train. The catch is that each passenger will claim innocence, and you have to disprove their alibi to the majority of the passengers otherwise they might think you are the guilty party trying to shift blame. If you're just not convincing enough than the passengers will ignore you, the killer though, will probably take you out next. After that it doesn't matter if the passengers believe you. You have to figure out the crime within a certain time. You have roughly three murders to find enough clues at the crime scenes and from questioning the passengers before.. say he kills you. 

 

ALGORITHM

 

So the hard part of an Algorithm.. is the algorithm. I've got a list of features and what I have to do now is decide what I absolutely need to make this a functioning game. With a generated murder mystery it comes down to a balance of having clues that lead with necessity to the murder but not obviously, and leaving enough room for the player to doubt what they've found as happenstance, or even as a red haring planted by the murder to confuse him.

Learning AGS and Narrative (discussion of play, prose, and focalization)

Oh dear god this is hard.


The first thing I learned of design.. was that something simple is complex. Just because something plays really simply and is a simple design, doesn't mean it didn't take much to create. Trying to recreate a really simple game in a manner that's better, is like trying to reinvent the wheel. Try remaking something like tick-tack-toe, ya know, something that will fit the same market and could replace tick-tack-toe in the mind of it's loyal audience... you can't.

That's because every beautifully simple design, is ingeniously complex. It's complex in the manner that it is simple but still works so strongly. It is precisely the right amount of everything to convey what it needed to, not too much where it became confusing, and not too little where it became forgettable. Think of rock-paper-scissors, as much as people try they can't really add something to the game and have the game work smoothly. They might reskin it, have three other things besides the classics; but that's just aesthetics, that's not changing the design of the game. There are three options to each player, each option lead can only lead to one of 2 outcomes.
1. fail-state, which would automatically result in the opponent's win-state (and vice-versa)
2. stalemate, which leads to a replay.

These outcomes lead to split second strategic decisions with instant reward, the timed element builds tension, the player aspect makes every game feel new despite the fact that every outcome has already been experienced. The nature of it leaves the players on an even level. Regardless of what age you are you can still loose or win with the same likelihood as you always could.

My point here is that early designers incorrectly correlate the number of inputs and quantity of interactions onscreen to the quality of the game's play. This is a fallacy that's typically learned after the first or second project. While tangentially related as far as design goes; input, interaction, and play are completely different aspects of game. Input is strictly analog. Interaction is strictly digital response to input. And play is the neurological response (within the player) to the perceived association of analog input and interaction. I distinguish it as a perceived association because of the play we frequently witness with young players, or even just children in play. We constantly see players lean controllers one way or the other even though that has nothing to do with the interaction onscreen. You can place a unplugged controller in your nephew's hand and they'll watch you play, clicking buttons, thinking they're involved. (I'm not the best babysitter)

Of course during early development the nuances of analog controls (just like the nuances of analog motor skills) are lost on youngsters, along with the nuances of small game interactions onscreen. With this we assume the input->interaction->play is lost on youngsters, and they perceive it to be a solely passive (McLuhan Hot) medium like film, but this isn't necessarily true. The nuances of it are lost but the cognitive response is still there, the interactions we see simply highlight the importance of agency in the input->interaction relation. In a small experiment (I'm a terrible uncle) while babysitting I brought up my Atari simulator, turned on Combat2, and handed my nephew (1 1/2 year old) the second controller. Not expecting much and knowing the little one's love of pressing buttons, changing the channels, and seeing the change onscreen I placed everything within his reach (small television/console/both controllers) on a short coffee table, to see what would happen. I instantly regretted the game choice because the foliage covers a good part of the interactions onscreen, new players might not even notice what's happening for the first few shots.

Not to diminish the whippersnapper incidentally beating his distracted uncle a few times, the game did not last long as the small nuanced interactions onscreen were not enough to hold the youngster's attention. After exploring all the controller seemed to offer him, my nephew quickly began to experiment with the console. Which had the desired effects of turning on and off, then cycling through the games installed within it's memory. This illustrates a rudimentary rule of design; agency is established through clear control. The response of play is only as strong as the perceived association between the input and interaction. The interaction must be noticeable and a clear and direct response from the input. Imagine watching a game being played where you have no grasp of the rules, until you can make the link between what players are doing and the repercussions of their actions, then all you're seeing in-front of you is gibberish actions that have no correlation. To you it can't be played, you can't voyeuristically play that game because you have no understanding of that system (input->interaction). This is at root the inherent difference between games and film, games are constructed to convey the input->interaction system to a player (design is comparable to prose) where film doesn't have this interactive(cool, McLuhan) prose. This is why Let's Plays or Walk Throughs on youtube are popular with the gaming culture as interactive material related, instead of the film culture as cinematic material related despite sharing similar a visual language. While a mostly invisible aspect that's "under the hood" the prose of games and cinema are internally different, and draw the participant into a different neurological experience.

And just like if you don't recognize the system of input->interaction, if the interaction is inconsistent the game ceases to be. When kids run around the playground and point fingers going "BAM, you're Dead!", they have simultaneously designated input and interaction. If the second child laughs falling down, pretending to be dead, they have designated the output, the system is established. Even if they dodge, or run shouting "No you didn't!" they have established a system. Then it's a game, they've created play. If the second child doesn't react, then the first child is privy to either give up on his game, or to adapt it. Imagine the child that sneaks around in a public place pretending they're James Bond and imagines shooting down robots in the supermarket, or the kid in the back seat that pretends they're launching rockets out of their window, blowing up other cars. They have designated the game to be private and within their imagination, if a stranger sees them and pretends to fall down dead in the supermarket, smiling.. well typically at that point they just ruined it. That wasn't the game child was playing first, second they didn't invite this weirdo to play. It might have similarities and be a game, but it wasn't the game being played. It's not that the player doesn't understand the system of the slightly different game of "shoot, and shoot down bad guys" but that interaction and output had a fundamentally different prose then "shoot, and imagine shooting down bad guys". The prose of the first was controlled internally and allowed a deep exploration of player imagination and narrative, where the prose of the second became a cooperative effort and drew more attention to the game itself and out of the narrative being experienced, this is why some kids suddenly get embarrassed when you jump in on their game.

-Jump next to sandcastle-

"So what-cha doing?"

-shyly sticks plastic figure in sand-

"Just.. playing.."

You're sudden attention draws their own attention to the nature and prose of their game, drawing them out of their play experience. At this point we've all learned the best thing is to draw the child back into their narrative, be a participant and not draw attention to their system by learning the rules, and responding as they decree is appropriate to the system. Let them DM. 

"I wanna play, what do I do?"

"OK, and you can be the dragon! You're over here, and you're like -"RAHH"- when the knights go inside the cave. Alright! But I'm the Green knight, you can burn my head, but I just don't die."

I'm Getting There! Jeez!

As I've mentioned games have an inherent prose of their own through the design and nature of the game. The elements of the games design, the input, the interactions, and the subsequent play are the prose of games. Game prose is the form of interactive language and game flow/feel, and same as linguistic prose is the form of grammar and flow. In a manner of speaking prose is the cellular structure of narrative. There is a rudimentary prose in narrative(storytelling) that is not directly specific to any medium (movie,comic,tv series, novel, painting, ext.)

This rudimentary aspect of prose, this universal aspect of story stems from the existence of the story itself. I am of the personal belief that every creative medium has the potential to convey a story, and might so inherently through the participation of humanity (but that's for another time)

What I'm referring to is what French Narrative theorist Gerard Genette, refers to as Focalization. The eye and voice with which the story is being told. Narrative is the recounting of a story, the fact that the story cannot be recounted without a manner of voice, or eye, or ear, or some other sense mandates that there must be -in a sense- a narrator as an individual that recounts the story. We borrow their eyes, ears, thoughts and actions; but not always directly, often a storyteller will distance themselves from the protagonist so they can establish elements like foreshadowing by allowing the viewer information the character isn't privy too. Or build drama by allowing the viewer more then one character's perspective so the viewer can be engaged on a larger scale. A young writers first struggle is commonly changing tenses when trying to change perspectives, which is understandable as timespace in any form of storytelling is a pretty weird,weird thing.

(I'd encourage anyone interested in storytelling mediums (especially visual) to look into Scott McCloud's, Understanding Comics, which has a brilliant section on this.)

I've always found it helpful when organizing, character events, time, locations, pacing, basically everything to think of the focalization (the eyes and mouth of the story) to be a character on their own. Even if the character is just a spirit that floats around the other individuals I've found it to be extremely helpful understanding and writing for the reader when I have a established character that's sort of a in-between for the reader to the fiction. Think of the narrator of the window into the story, now think of that window having some degree of character.

With this it's easier to focus the story, like an engineer removing useless or redundant parts, if it's imagined within the span of a single beings mind. Especially as the entire story has to fit into one person's mind. The narrator doesn't need to refer to themselves as a character in the story to have relevance in the story. Imagine the narrator as the person whose siting by your bedside telling a story to you. Someone who knows the story so well they could read it too you without any reference, and they chose to do it a certain way because of that. When the narrative isn't delivered in chronological order, it's sort of like someone telling you pieces that somehow fit together into a larger story, part of reading it and the experience is in figuring out why the narrator does that. Everything the narrator tells you matters, or sometimes with postmodernist-lit it matters that it doesn't matter. The same way in a novel the author won't write what happens to the character every moment of every waking day the narrator wouldn't turn around and tell you that, because it's irrelevant to the story the narrator is trying to tell you. A story with a strong voice is when the narrator has cut the fat and will only tell the reader what really matters about what happened, (or what the author decides what matters).

I am of the opinion that everyone is to some degree a natural storyteller, maybe not a concise or very good storyteller, but one non-the-less. I think it's something we learn through years of communication and through a kind of osmosis, or at least we gain the ability to subconsciously appreciate it. When we're educated to recognize storytelling, it's mechanics, and specific language we better understand why we appreciate the pieces we did. Hopefully we might even be inspired to make our own.

So I believe that to a sense people have a natural sense of thematic devices, plot, pacing, and the like. Stephen King did a interview on writing where he talked about one of his current projects based on a news story he heard years ago about some lady driving threw a store window to drive over someone. To paraphrase, King said that he always felt time was kind of like a sieve, you can't really get ride of the big important stuff. The "chaff" just falls aside leaving the "rocks" the things that just stick in your head and you have trouble forgetting. People have a sense of what is big and important, in hindsight it's always a little clearer what was actually the "big stuff" but it isn't like it goes away, but the point is people still have that kind of thing with them. I think everyone has a great sense of the moments that are big and important, and that as you gain experience storytelling and work on your craft you're learning the reason those things are big, and you learn to position those things in the light and shape the edges to get the best effect you can out of them.

At this point we've dug into a number of topics.
1. Simple systems aren't easy projects
2. The input->interaction system that produces play hinges itself strongly on a sense of agency in the player, without a sense of agency the essence of play is diminished and the interactive aspect of the medium takes a more passive tense.
3. Agency is established through clear control. The response of play is only as strong as the perceived association between the input and interaction.
4. This play dynamic is the prose of video games and ludonarrative. Similar to prose in literature being the narrative flow, the play dynamic in games are the ludonarrative flow/ the game feel.  (Pieces expanding on Ludonarrative A. B.) 
5. A story's Focalizatin is the aspect in which the narrative is being delivered. In a story the manipulation and treatment of the elements in that story's medium becomes an element of story itself. In film the angle and position of the camera are just as important to conveying the story as the dialog delivered. In comics the specific layout of panels and manner moments are conveyed mean just as much as the moments themselves. In literature the use of transitions, the inclusions or exclusions of segments, all focus the material presented. In games the use of camera angle, the interfaces, the analog input, audio or text segments, the general gameplay all create the aspects of narrative delivery. With any great story its specific focalization is necessary for the story to maintain its individual nature.
6. Humans are natural storytellers, in our understanding and mastery of elements of storytelling is where we learn to understand the natural strengths in a story and the best manner in which to convey that.

This was all about Ags  

The main reason I am always so emphatic that people who want to get into game design start small is not just so they feel the accomplishment of finishing a game and don't loose there passion to a overbearing project, but so that they hone their abilities to create good games and convey experience to the player. Games that use simple systems like basic platformers, basic rpgs, shoot'm ups, brawlers, point and click adventure, are all time proven systems with very limited focalization. The camera is set, the player can only do so much, the designer is presented with limitations. One of the first impulses of a new game designer is to take a game system and expand it's focalization; take a top down shooter and give it rts elements, make it rouge-like, multiple endings, character relations. This ends in a game that is jack of all, master of none, which results in a mehh product. Some indie game that tried to do too much without focusing on doing any one thing well. But when you have someone tackle something small for a while; whether it be your platformer, rpg, top down shoot'm up, card game, board game, Doom clone shooter, or your point and click adventure game.. well then you see someone produce clever and well crafted pieces. The reason for this is that a practiced veteran of a genre has the experience not just to reproduce the focalization (gameplay) of that genre, but has the experience to perfect(or better) their prose within the genre. They've come to understand the inner workings that make the nuanced decisions when designing interactions that result in a better end product.

I'm at a point where I've only been tangentially aware of the Adventure Game genre and it's elements, I've begun working through the Sam an Max series(one I've always wanted to tryout) and reading up as much as I can on design theory, puzzles, and story that I've found. As before the ags forum community has been very helpful and directed me to a number of resource blogs/aritcles/podcasts to check out.(listed below) My first attempt at a project had me realizing the cinematic sequential nature of ags games with their backgrounds and transitions so I invested in some books about comics... I don't know how much it was just an excuse, but so far the books have benefited me tremendously. 

I have a better understanding of angles and positioning with my backgrounds, my character design, and animations are stronger. I had heard it mentioned before but this work definitely is a must have for game designers. Even it most of it just reiterates something you've learned with experience, if you're into storytelling, there is a wealth of knowledge in here you do not want to miss. 

Of course I'll continue referring you guys to blogs that have been helpful, and better reading then mine (look to the right side of this blog). I'm going to continue writing, dusting off and resharpening my art skills, and start working out puzzles. With time, with experimentation and study, I'll start to figure out the specific strengths of the Adventure Game narrative. I'll discover the elements of pacing and storytelling within this specific genre. When I learn or find something that's helpful while I go along I'll be sure to put something up here for it. Until next time, thanks for reading, and good luck everyone :)

Welcome to the Program
-here is a great introductory series of videos to the program and all the basic coding you'll need to make your first game -  https://www.youtube.com/watch?v=1Ml_DR76Cl4

-here is more information on the Ags program scripting -  
http://www.adventuregamestudio.co.uk/wiki/Scripting

Focus on Design/Prose

-here is a backlog of the Blue Cup Tools podcast where Ags developers Grundislav and ThreeOhFour discuss game design and production with a heavy focus on Adventure games (shock) with a tasteful amount of divergence to other genres -  http://www.adventuregamestudio.co.uk/forums/index.php?topic=46193.0

-while at the time of writing this I haven't had the opportunity to read these, I've heard numerous reference to these articles on adventure game by genre enthusiast Ben "Yahtzee" Croshaw. 

-  http://www.adventuregamers.com/about/author/2157

-more by Yahtzee
-  http://www.escapistmagazine.com/articles/view/columns/extra-punctuation/10959-The-Magic-of-Old-Adventure-Games

YOU CAN GET THIS PROGRAM FREE UNTIL THE SECOND OF MARCH 2014!

http://www.yoyogames.com/studio/download

Typically a 35 dollar value GameMaker Studio is free to download.. Like right now. I'm no pro at GameMaker, but I've downloaded it an it's on the list of program walkthroughs I'm going to do. Get Studio now if this one catches your eye, if you're ever interested in investing in something it's always better to do it when it's cheap, and if it's free you should just do it incase, seriously. For those of you who roll there eyes at these programs and just want to get into the ground up programming world of game making, I do getting into Java and JDK eventually. Soon as I'm proficient enough with coding, but for full disclosure that really means as soon as I'm not juggling upper level courses with work.

Update on the game stuff. I'd love to say the first engine is complete, but it's not. It's simple a matter of understanding the rolls of in script functions and how they function (which is kinda funny in itself). Quality tutorials for Construct 2 are a little more difficult to find, I'll be putting up the resources I've used and a in depth of the game development soon. 

2014, The Year of Pies and Fingers.

With my first class of the semester just a few hours around the corner and a few elements of my platformer working I just wanted to take this time to throw out my game plan as far as game development goes for this semester.

I've decided to aim to develop three games this semester using the respective optimal programs for their development and record my progress and lessons learned here. One platformer, one rpg, one adventure game. Each using their respective suited creations software; Construct2, Rpg maker, and Ags. Each will only be using the most basic elements of gameplay from their respected genres that I can code without too much difficulty so I can focus on the design during development and come up with the most polished product possible.

Still, this is kinda nuts -for me at least- I'm a full-time student, have my game journalism column with Kevin along with my other duties at that internship, might help write for my friend's film journalism internship group, I'm getting a second part time job, and I've joined a band. But I'm still optimistic, second job is a every-other-Friday-or-third-shift kinda deal, my classes are basically condensed to two days through the week, with a one-class-easy monday/wednesday/friday, my other job is flexible, all of my classes are interesting, plus I've found awesome communities that can point me to tutorials and so far have been more than happy to give me advice and pointers on my work. The planets have aligned as it were. 

My aim is to learn as much as I can and develop my skills so that future design ideas can be realized more efficiently. The benefit of making a number of small games when first starting with a program to making one massive one is a stark contrast. When you spend half a year making a single(conservatively saying) big game it's going to take you much longer to distance yourself from the work and be able to reflect on it's flaws and missteps. You often hear developers talking about the benefit of having gamejams and having to fit some awkward random parameter in some genre they're new too. It challenges you and makes you think about the process and medium in ways you haven't before. The same way you hear writers often tell people the best advice they could give to a fledgling author is to read books that are out of their genre or style. Short projects that let you brainstorm on something completely new then see it through to completion without the time or luxury to spend time second guessing or last minute revising help build confidence, familiarity with working the crunch, and understanding of the development process.

And so in this fashion I'm going to be tackling a puzzle platformer, a turn-based rpg, and something in ags... just kidding it's going to be a point and click adventure game. I barely have the slightest knowledge of ags scripting and I don't have any Rpg Maker sofeware as of yet. But after fuddling around with Construct for a few days I spent today.. yesterday. Sunday, working on an engine and thus far I have

1. functional wall jumping

2. invert-able gravity 

3. button mashing type flying (broken double jump)

4. self destruct button (broken dash, soon to be fixed)

5. rotatable characters (no ai to have secondary character follow you around thus far)

But that's just one day. I plan on spending a week on each engine, getting what functions and place holder graphics I need working, and anything that's glitchy/unfinished/I-don't-like will be either removed or disabled from the code and I will use whatever I have to come up with a design. The design will be scaled on my remaining time, and as I plan on fitting these out across the semester the first two at least will probably be pretty small scale. There are really only two functional elements in the platformer right now but I'm getting a good arcade feel from it. Rpg will probably be a small mystery as that's a simple way to have a concise story wrap up at the end of a puzzle/dialogue session, it'd be rad if I had time to figure out a multiple ending sort of thing. And to be honest I have no idea what to do for the Ags and that's why I'm going to schedule it for last.

I'm not going to set any publish dates or anything like that for the individual titles. I just want to have a working beta of each by the end of the semester. There is the possibility that I will fall on my face and fail halfway through. I might end up with just three somethings that play kinda like games, but regardless of the physical product what I'll have learned through the experience gained as a developer will be immeasurable. 

Other great advice is have a good programming friend who can look at what you do and give you pointers, one I've chatted with mine and get those broken bits fixed I'll put up my links to the tutorials and include my own commentary on this platformer engine I'm making. I'm thinking something end product like Wario Land but with a gun.

Til next time, goodnight everybody and good luck with your projects. 

Gotta Walk before you can Crawl

Reverse That

So... learning pixel art and design. Code still looks like Russian to me. In what way can someone utilize and test their abilities in the design/writing/art section of game making without yet understanding the code, the very life blood of games? Well there are two possibilities, either A. you work with a team where the code is not your responsibility. This is good because you can hone your specific craft, the issue though is you are reliant on first a finished product to test your work in action and second forced to wait until a certain point of production. Games evolve as they are made and sometimes entire sets of art assets become useless if the design changes. What an artist or writer or designer wants, is to have something tangible to show their work. An actual game that functions as such to display their work, otherwise their craft isn't as well represented in portfolio (and obviously this is less the case with artists or musicians whose work can be appreciated separately) but design in interactive media needs interactivity. Even if it's just the menu buttons lighting up as your mouse hovers over them.

Option B. the artist/writer/designer can find a program that requires no code(or little) to create functional games and have at it. 

And that's sort of what we've been trying to do here. Find the easiest way to make games. Just to be clear, the truly difficult part -the area where a game becomes great or crap- is not in the tools but the creator. Card games are crated with paper and ink. Board games are cardboard, ink, and bits of plastic. The average Chess game is just made of bits of wood and cardboard, and yet that's been around for centuries. My point is the tools do not dictate the quality of the product. Someone can have the best equipment in the world for digital art and still come up with something that looks like junk. Back in the day graphic designers use pen and paper instead of illustrator and the existence of illustrator along with all of its tools have not lead to better graphic artists. 

Anyway, previously in a discussion I had heard Construct 2 mentioned. Previously I hadn't head of this program and at first glance figured it to be the same as MMF2, which dispite all of it's pros is still an expensive bit of machinery and therefor out of our running for "easiest to start making and learning about game making" contest. Ags is great and I'm loving the community, but there's still a decent amount of code required. It's inescapable. 

Or is it?

The reason I advise people use programs like MMF2 and (as far as my limited understanding) programs  like GameSalad, is because they have this sudo-code. Underneath it's the same code that makes any other game work, but it's broken down into symbols and an easily approachable interface. This teaches code logic, which if isn't later used to understand code in it's true raw form can at least bridge the gap between you and your coder when communicating in production. GameSalad is one that's free, but right now we're going to take a look at Construct 2. Or at least I am.

Here are a few games from a person I follow made using Construct 2

http://supajackle.tumblr.com/backlightbig

(personal favorite of his work)

http://gamejolt.com/games/platformer/hero-quest/16821/

(I get a bug with this one but idk, maybe it's just my computer)

http://supajackle.tumblr.com/PixelGame

http://supajackle.tumblr.com/post/45430588965/porterminus-a-spooky-rpg-by-supajackle

 Here's the link to their site where you can download the program. 

Great things one, the interface is easy to understand, it comes with it's own paint image editor which is also easy to grasp. Great things two, it starts out offering a list of templates to chose from, not just get a head start templates for making top down shooters, path-finding, physics, or platforms, but templates to make your game work on Facebook, mobile devices, ect. 

Personally I'm hesitant to jump onto another program, I'm trying to figure out two different programs at once. But really few of my designs are actually complex. Most of the ones I have now are just platforms or beat-em-ups, the big ones.. The ones that are going to take a while use Ags, and it'll probably take me the twice the amount of time to do the art then it will take learning and coding the thing. And with school and work, if I were to throw out a number of when I'd finish that game it'd be someplace in the years category, even if I weren't doing the coding. And while the payoff will be awesome until then the work will be rather slow. Not to mention this blog, besides the DeconstructionCraft notices how much can I say about a background having a bit more shading or a single line of code being added. Development on.. I'm just going to call it 'the Island' project will be slow, and I'd prefer if I can have more regular activity on here. I think I'm at a point in my "career" I just need to make games. Yes I have a group project going on and this big project of my own, but I need something consistent and easily completed. Ags would be my tool if it was more oriented for platforms or the like but it's not, and C2 is. With school coming up and other messes that require my focus irl I'm going to be posting for a while about Construct 2 with the intermittent updates on Ags and what I've learned there. Soon as I can figure out fraps(this is the kind of simple you're talking too) I'll start putting up let's draws or tutorials or speed production vids. But for now I'll just be written bits with the occasional screen-cap. 

Until then, good luck with your projects, and goodnight. 

So I'm making these things again.

So after not really being able to wrap my mind around code. I opted to step it back and start simple. Something I typically try but end up trying to sneak in more features then a program is flexible enough for. And by that I typically mean doing so meant a more code heavy revise than I could handle.. But I think I've found the right thing. And I think this might be the hardest thing for starting up designers (or those of us that have never finished a project on our own), you need to find tools that are simple enough for you to wrap your mind around using them to create your idea, and the tool has to look simple enough and be the least amount of threatening on approach that you don't feel intimidated and overwhelmed when learning.

I found Ags.

And I was draw to ags initially the way I am typically drawn to something.. it was free. Spending the time to download and drudge through the tutorials is some of the best time I've spent. And I say that as a poor, currently under-slept, not quite starving college student. It's break right now for Christ sakes and I can't get myself to sleep in. I'm super excited to have one of my old designs not only off the back-burner (as I now have tools to slowly coax pages of scribbles into sweet digital life), but not just off the back-burner, but to see the tools at my disposal and realize how very doable this vision is. Often with a design orientation, you get an idea for something --and any good designer will tell you, it's not the thing that matters it's the manner in which it works, that makes a truly good design-- and when you don't have any training or understand the vocabulary of how your pen works(coding; in a manner of speaking) then you have the assumption your grand idea isn't possible and is too complex mechanically. And that's what I had thought for the longest time with many of my designs, so what did I do. I focused on the gameplay, the input output relations with the player and the essentials of what really made something. Because if I could figure that, and break a game down to it's smallest components, and then possibly get myself to the point of building those components, then I could design a project solely around that singular component, and then with time build on new features learn and work up to an engine that I could use to build the stories I wanted to.

Once to build a metroid-ish/brawl platformer I started the designs for five separate titles that slowly scaled back the functions of the game until the one I started working on was literally two frogs that could either step forward or backward and were fencing with their tongues. Like a dive kick game, but it's step forward or step backward kick. Attacking while stepping forward made a simple straightforward thrust. A backward step with a attack would make a sideways slash that could parry a hit. That was it. You would go forward in an attack or move back to defend. 

And really, I'll probably end up using that same strategy to make my final products, lord knows it'd help fill out the empty file designated for finished products.

Any finished product is a trophy in itself

But my point is, it's nice to know that the set of stairs that lead to your dream projects aren't always as massive as you think. Dream accomplishments aren't nearly as impossible as we think, the tasks are actually very human and legitimately possible.

And, my goal on this blog now.. along with using it to help keep me honest and frequent with my internship writing. Is to show off how possible these dream projects are. I've always been a massive fan of Wolfire Games' marketing strategy of showing start to finish because I know how much that meant to me when I was first thinking of game design. That sudden realization that follows being introduced to your deepest dream activity as a realistic profession, "Crap.. this could be what I do. Even if I need to do a second job, I could be doing this. I could be making those kinda things." That realization that game design and creation wasn't... it wasn't something so out of reach, not a "I could never do that.." situation. And when I first saw those games being made, when I followed the squares on screen betas turn to polished alpha releases, all of that just got me so excited. I spent.. well I haven't stopped thinking about games. Not just as a retreat, or pastime like they were before, but as my worlds. Instead of retreating into a book or movie or game like it was a favored place to be comfortable and be myself in, I started retreating into these as if they were close friends that whispered hints and tricks about how to excite the audience, make them laugh, or make them care. My notebooks at school actually started being used.

BACK ON TRACK

So, soon as I pull together the braincells to figure out fraps.. (probably lost half the audience, I swear I'm not completely incompetent), I'll record myself working on this project. Possibly do a tutorial session about everything that goes wrong and how to trouble-spot where you're going wrong.. because I think I've run into almost all of the most basic ones and in trying to find what's wrong realized there isn't a single person on the internet who was simple enough to make the same ignorant mistakes I've made. Thus far I've figured all the problems I've run into by myself (I'm very proud). There will undoubtedly be more in the future. But for now I'm going to upload and dictate my design process, both selections from my notebook on how I'm mapping and keeping track of the perspectives. And mentions of what I learn, as I learn the AGS editor and coding tips and hints.

-My first error, which was one of the most frustrating, was the room I had created was unable to load the background image I had drawn for it. Which was frustrating because I'd go back and forth between the general settings and the image I had made because they were the same size, pixel for pixel; and the computer told me they weren't. The issue had been, of course, the room actually wasn't the same size as the general setting, this was because after I had made the first room I changed the general setting size. This was because I made the room, checked the size, looked at my image editor and realized I wanted it bigger. The rooms are built off the general settings but once built isn't linked to those general settings anymore. The resolution does not bend back and forth to my will in these separate rooms. So basically all I did was delete the room, remake it, and the image worked. That took me two days to figure out. I want you to see me in all my pathetic glory so when I have something to show and you're first reaction is "meh, alright.. that's kinda neat." You'll see how far I've come.

-And here's my coup de gras, or at least I hope it's the most facepalm I get learning this... Facepalm.. Facepalm Games.. that's what I should call my youtube development videos! You see you have to find a way to make it fun, you even have to make losing fun, with my history of game making, this is going to be a whole lot of fun.

My coup de gras was I couldn't get the inbuilt editor to draw walkable areas. I'd select every tool in the little bar, draw rectangles, draw line tool, draw pen tool, and all those other things.. I don't know what do.. But anytime I'd try to draw on the page it'd tell me that I couldn't do that, that I had the eraser selected. And I'd get very upset because I didn't. And it was saying crap about a properties plane, and I couldn't find what they were talking about. It made me very upset, but I had seen the light at the end of the tunnel.. this was possible and this design has been brewing in my head for almost two years, the functions I thought I couldn't do and the art-style had been brewing for four years, and that functionality was literally a number of months of work away. It was possible, I was just being ignorant, and I'd make it work. Enter roughly four days of doing almost nothing but fart around on my computer trying different things on the editor and having five tabs open looking through basic tutorials later I realized I had the properties of the room set on Walkable Area 0... as in no walkable area at all. Meaning I wasn't drawing.. which would automatically set the pen to a function that wouldn't work. 

  

No matter what you start learning, you will always start off making mistakes you will laugh at in the future. So enjoy it, realizing painful ignorance is the universe's way of making learning fun.

My next hurdle.. along with everything coding. Is to find a good paint program to get the kind of pixel art I'm looking for. So far I'm using Sketchbook Express 2011, and with some farting about I might be able to get the precision stuff that I want but right now the settings are giving a difficult to control --as it's designed for tablet and pen(a set i don't really have)-- and faded soft brush effect in the lines. And.. well I'm looking for more pixel accurate hard color effect. Plus this isn't a program everyone can download. So I've downloaded and will come up with a review for PixelStudio next post along with more on the Island.

Goodnight everyone, good luck with your projects. 

Game Design Needs Better Storytelling Pt1[E]

Author's note - So while writing a small essay for school I got on the topic of storytelling and while not wanting to vary too far from that paper's thesis I'd like to say more on the topic, so that is what this is going to be. We're going to discuss storytelling in games, popular narration mechanics in other creative media and how they can be adapted to an interactive media. Understanding these will give us a better perspective on how story can be delivered within video games. Now not long ago Bob Chipman -no this blog will not be entirely responses or offshoots of what one internet personality says, Bob just brings up good topics, get off my back- Mr. Chipman as the Game Overthinker put out an episode on the rather popular topic of developing video games into competent film. And because the video was pretty good and I'll be bringing up some of what is mentioned later in this discussion, here, give his blog a quick look and watch it.

MECHANICS

 In the Game Overthinker's video he addresses how for the most part games historically have been lackluster in the storytelling department, and he's unarguably right. Of course there have been a number of shinning gems throughout the years, and even within the media's oldest routes we've found ways through gameplay to translate real and powerful experiences, as an example I'm going to site the 1980's Atari arcade Missile Command. And if you'd like an explanation take a few minutes and hear Extra Creditz's argument on the topic of Narrative Mechanics. Of course this is may kind of small stuff to some of you guys, "Games can tell a story about an experience by having you act out that experience?"

But of course there's more to it than just that, if it was just that the addition of film level graphics and cinematography along with some amazingly detailed mechanics using dialog (morality/story altering) would have catapulted the video game medium into its own Oscar worthy level of appreciation. And we all know it's not achieved that yet, because every year games come out and the major criticism -second to technical flaws- are a poorly designed and executed plot or character experience within the game. The story is boring, the characters are one dimensional, gameplay does not reflect the story or character's experience, the only connection to an excuse of a story are poorly made cutscenes... We've basically heard them all, and the problem is we keep hearing them. Remember Dead Island and that tear jerker tease trailer they had, along with those terrible characters and plot they delivered? Actually the game was just pretty awful in general, I felt no shame in trading that back in for store credit at Gamestop, wish I had bought it pre-owned in the first place if at all actually. So something is broken and it should be fixed, as much as some people might believe it's doing away with cutscenes it's not. Look at Bioshock. That game is held up as a shinning example of how to ingrain story and plot into gameplay, and it does it through cutscenes.  

Video games are a medium all to themselves, the take lessons and borrow theory from others like literature and film, but are governed by completely different rules. most important, and noticeable, is that the player has direct influence on the speed of the games/story progression through gameplay. The bulk of their experience is delivered from what their avatar is able to or, in some cases more significantly, not able to do. The gameplay has to reflect the story because that is the part of the characters experience you, as the player, are directly a part of. And because gameplay is what players are truly involved and interested in game designers have gone with themes and a hand full of story forms that can be reflected through gameplay right off the bat. 

TANGENT DIVERSION: PULP FICTION

These kind of story forms that just jump right into the action are reminiscent of the pulp fiction of the 1890 - 1950's. "Pulp" referring to the cheap composite wood pulp paper that the magazines were printed on. These magazines were so cheap to produce and had so many different kinds of action packed high fantasy short stories they became thee cheap american entertainment and escapism (besides sports) during the depression era. This basically were (along with comics) the origin of geek culture as we know it, possibly even the origin of the 'Jock vs Geek' click divide that persisted so long throughout our popular culture. Within this largely experimental and new kind of literature some of the greatest writers of that generation were found, names that have spawned works that, through varying forms of media; have lasted generations, become literary classics, and even inspired classics outside of their own medium. Pulp's high fantasy, imaginative visual style was also a clear direct inspiration for early game design, spanning from the arcades and early consoles when pixels were still discovering aesthetic tricks to... well now.

BACK ON TOPIC: MAKING SHAPELY FICTION

I digress, game designers use a many of the same narrative mechanics used in pulp fiction to get the characters into the action as soon as possible to get the player into the game. I'm going to comment on concepts and material for these mechanics from a great book on creative writing by Jerome Stern titled Making Shapely Fiction. 

(content examples)

     This is literally one of the best practical resources for sharpening storytelling technique and execution I have seen to date.  Now all these concepts are within Mr. Stern's book, and I'm just going to summarize a few of the shapes so if his work interests you then seriously, look into it. This book is more then worth getting your hands on if you're getting into a storytelling medium. 

BEAR AT THE DOOR

All stories, despite length or content, can be broken down to simple narrative concepts. The distinct way that the creator decided to present their material and the implications on the story that result from that. For an example the first kind of story we are going to talk about is the Bear at the Door, this type is when the character and reader are instantly thrown into the action. Something is wrong and the a pressing issue demands the character's attention right away and in most cases is completely unavoidable. It can be anything from depression, or standing in the trenches with your rifle waiting to hear the whistle and climb over into no-mans land. Notice these kinds of situations demand immediate choices from the characters; the kind of split minute decisions that show the character's true believes and motives, how they react under pressure, the kind of things that are really under the hood.  The way the character handles the struggle dictates our immediate impression of the character. The same goes for video games; when after an opening firefight there's a cut-scene and we watch the protagonist goes to kill an enemy, but we see him stop and hold back, we know that even in the face of danger the character holds onto his values. 

The true meat of this story shape is the inner conflicts that arise in the face of the bear, it's the smaller more human problems that let us relate to the character. He can't bring himself  to become an executioner because despite all his training and the battle going on around him he's still the young man that grew up in that quiet suburban home. Our solider might have gotten into fights at school, but that wasn't anything close to this. Even though his family has always held up their nation's military and the concept of duty with such a high respect life was something completely different then duty or honor, it was sacred. Sacred in the way that never needed to be explained, and yet here he is. Fighting ultimately because more powerful uniforms have told him to, killing people considered enemies because they ultimately felt they needed to stop these soldiers. He realizes he doesn't really want to kill these people, but still has driven to because of his basic self preservation; they seem unyielding in their aggression and he doesn't even know who they are. So there is a pause when he raises his gun. Does he pull the trigger?     

The Bear at the Door is even more so true within gameplay and controls. Let's backtrack a bit, Atari's Missile Command -which is probably the best example of a Bear at the Door shape narration in game- from the start of the game you're thrown into the place of the only one able to defend the surrounding towns from the nuclear onslaught. Your decisions must be done in real time and instantly affect gameplay, every move you make effect the outcome of your small digital world. You are instantly interwoven into the full experience, your actions are the story. You feel the responsibility and guilt in the decisions and those emotions become yours.

Next time, Blue Moon and the Journey shape in games and what we could do to do them better.

Read onto Part 2