Rouge Type dev log Entry 2.5 Bow problems

Not a full update, just decided to organize my tutorial references for easier access. Plus having them here means someone besides me might find the resources they need.

Making a bow and arrow in an top down view posed a large challenge then just skewing the ratio and visual illusion, mostly because I haven't seen a tutorial that is tooled to incorporate all three; top down perspective, bow with charging shots, and a projectile motion. But I can throw them in a blender and see what happens; so what I'll want to do is figure my features and what I want the end product to happen and do the simplest version. Here is what I'm thinking.

1. Inventory compatible, ought be able to switch too your bow from unequipped and switch through arrow types easily. Easy version is just an inventory, bow equipped (y/n) and are there arrows(y/n)?

2. Aim to mouse point, the arrow ought be able to be shot in full 360 degree range; that's above, below, and at the level of the player character, this means a toggled 3 layer ray casting system that works together. Easy version is just a ray coming out from the player character and if there is a target in range maybe the player "locks-on" or something.

3. Charged projectile, player should be able to "charge up" their shots, and arrows should go farther with less projectile drop or ricochet dependent on how charged the shot was. 

See how these squares move about on a 2d world... and their arrows also look very 2d and make the world feel flat. I don't want that, I don't think I have to do it like that.

4. Projectile DROP

I've tested nothing with arrow drop yet, but here's a different one in case I don't like that other one. 

Okay, now I have that out of my system, back to the grind.

Rouge Type dev log Entry 2.4

REFINING DESIGN

Interestingly enough, I've been working with horses for the past few months and been refining the control design. The actual coding is much less impressive.

As I mentioned in Rouge Type One Step 2.0, Things are slow and I'm working on movement still. I'm using Friendly Cosmonaut's pixel perfect movement rather then Shaun's, because it works into the overall stretch goals of a simple growth/ time/ day night system that is an aspect of the main design. Right now I can't figure the glitch that makes the box draw itself rather than move and ghost underneath walls instead of colliding with them.

Base build will be in Beta when


1. Player Movement  & Action
Because I want to include a variation of ways to interact with the map because the more combinations of approaches to play the broader the options in replaying the game.
Kinds of movement are more important to consider than speeds of movement. If the player can run or walk only matters if there are times when both are the optimum option.

Consider this, on a big project maybe you'd see and expect 16 different vehicle types with customization and tuning options, but if every line of code counts why include 10 vehicles that no one will play with? On the same side why code an entirely new vehicle or action that will only be used once in a while? This is why the kind of movement rather than the speed should be considered, if their are 3 options of unlockable vehicles and the only difference is speed then only one is useful at any given time. But if the three move differently; then the result is the player perceives movement differently. Checkers is a different game than Chess. When you play checkers you are looking at the board and movement for each piece all the same, but on a game of Chess every piece matters individually from each other because you must consider the board from a variety of perspectives.

So sticking with that theme of approach and perspective changing what the situation is, we're sticking with classic adventure-game-platforming-puzzle-movement.
That means WASD controls
1.Crawl-walk-run
2.Climb up/down
3.Shoot arrow
4...And catch-all "interact".

Alpha would work include
1.Multiple weapons
2.Jump
3.Swim
4.Swing on rope
5.Mounted(on horse)



2. Level Spawn

The inspiration for what I'm looking to make with the level design comes from the likes of Binding of Issac. Zelda's lost wood segment, and Nuclear Throne.

Base build will include one homestead room that allows entry into the segment of randomly chained forest rooms, each forest room will have randomized placed exits to the other forest rooms(incorrect door will lead one or more rooms back), upon climbing to the top of the trees from any of the forest rooms there will be a vertical parallax triggered to bring a far off tower into view (as if climbing to a greater height and seeing the tower in the distance) The tower will be either in the north, south, west, or east quadrant of the canopy and only visible in the distance if it is daylight, or there is a light in the tower, or a full moon, or whatever.
The purpose of this is to create some benefit or value that can alter the difficulty of finding the tower besides simply changing the number of forest rooms the player must play through before reaching the tower, or what would be characterized as the boss level.

Tentative step after this would be to tool separate randomizing sequences with separate sprites to differentiate between forest dungeon rooms, cavern dungeon rooms, and fortress dungeon rooms.

Option 1
Heartbeast Vs1

Option 2
GmSkew Cave Generator

Option 3(pick me)
Heartbeast vs2



3. Enemy Spawn

In truth I don't want to even begin to tackle this until I've figured how the dungeon generators are worked out, most of the player's interaction with the enemy will be in the random chained rooms, how many I make and how they work together should be linked to the difficulty. I'll set the number of enemies and difficulty of sort of enemy to increase as the player gets closer and closer to whichever specific tower and enemy.

Hand crafted levels will always retain a better quality of polish then any procedural generated level, but what I can do is control how many and how close together the encounters are. The main plan is to aid a single item into the random spawn of the forest that will position the mobs and give them an origin point to operate from.

Beta draft will include a firepit in it's randomly spawned forest levels, the firepit will be in one of the more open corners of the level and will spawn with mobs around it, this will be the basis for where I test out the AI.

Beta will include
1. Mobs that rage while player is in view, chase after the player, attempt to inflict damage, and loose rage while player is out of view.

2. tentative next step at this point would be to build onto the base A.I. and include duties that they might be performing, for example one might tend the fire while idle, the other look for firewood, possibly forging for food (an option if I get the level spawning to work nicely with the farming segment.



4. Art Assets
I'm not bad spritework, but also I'd rather design and aim within my own capabilities. I'll at least gear my placeholder art to resemble a Zelda 3/4th's top down isometrics perspective similar to oldschool gameboy art. I might do a hyper simplified pallet, like Rougelight Or (again) something like Titan Souls.

As important as art is ultimately, skin without muscle or bones isn't a body, so I'm going to spend little mentioning the art during the bulk of the coding and testing process.

Entry 1285943

Dear Public Diary.

Progress on the forge/game have been slow, but promising.

The forge's new burners are up and running, though they are going to double my fuel cost, I should be reaching welding temperatures; ran out of gas before I got to run them long enough to bring it up to heat.


On the game front I'm shuffling hardware around so I can Frankenstein myself something entirely out of tutorials. The specific seasonal/environmental change feature I was hoping for I found in a tutorial on a farming sim that also has customization outfits and crafting, two other features that I wanted as a stretch goal, three birds with the same stone. I'm not sure but it feels I won't be happy with the movement until there is some kind of lock-on mechanic. A second mode for the camera that could bounces between targets.

I've decided on the separate control system for the riding/mounted play, something more akin to a tank sort of movement but where footing and terrain effect the speed and control of the direction of the player. Make it feel more like you're riding a jumping segway as compared to a motorcycle as most horse riding mechanics in games seem these days. Where the movement of the animal is a set distance above the ground and speed is consistent like a dirt bike driving over a polygon universe that has the wild west painted just above the surface. Making things like puddles and tall grass and other stuff into variables of the player avatar and avatar pet/mount would make strategic playing, like retreating into the thick woods, possible. Second varied distance from the ground, if the avatar feels like it never leaves the ground it feels like moving in a wheel, but when the walking and or running animations and sounds are done just right it feels good to go fast to dart about, I'm not one for utter realism, but I find gameplay loops feels more intuitive and satisfying. This will take testing.

Big read is too old but my newest computer can handle GameMaker Studio 2.0, now just re-install game maker and to code it all.

For the forge just means a new tank of fuel, I'll be putting photos of the knives I plan on submitting to the fair.

Until then, Good Night Internet.

Rouge Type One dev log Step 2.0

This are going to be boring for a while, keep your shirt on.


I believe I found a work around to simulate a Z axis; on the artistic side of development one of the tricks of making a jump animation is keeping the origin(the point in digital space the player character controls are oriented to) in a single spot and simply have the image moving farther from that point in each frame, run of the mill how to animate a jump stuff, so far. What I should be able to do to make the game react and properly layer the air born player character though is key some step events to the specific frames. Far as I know this is a bit of a backwards way of doing it, I imagine the physics are suppose to be coded first with the different animation frames keyed specifically to the physics of the game as they happen, rather then hiding the physics in keyed frames of the animation, but far as my knowledge of the program and GML goes there's no reason for this not to work. "It's not stupid if it works." Is one of my favorite sayings, so here's to hoping in this instance it -or it leads to something that- pans out for me.


My development philosophy is something between tackling the biggest crucial elements -which without the project would fail- and tackling the monotonous tedious tweaking and refining of the core game-play mechanics -which without polish the project wouldn't "play"-. These tend to be on somewhat opposite sides of the To-Do list, but they are both necessary to establish a foundation for the first proof-of-concept playable build. Because I can never make things easy for myself I have a notepad or two full of scribbled ideas for features or how I might be able to tweak enemy types, and weapons, and possibly how I might want to order object states for the AI; but first things first.

1. Movement
2. Shooting
3. Generating Map
4. Moving and Shooting through Generated Map

As strange as it sounds, considering jumping in this design is in actuality an interaction of animation frames with instances of contact with environment that I'll have to designate as on a different level of the Z axis, testing out that jump design is moved down to step 4. First I'll need a map and environment to be jumping on and moving around.

In other news I've updated the software I'm using, rather then 1.8 I'm onto studio 2, I guess it doesn't work putting new code for the new program into the old version.

Right now I'm on step 2.
I've put in Shaun Spalding's ds map weapon system, so not only does the moving square shoot, but it will be able to shoot and cycle through both hitscan and object projectile type attacks with ammo count, recoil, cool down, and other similar type weapon features. With this ds map system I should be able to cycle through all of the weapons I might want to add later. It's not an inventory system, but it's a foundation.

Before I start onto the Generating Map I'd like first make a charge up feature for the WeaponBow and to integrate a ricochet into the projectiles, Tweak the speed and cool down and such so it feels more like shooting an arrow.

Rouge Type One

My understanding of GameMaker, is rudimentary at best, so I am happily resigned to simply following tutorials to make my little projects and the games I imagine. If the reader has found this blog hoping for tutelage, abandon all hope. I will at most relay the reader to the tutorial I have used, and give example of what I have used it for via my own work. This blog is my project journal for what I hope to be a portfolio piece, using only code from tutorials, to exhibit my own musings on design, game feel, and level design.

I have Obj_Player in a step event coded movement,

//Movement
MySpeed = 300/room_speed


    if keyboard_check(ord("W")) {
        y = y - MySpeed
    }
    if keyboard_check(ord("S")) {
        y = y + MySpeed
    }
    if keyboard_check(ord("A")) {
        x = x - MySpeed
    }
    if keyboard_check(ord("D")) {
        x = x + MySpeed
    }

As learned from Tom Francis's Make a Game With No Experience youtube tutorial series, I'm linking movement to room speed so the movement can be easily edited from a single point in the code rather than changing the number of pixels moved for each W, A, S, D. Also linking movement to the MySpeed variable I should be able to link in later additions like power-ups or if I find it not toooo difficult things like mounts. What I'm trying to figure out now is something similar to a jump, however I might be able to simulate a Z axis while keeping the WASD movement.

More often the Z axis is simulated by a trick of layering, where and when the player character is drawn on-top or underneath other sprites in the environment, imagine if you will a glowing sphere. If the sphere is shown in a top down level moving ontop of high grass, it would be imagined to be at some height above the ground, floating, similar to maybe a fairy or firefly. But if the grass is drawn ontop, suddenly the same movement appears to be low to the ground, like some sort of glowing rat in the underbrush. Similar, if we had trouble making rodents or spiders or some ground enemy appearing as if they were not floating around midsection when they come to attack the player character, having them drawn behind the trees and underbrush, as well as having them trigger a rustle of the brush when they move past it would give them a very "grounded" feel, and would also give the world a very present feeling.

My issue is making a sense of gravity in a game view that typically has the player character locked to the ground unless there is a ladder, or a chest high wall to jump over, or whatever might trigger a climb animation. 

updates and that pesky rouge type project.

Pre-POST
Working nights is just as awful as I remember -go figure right- but on the side of tooling up for my blacksmiths and having the tech to fix the computer and possibly saving up for licensing or whatever has been good. Taking some time off school seems to have been exactly what I needed.


The game I have been working on, is a Frankenstein's Monster of tutorials, and it's hogpog construction has bounced through different computers and multiple iterations that started on the foundations of the buggy code. For anyone following along, the previous gamemaker project was based off Tom Francis's Make Your First Game, tutorial series.

That project was.... iffy at best. The player could shoot, the bullets would push enemies back and make them shrink until they died. The player upon taking too much damage would explode in a splatter of bits, that the player then needed to pick up before being able to shoot again. This last bit hadn't quiet, every worked... perfectly. 

My next goal was to design a project that would combine two or more tutorials to make a more dynamic game. This is more so an experiment in design than it is in coding, because I am not a programmer, this is to see if it is possible to design an engaging polished product that can deliver an hour or so of game play. Along with give me some rudimentary foundation to test out things I'm excited to explore testing. Like, how to simulate the arch and fall of an arrow on a top down and not profile controlled game, as in.. how do you make a Z axis on a 2d top down game such as Zelda: The Minish Cap. How the heck do day/night cycles work? Could those be expanded to seasonal cycles? How do inventories work? Better yet, how does equip-able gear function? There's alot of stuff in games that's actually quiet impressive when it comes to the development side. But we're going to follow along some tutorials and figure it out bit by bit ^^

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.    

Epoche Dev log: 3 The mess before the storm

It has been a while since I've put anything up on my ambitious first game Epoche, the idea of the project being to create a murder mystery where you a detective upon finding a murdered person in your train car must discover who among-st the other handful of passengers committed the act. Those of you who have found the other Epoche blog posts first might remember the brainstormed write up that included things like hunger or intoxication meters along with a diplomatic mechanic where your player must argue their case against the suspect otherwise be accused of being the murder themselves and loosing the suspect in the process, and a bunch of other fun but silly ideas that were bouncing around in the first stages to solidify what the game would be. Well I'm here to say that a good chunk of whatever you first dream a game to be or include, will not make it to the finished product, or even past the halfway point, this is not necessarily a bad thing, this is the sign of a refined design. No design of anything that functions well comes fully formed from that creative brainstorm, none. The most valuable asset to a designer and storytellers in general is the learned ability to distill and refine down the material to it's essentials while maintaining and subsequently enhancing the fundamental experience. Or, as I've heard it better stated in The Elements of Style.

Finding the underlining theme of your game and removing all parts that do not add to the players experience of that will make for that more cohesive game-feel that every design aims for. Easier said than done as that entitles understanding your piece from both a critical and creative perspective, knowing both how and what the game does as it does, something that comes out of years of experience... So don't make my mistake of waiting until your twenties to finally sitting down and working on your game, start now, start small, start making games. 

Start with pen and paper.

 (LOOK AT THE LACK OF QUALITY! LOOK AT IT)

Here we see the start of a pen and paper version of the game. The layout of the five npc's and their interaction cards are formatted and started. As well as a brief write up on how they interact over to the side, and how the tier system of interaction works within each murder. This is how you should start every game. Why? Because you need a physical representation to start really thinking about what all the numbers and mechanics will mean for you on the computer. Had I started just building I'd have a few months of broken code and if it worked in any semblance an unbalanced game by now. On paper when you're deciding how to do a thing and you write it down you don't feel bad about crumpling up that paper and starting over if you don't really like it, but when you've just made those assets or coded that function, or put together that level, you are more likely to let it slide even when you're not happy with it. You just are. You're more likely to tell yourself you'll get back to it later and that this is just the first draft and you can always come back once the game is done, which is more or less true don't get me wrong: but after the game is done you are more likely to not come back and not revise anything you don't need to. 

This isn't coming from personal experience but from every designer or producer I've ever herd interviewed they've always said that no game comes out exactly what the designer wanted, none, they always wanted extra time to come back and tweak or even redo entire levels that they didn't have the time or energy after completing the game to come back to. The amount of time and energy you save when putting hours in finalizing that design before creation rather than redoing build after build, is immeasurable. I say this as someone whose always burnt out of steam after jumping into a project without fully designing it, I convinced myself I have a general idea and a mechanic, but then after I get the mechanic or more often then not I don't get the mechanic working, I don't care. I realize my design was a slap dash toss together of chocolate and peanut butter mechanics that don't lead anywhere and I don't think it's an interesting game, because it's not a game, at that point it's a tech-demo at best. It'd be like randomly throwing foods in a blender, you might accidentally come across a recipe for something, but you've more likely just created nutrition barf that could have been food, there needs to be a plan going into the kitchen or you're not really making anything; you're just playing with the food. When you start with a basic recipe though, you have something in mind, you know how to start, you know what you need, and you save yourself hours upon hours of being in a position of not knowing if your food might kill someone or not. Plus, after you know what you are doing, and you've tweaked it into something you really want to actually create... you've found your path and you're more energized to do it, two of the most valuable positions to be in for a creator. I've worked out the majority of what I need about the mechanics and how the game is/work so I can make good with my attempt to code the first prototype, and while it feels like half the battle is done and everything could literally just fall into place over the next month or so, I don't feel tired with this project at all. I know I don't have every obstacle accounted for in that notebook of scribbles and lines connecting dots and numbers, but I know that I have a solid footing, and I know where the problems will come up and have some ideas of how to remedy them. That is an immeasurable advantage that current me has over the me that first started this project. 

Essentially...

This is the sketch in class I made when I figured out the games name and premise, a moment of, YES I NEED TO MAKE THAT.

I keep this old (what the game box art might look like) sketch with me and everything because I want to remember exactly what that dream image was like and how it felt when the idea for this game popped into my head. There were five different art-styles fighting in my minds eye and at least three different color pallets I've seen in other games, plus a ridiculous number of supposedly connected and dramatically important mechanics I wanted to put into the game at that point, but underneath all of this competing forms of expression the game idea was trying to make one experience the main point, a game that made the player second guess themselves. That sounds really weird, actually kinda lame out loud, but that's what I want to do. I want to make a hard boiled mystery game that keeps the player guessing, not just until the plot twist or even until the end of their first play-through (don't know if I could write something that good) but throughout the whole game, every time they play it. Like with Agatha Christie's 'And Then There Were None if you refuse to read the epilogue and you simply sit there, reading the book over and over again trying to figure out who was committing all of those murders. Like how in games like Dragon Age or any of the other games where dialogue is interactive and meaningful, where that feeling of importance and connection to the characters matters; what if you could make a game where you're judgement of the characters always matters? I wanted to remember how much that feeling excited me to start this, that little idea is what I'm going to hold onto throughout this project. Well see how it comes out.