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 ^^

Oh look it's 2019.

As neglected as this blog is I still like Blogger and the space I've cultivated, at least on this end. I'm excited to introduce to you guys my non-game making project, I've been working on this while trying to teach myself code and because physical products and builds are easier to show than buggy code; I'll be posting updates on that front here as well as my game project updates when I get them, essentially any photos or whatever I feel like fits here better then the fb page.

My goal for 2019 is to have an update at least once a month on the progress for my game. And depending how things go with RPF maybe make that project it's own blog bog. Back on the game front, right now I'm still using smaller projects to teach myself code, so expect little game jam type previews and unabashedly bad art.

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.