Wednesday, March 4, 2020

Rouge Type devlog 3.0 map is mazing but arrows arn't blazing

Wanted to give a quick update, learned alot following the farming tutorial, enough to get the first room started and mess with playtesting.

(great tutorial series, rather advanced for my level but still really easy to follow)

So, essentially I have followed this two part tutorial series, and a working randomized room. What I need to figure out now is how to make the randomize controller place enemies and other objects about the room, like exits and chests.

I'm not totally clear how I can plug in more random spawns in the room rn, so before I have a working project get stuck between another rock and a hard place I'm going to work on the bow and arrow mechanics. If I get  the particle drop on the arrows and then the inventory segments of the bow mechanics done I'll either explore the tile system again and see if I can get more items to load, if not I'll look at messing with the arrow physics. I still hope to have at least a rebound effect in the first open build, also being able to recover arrows would be very cool as well. 

Tuesday, January 14, 2020

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.

Saturday, December 14, 2019

Rouge Type dev log Entry 2.4


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
2.Climb up/down
3.Shoot arrow
4...And catch-all "interact".

Alpha would work include
1.Multiple weapons
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.

Monday, November 18, 2019

Mu ren zhuang (wooden post man) woodworking project

While I'm on my sabbatical from higher education I've wanted to keep with some school or class and so since about last winter I've started studying Wing Chun. To aid in my practice and because it looked like an interesting woodworking project, my dad and I have set out to build one of my own wooden dummies.

the following is our progress

*update; it's too cold to be playing out in the snow with my dummy, come spring I'll finish making his silly leg and turn the new arms.*

Wednesday, June 26, 2019

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.

Monday, March 4, 2019

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.

Friday, March 1, 2019

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,

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.