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

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.