The quandary that is room design

In game design everything is interconnected. Like a meal, you can't have as satisfying an experience if each of the elements on the plate don't compliment each other.

The game's use of Health or end states alter the way players move through the levels and how they approach situations.

And of course what are the objectives? That will determine how the player operates within the space, is there much backtracking? Do they break every crate and check every nicknack before they go? Does the layout give them a clear path, or branching paths? Is the map interesting to navigate, is it memorable, does it present a varied amount of situations, or is it the same stuff different room? There are alot of nuances to consider when designing a level. 

My inspiration for this current project, and a notebook that's now full of scribbled connecting squares, comes from a mental combination of the old choose your own adventure books, the zaniness of Dargon's Lair, the idea of these multi-faceted rooms, and of course a concept for a rpg influenced GUI I want to experiment with before I start coding the big project that will consume my life whole, garnishing olive on a toothpick and all. 

So the general plan is to build a handful of rooms that change over the course of the game, with multiple ways of moving about to reach the trigger for each, optional inventory items and character interaction. I like the idea of the player being able to completely ignore a quest or two because they don't like the character and want to give them the cold shoulder. I'm not going to give to much away, not because I'm worried of spoilers, but because there's not much to give away; but the general plan is to have a cast of misfit magical characters who guard a dungeon. The main character being a -captured and not always good at his job- thief who must now escape the levels of the dungeon. The immortal guards of which have become quite bored and disillusioned with the whole immortal guard gig, made a sort of game of their job in the hopes of keeping it from getting too incredibly dull. Hope to put up some sketches soon. Until then goodnight everyone ^^

Life update summer of 2016

I try to do these every so often whenever I've been off development or just having posted anything for a while. Just to give a bit of a heads up, show anyone I'm still alive, and haven't abandoned game development.

Last I posted I was working two jobs and trying to make some money on the side with projects, that's not changed at all. But I'm farther along with those projects and future proofing production. Some are definitely starting to show promise.

On the more "life" side of things in the life update. I'm still in school... seriously considering changing one of my majors.. which.. would help me in literally everything I want to do outside of academics, this game development/my side projects/ writing, ect. as well as make my academics something I might want to pursue as far as a career, but we'll see what that means with my timeline for graduation. But whatever, I work enough to cover school and don't exactly have much in the way of bills, which is good because after school and car and gas I never have much in the way of funds. I bought a more powerful pc.. but quickly broke it, and it'll need repairs.. but I can't afford that right now considering car repairs sucking up that chunk of change. But my laptop is still kicking, and I have projects that don't require anything fancy that I'm working on, it's all just up to me to learn code and room/puzzle design. I have a goal of one game this year. We'll see how that goes. 

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. 

Jam Log No.5

Wish you could hear the ricochet sound effects.

Using http://www.bfxr.net/ for all the sounds.

Camera implemented and basic bullet collision. What you don't notice is the character can actually walk through the walls at this point, just threw this in for visual markers of movement so i could tweak the camera code/player speed/ and view specifics until I was happy with it. Right now I'm attempting to code the enemies attacks/A.i. 

Realized I need to do this before I start working on the graphics. I do have a basic image for the aliens... but I remembered how I'll fall into this trap of making a hundred or so sprites before even having the code working, and I refuse to fall into that trap again. I'm by no means a professional artist and by no means have that conviction to let go of that "perfectionist" drive and complete the work. I had the problem back when I was studying graphic design, and I still have it turning in papers. Some day I'll learn it.. But the code is what the people experience in the end, and as a Game Jam much isn't expected of me in the way of either. I know given the time I can decent work with sprites, but I don't know I can complete coding the game as designed. That's my main milestone.. I don't have to implement all the levels, if it ends up just being a big courtyard with spawning blocks I'll still be happy, as long as they spawn and move the way they're suppose to. This post will go up in multiple parts, I'll add onto this post as progress/issues crop up, this is just an update to show despite my loss of progress to scheduling, I'm still in this. Five days to go guys.

Update 2

For some reason, the big enemy is invisible..

started brainstorming the aliens, like the color scheme, especially around the head, but not happy about the body shape yet. will need to work out more silhouettes. 

Update

Welp... the big enemies are still invisible, somewhere in my order of events the mind of the invisible monster destroys itself. Before I thought it was just invisible like when originally spawned, but the small hive mind of monsters that come out of it don't return... which, thinking of it now might be because I don't have something to in there to turn off their focus on the player.. brb. Whatever, that's still not working. Point being, I won't know if these is happening just right until I can see it interacting. I have to admit thought, I like how the code ended up having these guys converge towards the player, their movements are awkward as they fumble around each other trying to get closer to the player. I'll be fun to detail everything with nice animations and sound effects when all of this is done.

update

Wowza, that was an easy fix.. apparently... I had the little "visible" button for the big-enemy object unclicked.. don't know how that happened. 

Anywho now I can see what the problem is, first, the little mobs that come out of the biggie don't seem to be triggering their return, second the biggie is able to send out multiple waves, which isn't suppose to happen... not a bad idea though. This all needs some serious ironing. But it's getting closer to something that looks like a game.

Jam Log No.4

KNOW THY LIMIT

Welp. The things I know I cannot yet do has grown, and I have learned. 

Here is the most updated version, the array and weapon switch system was not working, try as I may I couldn't follow all of the tutorial and my computer couldn't let me access the download the source material so I couldn't even compare the code side by side to see where I went wrong. I also now have a bias against learning code from programmers. Nothing against programmers, but the curse of knowledge I've found in devs whose education/focus was in code, rather then art or design, was stronger. Of course I'm basing this off a very small sample size of tutorial videos I've seen on youtube, I know programmers whose education is in code that could probably teach me just fine, I'm just saying of the educational tutorials I've seen on youtube, coding taught from those who started elsewhere has been easier for me to learn from.

So.. again, I've cut back and improved a little on what I know works, I've lost a few days to work but I'm not too far behind. I'm going to stop trying to add in things until I get this working like a game rather then a mechanic test. Then I'll see what I can do.

The player can now explode and the pieces come to rest, now the difficult part. 

I've worked it into the code that the player simply changes to one of the pieces thrown, to avoiding having to label and follow each individual piece thrown from the character, the character is changed into one of these pieces separate from their specific generation. The tricky part is coding it so that, first; you are thrown from the site of contact as if you are suddenly controlling one of the smaller pieces of gore, second the players control of the piece is removed during flight, third any possible extra contact with the enemy will not trigger another explosion, and forth once landed the player bit will regain control to the player and be able to be destroyed again, where the second contact with the monster (after this explosion) will result in game end.... an awesome stretch goal would be that the explosion damages and knock-backs any enemies within a radius as well. 

ALRIGHT!

I got a good part of the tricky stuff that I was struggling with fixed, reason I was having such a hard time is because I had my variables set in the wrong place so they were constantly resetting instead of having them in coded where they'd remain static. Basic mistake, but satisfying pay out. So, what we have now is a person that shoots, can blow up, regain his pieces, and become whole again. While exploding there is a grace period where the player is invincible after that if hit before regaining their parts the player explodes and game over. For anyone confused how this ties in with the game premise as specified in an earlier post, don't be alarmed, that makes two of us. I thought of something cool I wanted to code, and ended up being able to code it, I'll be damned if I don't run with it. Probably somewhere in the same universe this game is the story about a newly formed zombie, fighting of those who accidentally resurrected him, the alien invaders. He's a gun toting mostly blooded patriot of his planet and he didn't much like his evening being disturbed. I'm going to do minimum colors with minimum style, because time constraints and animations are hard. I have placeholders for most of what I'll need but I'm going to bare bones it until I have the enemy A.I. up to speed and something like a level laid out and coded. Basics being, idle, shoot, run.. maybe a flashing idle for damage idk. I still have to make up this alternate enemy and then try my hand at this mini-boss idea. From what I have with the player code it shouldn't be that far a stretch. What concerns me is the specific instances.. The player, dependent on health, has different abilities. Some are so easy as changing the speed of movement or specific passageways being accessible, and that might be enough. But it'd be nice if each instance felt different to play, without one feeling better or worse then the other. What I might end up doing is simplifying the instances again, streamline the design. I was figuring a verbal count would have been nice instead of a number hanging in the top screen, but really... for what I have ammo is irrelevant. It's not about saving bullets, it's about getting to the end of the map in one piece... that is one whole piece.. all together. The hard part is going to be designing and coding each of those so they can stand up in play independently, and of course fixing some animation in time for that. I'll have an updated video later this week. Night fokes.  

Jam Log No.3

Where we left off.

Shrinking enemies and "vacuum" weapon

I would include more but what I have now is incomplete and doesn't work yet. I'm in process of phasing out the vacuum and all my other sucking and gun related code for this newer system that allows the weapon switch. Maybe when I complete this new thing I'll be able to work it back under the new framework, maybe not. It's to early to tell. 

Today wasn't as productive as I hoped, but I think I'm still on schedule. After tomorrow I should have the shooty situation figured out and then it's on to coding in the enemies and working out the animation code (combining this set with that action ect)

For now, I'm going to take a moment to grieve a loss.

Vacuum gun Mark1. You were fun while you were with us, gone but not forgotten. Lost along the trail so many ideas have ventured with their makers. While you might not make it with us to the end of this game jam, we will carry you with us in spirit. We'll see you in another life perhaps.

Until tomorrow, where maybe after work I can finish this and have something to show you all, I realized I haven't given much of the premise here. 

So here is  a link tomy DevLog on the Itchio page for this jam, check out the other indie's there while you're at it, they have neat stuff, and they actually update it.

Jam Log No.2

Alright, I think I'll do these once a night, show something recorded from the morning and then what I have before I go to bed.

I got the vacuum weapon working, mostly. It pulls the player forward and I've tweaked the enemy's shrinking so that looks right. I haven't figured.. or tried yet to have the "bullets" destroy themselves after a certain distance, but that will be after I work out this cycling problem.

I worked in the cycling system from this tutorial with minor alterations. The primary being that I put the code for the player object in a Step event instead of a Create event, the youtuber said this would mean whenever the player switched guns any amo on the field would change as well,  I didn't have this problem, the amo stayed the same. What did happen though was the weapon specifics were connected with the wrong weapon. And I'm stumped how this happened, it appeared to have been working when I had four weapons, but when I switched back to the planned 2 (remembering my habit of biting more I can chew) the specifics of knockback (or in the case of the vacuum suckforward) and the type of bullets that came out was switched.. without any discrepancy in the variable naming as far as I can see.. which is weird because I have it labeled so simply. Now this in itself isn't a problem I would just figure I have something in the Hud Object listed wrong so it pulls up the string differently or.. whatever. I could just rename them. But what's really the problem is if I switch to the other while there are still bullets onscreen it seems to massively tax the computer. The game freezes.. so... I'm going to have to delete a bunch tomorrow, back to the start where I just have the vacuum working.

There is more then one way to skin a cat, and if this way freezes up the game it's got to go. I've got other tutorials for the same feature opened in tabs and I'll give them a shot tomorrow, at the very least I'll get enough of an idea of how to deal with global variables and strings that I'll be able to figure it myself, and if not that, then I guess the game doesn't need multiple guns. Plan tomorrow is to strip the game back to it's working version and finish working on that boss character. I have two related monsters and I'd be tickled pink if I could get them to connect the way I want, a variation on your basic big guy explodes into small guys. And if that doesn't work it's onto plan B, or I guess it's C, with the monsters and focus on these weapons, with a new stretch of QTE finishers.

Jam Log No.1

Jam Log No. 1

(apologies for the shotty video quality, grabbed the first free screen recorder I could find)

Note to self, do not save code unless you know it works. I have no idea what's going wrong with all that code I wrote up and saved the other night, I plugged it in and going through bit by bit worked out all the little mistakes, capital where there should be an under-case here, a misplaced bracket there.. ect. And each test seemed to work fine, it'd compile then tell me where there was an error. but as soon as I thought I had all that, having combed through all the additional code and fixed what I thought was the last error, the GameMaker runner hit a snag. As in, no code error, but the runner shuts down whenever I try to run the game. I don't know what I did. And I can't find what part of the code is responsible if it is that. So.. I started again. I have basic shooting and movement, along with basic "don't walk off the edge" a.i. for the enemy. Soon I'll be deviating from the tutorial, and the trial by fire will commence.

(little better grasp of the program now, mousepad is fickle but everything working smooth)

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.