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