Dev-Day Episode 15: Down-Sizing

maybe the player character is too big.

instead of going through everysprite, and resizing them, i could just resize them with the object.

using a step event and just changing their xscale and yscale to, say, 0.8

0.9 actually gives me what i'm looking for, so i'll use that.
0.85?

i'll keep mucking with it.

i can layer my tiles on top of platforms.

that works.

Dev-Day Episode 14: Big Picture

having troubles with fullscreen, and window resizing in general.

i want the game to be player fullscreen on both big and small moniters, without doing weird things to the sprites.

i have the option to "keep the aspect ratio" selected, but it doesn't differ from full scaling.

here's a screenshot of the game, unaltered.

all the pixels are where they should be.

these two and from a resized game window, one is set to 'full scaling', the other is 'keep aspect ratio' respectively.

there's no difference.

...

after experimenting, those scaling options only apply to the fullscreen mode, and not resized windows.

interesting.

... back to tilesets.

i'm working more with the gray/blue bricks than the grey/green ones.

Dev-Day Episode 13: Creation

i'll be using this colour pallet to make the artsy stuff, besides the player character.

this pallet is based off of the NES's 52 colours, it'll be great.

i also drew up a little icon.

i think it looks cool.

i'll probably make more later.

here's some tiles i made.

Dev-Day Episode 12: Escalation

i tried everything i could think of to make the arm look perfect, but oh well, this will do.

the next task is to make to so the player character can walk up a slope.

this in particular will be challenging because of my collision code which stop the player character as it reaches and pixel of a solid object.

...

or, on second thought,

i'm looking at shovel knight, likely one of the best SNES inspired indie games if not the best on the market right now.

it doesn't use ramps, nor does mario, the classic platformer.

when you're supposed to go up in a diagonal direction, it's a series  of short jumps.

but the result could end up being the pace of the game becomes slower.

something to consider, but for now i'll avoid making ramp tech.

now i shall start, ART.

Dev-Day Episode 11: Influence

arm.

so this is made by stretching the sprite in-game 2 sprites actually.

i had a hard time getting the the sprite to stretch all the way without going over, so instead i made 2 'rope' objects.

one is linked to the player character and points towards the grappling hand.
the other is linked to the grappling hand and points towards the player character.
the result is they overlap.

however, a new issue arose.
when the grappling hand is moved around semi-rapidly the two ropes seem to separate, most likely due to some form of delay.

i'll move the code around into different step events and see if that fixes it, but if it doesn't i may have to make an adjustment in how the grappling hook works.

Dev-Day Episode 10: Hush

it's getting hard to keep up with this naming convention for these blog entries.

i'm starting to write this entiry before i begin work on the rope section joining the player character and the actual grappling hook.

the task is a little intimidating and could take a while, so i may take this project home to work on it more there as well as in the generous 2 blocks of infotech i have at school.

to do that i want to make sure dropbox is working alright, and i'm not sure it is, as someone else uses this pc and dropbox, and the folder is linked for some reason, but i think it'll be fine.

i saved the project under a new name, before it was "woah1", now it's "project new order".

...

so i tried to impliment this rope : (this one right here)

but making the game room a physics room messes with all of my pre-established code.

so that won't work, i believe i'll make something from scratch.

i don't know how to connect 2 different instances of the same object on opposites ends, to make a rope, but i'll find out.

Dev-Day Episode 9: The Backdown

there's a very simple rule to designing anything, K.I.S.S.
keep it simple, stupid.

what i'm doing with all these moving parts is not keeping it simple.

so i'm going to just remove the hand part from the sprites for the 'armless' versions.

...

and so after doing that, i have a product that looks much cleaner.

i did not remove the arm and cloak objects from the game, in case i want to mess around with them later.

so now that i have all the movement animations i need, i can move onto my next goal...

(a rope thingy)

Dev-Day Episode 8: Gain

walksprite.

it's much slower here than in game.

also you can see both feet, all the time.

i fixed that in game maker's sprite editor,

i'm noticing other things wrong with it, however.

when the sprite reches mid-step, when the static foot is right below the body, the upper body is lowered, but normal people have heightened upper bodies at that point in their step.

but it'll work, for now.

Dev-Day Episode 7: Remission

i'm really putting off having to make a walking animation.
so instead i'm making other things run smoothly, which isn't a bad thing.
and one thing i'm doing is the whole, armless sprites things.

it works, both facing left and right, except for the arm.

the arm works while facing right just fine,

see? looks good.

not so much facing left.

that's not how arms work.

that's really not how arms work.

i should be able to use my "facing" variable to change how the parts work.

and then, i'll buckle down and make a great running animation, one that matches the movement speed.

Dev-Day Episode 6: Renovation

first things first, i found the solution to a big problem i was having.

these, are the global game settings.

by going into the windows/graphics section, i have the option to turn off the "interpolate colors between pixels" option.

this means that when objects move, their sprites won't blur.

it's pretty great.

next, i did the thing with the 'armless' sprite.

it looks a little derpy here but it looks fine in game.\

she doesn't have a hand, because that's what the grappling hook is going to be.
her hand.

the cape was a bit tricky, it's made of 2 different objects, the bottom one's angle change at about half the rate of the top one, so the bottom one is always about halfway between the character sprite and the top part of the cape.

i'm still working on a running sprite.

Dev-Day Episode 5: Evolution

so this is my idle sprite.

and this

is my jumping sprite.

i plan to make the grappling hook the character's arm, so i think what i can do is delete her arm from the sprite, and the make a new object as her arm, which i can make stay on her body, but point towards the mouse, with math.

like this

it'll take some time to get all the code working, but i can get it done.

the walking sprite will be a little more troublesome, but i think i'll be able to do it.

the way spriter pro works is that be importing isolated images;

i can put them together in one animation, while picking some "key frames", and by making changes between the 'key frames' the program can make a smooth animation.

Dev-Day episode 4: Rising

so with the basics of of the movement and collision in place, i've begun sprite work on the player character, i already started work with that one sprite, but the tricky part is making the collision box work OK.

because the working sprite;


is a lot different from

the 'testing sprite'

the plan is to make the collision box the same for all sprites, this will help avoid problems like glitching into walls.

Dev-Day Episode 3: Beginnings

so, here's what i've already got done.

(click to enlarge pictures)

for the player object:

these are the variable's i've created for the player object, with the exception of "grabby".

"grabby" is a global variable, as it will also apply to the grappling hook-esque object.

the "jumpable" variable's use is mostly for determining whether or not the player object is touching the "ground", and therefore can jump.

this is the list of code in control of changes the sprites accoarding to player input and player object ability.

in general, "A" will make the player object turn left, and "D" will make it turn right.

pressing both "A" and "D" simultaneously will make the character face right.

this is my collision code, and it works extraordinarily well.

there are 2 versions of horizontal collision, one if the player character is on the ground, and one if they're in the air.

and there's also a version for vertical collision.

this version checks if vspeed is not  equal to 0.

in general, this code will detect collisions along the the character's predicted path in a distance relative to the object's speed, and complete the distance.

also, when the code detects collision below the object character, it will make "jumpable", "true" again.

and this is the movement code.

"A" move the player object left, "D" right.

pressing both "A" and "D" will make the player object stop moving.

both "SPACE" and "W" will make the player jump, assuming they are touching the ground, for that the code checks the "jumpable" variable.

this code also uses a piece of the collision code, to for the purpose of detecting if the player object has 'walked off a ledge', making "jumpable", "false", making the player unable to jump until they land again.

this piece of code is for activating the grappling hook.

when the mouse button is clicked, it will create the hook "obj_grabby_test"

as long as the mouse is held, the hook will follow it.

when the hook latches onto a solid object, a.k.a., when "grabby" is "true", the player object will move towards the grappling hook at a speed relative to the distance to the grappling hook.

for the grappling hook:

there are 4 parts here.

1, the sprite change section.

the sprite will change once it has locked onto a solid object, it will also rotate towards the mouse.

2, the controls section.

most of the controls for this object are actually stored in the player object, but for this, when the left mouse button is released, the instance will destroy itself.

3, the grabby fixation.

this will just set "grabby" to false when it's created.

4, functionality.

this detects collisions, and when it does, it will make "grabby" true, and prevent itself from moving.

when it does move, this makes it move towards the mouse at a speed relative to the distance.

Dev-Day Episode 2: Reckoning

it took forever to start today, and i wasn't to get much done due to rebooting the computer i use and reformatting it to the full windows 10 version, i presume.
but, tomorrow, i'll have my steam account, and be able to copy the programs i got via humble bundle, hopefully.
then i'll be able to get back on track to making the game i'm working on.
one of the programs i'll be using is spriter pro, to make the animation for the game.
one of the images i've already made is this idle animation.

i made this animation by creating separate images of each individual body part, and with the parts set to different layers, each layer can be moved individually.
a believe a similar effect can be re-created with Photoshop.
however, possibly unlike photoshop, there's two options in the artstyle with this program, vector and pixels based art.
i believe i will continue to use the pixel setting.

continuing from last year, i believe i will stick with gamemaker, as i already have the basics of the game nearly completed.
more on that later.

also, i'll need to look more into this, but gamemaker is compatible with html5 in some way, i believe you can export a game in html to make it playable in browsers...

... i need to do additional research.

Dev-Day Episode 1: Genesis

right now, things are still getting set up, and it seems like the school district doesn't want to make getting set up easy.
i signed into my student account, however due to restrictions placed on the computer, for some reason i was not able to access any of the computer folders, other than the documents.
i could not save or open practically any files.
to alleviate this, i've signed in as an administrator.
and after implementing zenmate, i was able to create a new blog.
it's great.

unfortunately, i'm not yet ready to start development.
i've been informed that the computer i'll be working on will in the near future be undergoing a sort of reboot, clearing most files.
if i to be securely working on a project, i want my work to be preserved.

but here's the twist, i've already started development, at home, over the summer.
i don't have much to show, except for working movement, collisions, and proven sprite changing code, as well as the early works of a key game mechanic.