Here's a link to a build you can actually run on Chrome and Firefox!
Hi all, I've been sick this week, and busy figuring out some things for my upcoming move, so unfortunately there's no new build this week. I did, however, have time to look into publishing the game using Unity's WebGL platform. Expect the audio for certain sound effects to be a bit harsh, and expect shadows to appear jagged. I'll see in future weeks if there's anything I can do about that. Due to the inherent differences between web player and WebGL, there might not much.
As always, charge-up noise is by Javier Zumer, and is being used under this license. It has been edited by me.
Sunday, February 14, 2016
Sunday, February 7, 2016
Reconfiguring Wall Logic, and adding Warp Walls
(New Build is up here!)
This week I did exactly what the title says - I added a new wall type! Okay, it's not that exciting. I want to play around with a type of wall that simply teleports you to a set location. Not sure if I want to make it a one-way trip or not, though that could be interesting... I'm calling this new type of wall "Warp Walls." I now have warp walls and wrap walls, so it isn't confusing at all.
I didn't get to really play around with them since I spent most of my time reconfiguring how all walls work. I used to have the code governing what happens when a player (or enemy projectile) hits a certain wall on that player (or on that projectile, as the case may be). In other words, it was up to the player or projectile to figure out what it should do when it hit a certain surface. This duplicates code and is a bit counterintuitive. On top of that, it makes the player script and enemy projectile script longer than they need to be. When I realized I really wanted to have the code for the warp walls on the actual wall, I realized I should probably bite the bullet and make the change for all wall types. Hopefully this makes my code cleaner and easier to deal with for the future.
And as always, charge-up noise is courtesy of Javier Zumer under this license. It has been modified by me.
This week I did exactly what the title says - I added a new wall type! Okay, it's not that exciting. I want to play around with a type of wall that simply teleports you to a set location. Not sure if I want to make it a one-way trip or not, though that could be interesting... I'm calling this new type of wall "Warp Walls." I now have warp walls and wrap walls, so it isn't confusing at all.
I didn't get to really play around with them since I spent most of my time reconfiguring how all walls work. I used to have the code governing what happens when a player (or enemy projectile) hits a certain wall on that player (or on that projectile, as the case may be). In other words, it was up to the player or projectile to figure out what it should do when it hit a certain surface. This duplicates code and is a bit counterintuitive. On top of that, it makes the player script and enemy projectile script longer than they need to be. When I realized I really wanted to have the code for the warp walls on the actual wall, I realized I should probably bite the bullet and make the change for all wall types. Hopefully this makes my code cleaner and easier to deal with for the future.
And as always, charge-up noise is courtesy of Javier Zumer under this license. It has been modified by me.
Sunday, January 31, 2016
Getting a Move On (In more ways than one)
(New build can be found here!)
Hey all, sorry about not posting last week. I'll try to continue posting consistently, but I'm actually moving BACK to Chicago very soon, so things might get a bit rocky.
Speaking of moving, this week I decided to take the game up to 15 levels. The 15th level is brand new, while levels 12, 13, and 14 are earlier levels with tweaked goals and node-based movement added in.
I'm not sure how many levels I want the game to have in the end, but I'll probably continue to make several new levels in a week, then edit down. That's what I'll likely do for next week.
And again, the charge-up noise is by Javier Zumer, edited by me, used under this license.
Hey all, sorry about not posting last week. I'll try to continue posting consistently, but I'm actually moving BACK to Chicago very soon, so things might get a bit rocky.
Speaking of moving, this week I decided to take the game up to 15 levels. The 15th level is brand new, while levels 12, 13, and 14 are earlier levels with tweaked goals and node-based movement added in.
I'm not sure how many levels I want the game to have in the end, but I'll probably continue to make several new levels in a week, then edit down. That's what I'll likely do for next week.
And again, the charge-up noise is by Javier Zumer, edited by me, used under this license.
Sunday, January 24, 2016
No update this week!
This was a quite hectic week for me, and unfortunately I think I'll be taking Sunday off to recover. No update this week, sorry!
Sunday, January 17, 2016
Still mulling over casting. Also, moving things!
(New build is here! 12 Levels now!)
This post comes after a long weekend looking at apartments. I am TIRED! But feeling accomplished. Last week I settled on how I should be handling casting. This week I started making levels which took advantage of that, had some second thoughts immediately. I had an hour-long conversation with my roommate about it, and came away with the resolution to just ride this out.
Both methods produce very similar results, and it isn't difficult to change between the two of them. So I'll just continue to develop the game and see if I run into any problems that make me want to switch. Time will tell if this is a good or bad idea.
On the subject of actually continuing to develop the game, I added a node-based movement script to give objects some simple patrol movement capabilities. I feel it opens up a lot of design space, but we'll have to see just how much in the coming weeks.
As always, the charging-up sound is by Javier Zumer, and is being used under this license. It has been modified by me.
This post comes after a long weekend looking at apartments. I am TIRED! But feeling accomplished. Last week I settled on how I should be handling casting. This week I started making levels which took advantage of that, had some second thoughts immediately. I had an hour-long conversation with my roommate about it, and came away with the resolution to just ride this out.
Both methods produce very similar results, and it isn't difficult to change between the two of them. So I'll just continue to develop the game and see if I run into any problems that make me want to switch. Time will tell if this is a good or bad idea.
On the subject of actually continuing to develop the game, I added a node-based movement script to give objects some simple patrol movement capabilities. I feel it opens up a lot of design space, but we'll have to see just how much in the coming weeks.
As always, the charging-up sound is by Javier Zumer, and is being used under this license. It has been modified by me.
Sunday, January 10, 2016
Brand New Year
The latest build is up here!
Well I'm back to work on the game after taking a break for the Holidays. This week, I made a decision about which method of warping I wanted to use, fine-tuned that behavior, and implemented a slight tweak to an existing feature at the advice of a friend.
First, I decided that warping with a raycast oriented to the normal of the warp wall hit was the way to go. Last time, I detailed how I could either raycast backwards from the player, backwards from the surface of the wall we're warping through, or backwards from the player using a spherecast. They each had benefits and drawbacks, but if I raycast backwards from the wall I can actually make the player move in more interesting ways. Hopefully I'll have a new level or two by next week to show what I mean.
Warping in this way can cause the player to drift sideways slightly, so I needed to figure out a way to keep the player from moving too erratically in places where they're looping many times through two warp walls. In cases where the difference isn't too large, the warping will actually use a raycast backwards from the player - since that doesn't cause any drift. So I sort of hybridized the warping.
And finally, I used to have warp walls and bounce walls light up as you are charging forward, but a friend of mine pointed out that it makes so much more sense for this to happen when you're building up your charge attack (the double meaning of "charge" has been a headache on this project). Anyway, walls now change color when you're getting ready to charge, not while you're already charging.
And as always, the charge-up (see what I mean?) sound is a sound by Javier Zumer, used and modified by me under this license.
Well I'm back to work on the game after taking a break for the Holidays. This week, I made a decision about which method of warping I wanted to use, fine-tuned that behavior, and implemented a slight tweak to an existing feature at the advice of a friend.
First, I decided that warping with a raycast oriented to the normal of the warp wall hit was the way to go. Last time, I detailed how I could either raycast backwards from the player, backwards from the surface of the wall we're warping through, or backwards from the player using a spherecast. They each had benefits and drawbacks, but if I raycast backwards from the wall I can actually make the player move in more interesting ways. Hopefully I'll have a new level or two by next week to show what I mean.
Warping in this way can cause the player to drift sideways slightly, so I needed to figure out a way to keep the player from moving too erratically in places where they're looping many times through two warp walls. In cases where the difference isn't too large, the warping will actually use a raycast backwards from the player - since that doesn't cause any drift. So I sort of hybridized the warping.
And finally, I used to have warp walls and bounce walls light up as you are charging forward, but a friend of mine pointed out that it makes so much more sense for this to happen when you're building up your charge attack (the double meaning of "charge" has been a headache on this project). Anyway, walls now change color when you're getting ready to charge, not while you're already charging.
And as always, the charge-up (see what I mean?) sound is a sound by Javier Zumer, used and modified by me under this license.
Sunday, December 20, 2015
The Perfect Cast
(New build is up here!)
Hi! I didn't have much time to code this week, but I did have enough time to unravel one of the last mysteries to smoothing out how this game plays.
See, having solved (for the most part) the issue of getting caught in the middle of long warp-wall loops, I thought I'd move on to the next most annoying thing that happens when you play: not warping when charging at a warp wall.
See, the secret to this issue is what happens when you hit a warp wall. In old builds, a ray is cast backwards from the player in the opposite direction of movement. I liked this because it felt exact and predictable. If you're just hairs away from hitting the opposite warp wall with your raycast though, it can look like you ought to have warped:
But, as you see, that raycast is nowhere near the warp wall we want to warp to. This results in frustrating moments where you feel like you ought to have warped but you don't.
The solution is to use a different method of warping. I've thought of two options, both of which work to varying degrees:
Hi! I didn't have much time to code this week, but I did have enough time to unravel one of the last mysteries to smoothing out how this game plays.
See, having solved (for the most part) the issue of getting caught in the middle of long warp-wall loops, I thought I'd move on to the next most annoying thing that happens when you play: not warping when charging at a warp wall.
See, the secret to this issue is what happens when you hit a warp wall. In old builds, a ray is cast backwards from the player in the opposite direction of movement. I liked this because it felt exact and predictable. If you're just hairs away from hitting the opposite warp wall with your raycast though, it can look like you ought to have warped:
But, as you see, that raycast is nowhere near the warp wall we want to warp to. This results in frustrating moments where you feel like you ought to have warped but you don't.
The solution is to use a different method of warping. I've thought of two options, both of which work to varying degrees:
- Use a spherecast. Spherecasts work like "fat" raycasts, so they can be configured to be more or less forgiving as I deem fit.
- Still cast a ray, but use the orientation of the warp wall for the direction of our ray. In other words, always cast a ray which is perpendicular to the face we hit. This results in a lot of horizontal movement at times, but in exchange you will literally never hit a warp wall and not warp to another warp wall (assuming there is a second warp wall directly across from the first...)
This build uses the second method. See how you like it.
Charging-up noise is a sound by Javier Zumer, modified by me. Used under this license.
Subscribe to:
Posts (Atom)