Music generation system works! And the fix was easy, if annoying. I just had to pull the missile tower out of the shoot-tower and make them have a different firing method(since they "Swap" who's playing which note, and use a static variable to keep track of it instead of each having their own)
And I tweaked the graphics a bit and added a bit of noise, so it gets that nice dirty "old screen" look that I'm going for.
The only problem is that the towers are a little hard to make out now... I might have to either put a simplified mesh in there with transparency just to sort of give it some space, or re-do the meshes for the towers.
Didn't you say your bass towers play every other note?
Yeah those are the missile towers.
Before they were still ShootTowers, which play when the sixteenth they're on is >= their note's duration * fireRate. But I had done some stuff with overrides and statics to re-do the MissileTowers to fire every other one(The first tower was advancing the shared counter, and then the 2nd tower was just overwriting its instanced sixteenth counter with the shared one), which worked fine unless the downbeat was an eighth note, at which point it would play two sixteenths. I think it's because it was still running the base advance() from the ShootTower before overwriting it from the static shared sixteenth counter. It wasn't a problem when it was the 2nd tower doing it or if it was longer than an eighth, because it would correct after the first sixteenth advance().
The solution was just basically to copy the advance() void from the intermediary class, and then have it only advance and track the static shared sixteenth counter. And then of course remove it from the ShootTower and only have it inherit from Tower.
Again, easy fix, just annoying after having set up all the ShootTowers as ShootTowers specifically because three tower types behaved in the same way, only to have to re-do it because it turns out some of them don't.
Does anyone have any experience creating a control config menu in Unity?
XNA had lots of stuff pre-defined, and it was easy to figure out which controller an input was coming from. It seems harder to detect and configure things programmatically in Unity instead of the Input Manager pane in the editor.
1.) Can I programmatically determine which controller is being used, or do I really have to define a series of axes for d-pad and sticks for every controller index?
2.) Is there a comprehensive way to detect what keyboard key or gamepad button has been pressed in order to assign it on a config screen?
Does anyone have any experience creating a control config menu in Unity?
XNA had lots of stuff pre-defined, and it was easy to figure out which controller an input was coming from. It seems harder to detect and configure things programmatically in Unity instead of the Input Manager pane in the editor.
1.) Can I programmatically determine which controller is being used, or do I really have to define a series of axes for d-pad and sticks for every controller index?
2.) Is there a comprehensive way to detect what keyboard key or gamepad button has been pressed in order to assign it on a config screen?
Without going third party, you have two options with unity regarding multiple controllers. Either accept input from all controllers (single player) or define each controller separately (multiplayer).
Unity has Input.inputString which returns all of the keyboard string input entered that frame, but that's only keyboard stuff. If you want to do your keybindings in default unity input manager, you probably have to define them all by hand, or at least check for each gamepad button and mouse button before using inputstring to check for keyboard input.
That being said, it looks like in unity you can request input arbitrarily without having to define it as a named axis in the unity input manager. I'm not totally sure this helps you but it is useful if you're determining by button press which out of multiple controllers should be considered "first player"
Also, there are at least a couple tools available for download which are replacements for the input manager that attempt to rectify some of the interesting decisions they've made.
Usual caveats apply: made in 3 days by mostly 3 people (with a little help from 2 more on the last day), so yay! Theme for this one was "Spring into the Future", whatever that means! I think a robot rabbit jumping around counts, right?
That being said, it looks like in unity you can request input arbitrarily without having to define it as a named axis in the unity input manager. I'm not totally sure this helps you but it is useful if you're determining by button press which out of multiple controllers should be considered "first player"
Also, there are at least a couple tools available for download which are replacements for the input manager that attempt to rectify some of the interesting decisions they've made.
Thanks for the response. :-)
I'm definitely angling for a multiplayer mode down the line, so the "all controllers" property wouldn't work for me.
I've seen that link, but the problem is that I can't figure out how to get dpad and sticks via that method. I can for loop over all controller indices, but I don't know the corresponding string to get directional input.
I'm tempted to piece together my own input manager instead of buying a third party module, but I need to get past the axis thing first!
That being said, it looks like in unity you can request input arbitrarily without having to define it as a named axis in the unity input manager. I'm not totally sure this helps you but it is useful if you're determining by button press which out of multiple controllers should be considered "first player"
Also, there are at least a couple tools available for download which are replacements for the input manager that attempt to rectify some of the interesting decisions they've made.
Thanks for the response. :-)
I'm definitely angling for a multiplayer mode down the line, so the "all controllers" property wouldn't work for me.
I've seen that link, but the problem is that I can't figure out how to get dpad and sticks via that method. I can for loop over all controller indices, but I don't know the corresponding string to get directional input.
I'm tempted to piece together my own input manager instead of buying a third party module, but I need to get past the axis thing first!
For normal xbox controller dpad, try "joystick [number] button [6|7|8|9]" ?
Not totally sure but figuring out those string identifiers for the buttons and axes seems like it would be imperative if you plan on tooling up your own input manager.
@templewulf Check out inControl. There's also a paid version on the asset store that they are continuing to update/add features to but the open source github version should be more than enough to get started with.
It's funny, one of the threads I was reading was Guavaman complaining about the state of Unity Input support 5 years ago. The thread concludes with him launching the Rewired website & Unity Asset.
With the number of input replacements in the community, I might forego making my own if any of them are good. Even though cInput and InControl are cheaper, I'm looking harder at Rewired since he made exactly the same assessment I did in that thread.
@templewulf Check out inControl. There's also a paid version on the asset store that they are continuing to update/add features to but the open source github version should be more than enough to get started with.
Oh, huh, I didn't realize it was open source. Thanks for the excellent find!
Public Beta is out for my game! If you have an Android device you can check it out. (I am developing for iOS as well but open beta testing is a pain on that platform).
What is it?
I, Falling Robot is a game where you a play as a robot who is constantly falling. It is an obstacle avoidance game with elements of a rhythm game, as the obstacle are tied to the classic music that accompanies each level. There is a heavy emphasis on theme; I've tried to capture the look and sound of early silent films.
The main menu's best times / lives information is a little weirdly formatted at times, I plan to redo this.
The frame rate can get a little rough on certain older Android devices, if you hit this, turn off the vignette filter under the settings menu. Also let me know what device you are running so I can keep track of problem devices.
Frame rate display is temporary and there to help with testing.
Looking for feedback on:
Gameplay, let me know if you think the gameplay is fun and have any suggestions about how it could be improved.
Technical, let me know if you hit any technical issues. While the game is still in beta it's been pretty stable for all my beta testers up to this point so I'd like to know if that isn't the case for anyone.
Aesthetics, I worked really hard on the theme of this game, I'd love to hear feedback on this.
When you are ready to submit feedback I set up a survey at http://goo.gl/forms/lUdwXDdcHr or you can just give me feedback in this thread.
What a journey to get here, hope you guys like it.
I spent the week mostly in investigative analysis of high-profile JRPG game design, that is to say, I played entirely too much Final Fantasy XIII and got very little accomplished.
HOWEVER.
After finding myself in the Unity documentation for reasons I remain at a loss to quantify, I realized, with serendipity like unto the arrival of prophecy from on high, that everything I've been working toward in raw code could actually be realized with Unity primitives far, far easier than my initial analysis suggested. So, I've sketched out a progression of very simple implementation steps that I plan to act on this weekend, in order to prototype some basic Sonic the Hedgehog-style platforming. So something got accomplished.
My favorite musical instrument is the air-raid siren.
A Star Wars: Rogue Squadron clone. A Roguelike Squadron, if you will. :P
And I'm making it in UE4, because that's what I have.
Wish me luck!
Children's rights are human rights.
+9
MachwingIt looks like a harmless old computer, doesn't it?Left in this cave to rot ... or to flower!Registered Userregular
edited April 2016
Unityyyyyyy question:
-I've got a prefab with a script containing a public value. If I edit this value in the inspector, it sticks! Great! However, I've tied the value to a custom editor gizmo by decorating the script with [ExecuteInEditMode] and checking in Update() if the gizmo's rotation has changed. If I use the gizmo to change the value, it resets after playing the game.
So script default value = 30.0, I set to 60.0 on the script through inspector, play and stop playing -> value stays 60.0
if I set to 90.0 by rotating my custom gizmo object, play and stop playing -> value reverts to whatever it was before, whether that be the prefab default or some custom value I set directly on the script
how do I keep the value when it's set through the custom gizmo? Why does it wait until I play before resetting? halp
edit: turns out I needed to duplicate my update() code in start(), unity wat r u doin
Music is pretty simplistic and can sound pretty iffy if it decides to get what I'll call "creative", but... it works! Still some weird bugs(If you build two missile towers and nothing else, they refuse to fire until something else has fired. Why? I have no idea).
Now all that's left is to build the arcade cabinet to put it in to install it in a space, and... well, take like a month or two or three off before returning to make it maybe something that's actually good, instead of just something that works.
Now all that's left is to build the arcade cabinet to put it in to install it in a space, and... well, take like a month or two or three off before returning to make it maybe something that's actually good, instead of just something that works.
Now all that's left is to build the arcade cabinet to put it in to install it in a space, and... well, take like a month or two or three off before returning to make it maybe something that's actually good, instead of just something that works.
So you're doing it as an installation piece?
Yeah, for this iteration at least. I think once I've done this installation I'm going to take some time off this project and do a little fun thing that's been bouncing around in my head, and then I'm going to go back to this project and try to make a real game out of it, and then also expand the music generation, do more intense markov analysis of stuff, really dive into the sound, etc, instead of just sort of a tech demo/proof of concept thing. And I think when I do that I'm going to make it a digital-only thing(maybe re-do the UI for phones too)
But for now, it's going to be installed in an art gallery,(The Audain at SFU in downtown Vancouver, from May 5th to the... 19th? if anyone wants to come see it in person who lives near Vancouver), and will be put into a faux-arcade cabinet. The entire idea of the thing was to sort of see if I could find a way to bring a Generative music game into a more traditional art space, so I decided to see how it would feel if I took an already existing way of having games as an installation by referencing arcades. I'll see how it feels when it's installed, but I think that adding the cabinet and shoehorning into a gallery setting doesn't really add anything to the work, while also taking away the nice things about, you know... the internet existing. I think I'll keep the general aesthetic of the pseudo-vector-graphics sort of thing, but scrap the actual cabinet in the future.
Then use ambient occlusion to turn off all the objects that aren't close to camera view
The term you're looking for here is frustrum culling (culling objects outside of the camera frustrum, i.e. off-screen). Ambient occlusion is a lighting effect.
@templewulf You can do a couple things here. One would be to separate areas into different scenes and have loading screens between them, but there's no reason you need to do it this way. Another option would be to separate the map into (X, Y) cells and keep only the cells adjacent to the player loaded in memory. So long as the player can't cross a cell before you've streamed the adjacent cells in, you shouldn't have any loading issues.
Thanks for the information, you guys! I was considering the adjacent cell approach, since that's what I did in XNA, but most of the Unity tutorials are single-scene demos. I was beginning to wonder if I was misunderstanding their approach to scene management.
I think what I'll end up doing is side-scrollers with long "hallway" areas that can be oriented in any direction on the world map. If I just load in all the hallways connected with the current one, I should be okay.
I'll try just using the Unity editor for level and character editing. I think it's just weird to me to instantiate prefabs to edit, then put them away. I feel like I'm creating a mess that I'll have to clean up later, like a `new` that makes me paranoid about missing a `delete`.
Okay, my tiny scenes are working okay in isolation, but what's the idiomatic way of creating level flow? Should I create some kind of DungeonMaster class to manage scene loading, fading in/out, picking the right entrance to spawn at, etc.? Or is there some easier, built-in way of doing that through events or coroutines or something?
Despite the valiant efforts of Star Fox Zero and Bravely Default, I followed through on (the vast majority of) the plans I laid out last week. Consequently, I have a functioning demo of the Sonic game physics I alluded to in my last post, codenamed "Hamsterball" (because when you represent a character with a circular collision volume, it's like they're running in a hamsterball). Check it out this video:
The rules are pretty simple; platforms are made up of a series of EdgeCollider2Ds that are hooked together as a doubly-linked list. When the ball hits any Edge and has a velocity contrary to the Edge's surface normal, it checks whether its center projects onto the line segment. If so, it goes into an "attached" state and moves along the Edge, determining its initial grounded velocity with some simple vector math. Any time the ball hits a different Edge (even when grounded), it simply attaches to the new Edge in the same way. Should the ball's velocity allow it to cover the entirety of an Edge in a single frame and no collision occurs otherwise, it moves to the relevant extreme and then attaches itself to the next connected Edge. If there is no next or previous Edge, then the ball detaches and goes back to its airborne state. And, of course, you can manually detach from a platform with a standard-issue jump.
I do have one concern about the way I have things set up the way they are now: I'm not using the ability of EdgeColliders to have multiple vertices in sequence; instead, every individual Edge is its own object. However, I think it's not necessarily a clear win to reduce the number of Edges used in that way for two reasons. The first is that the current implementation is much simpler; the ball only has to track when edge it's attached to, if any. When you add the possibility of your attached edges having many vertices, things get significantly more complicated; you have to find out which of the segments on the collided edge you most plausibly should attach to, then track not only your attached edge but also your index within the Edge's vertex array.
Incidentally, I lied. There was another reason, but with several hours' further idle thought since the original writing of this post, I see now that it applies to the case of having all the Edges be individual single line segments just as well. 1,000 characters of text averted!
Besides that monstrous issue (that turned out not to be), there are two other major design issues that are at least easier to resolve than that one. Currently, the ball doesn't care what the surface normal of the Edges it collides with are-- it just attaches, in defiance of gravity. At some point, the ball is going to have to determine whether an Edge that it just collided with has a walkable surface normal and bounce off if it can't attach. Furthermore, if the ball transitions onto a non-walkable surface from a walkable one, it needs to detach after a certain amount of time spent upside-down, though not instantly-- we do need to support loop-de-loops if we're going to be making a proper Sonic knockoff, after all.
The other problem the system has right now is "elbow bonks". If the ball collides with an Edge while moving against its surface normal, but its centerpoint does not project onto that Edge, then it "bonks"-- reflects its velocity across the surface normal and does not attach. That's the behavior you'd expect, but it doesn't quite work out properly when you have multiple line segments in play. Consider this situation:
The Edges are connected, so if the ball were attached to either of them individually, it would roll over to the next one after reaching the end of the first. But if it collides as shown, the ball's center point won't project onto either line segment-- it bonks off of both of them (or rather, whichever registers the collision first). This turns what otherwise looks like a nice, smooth surface into a coin-toss as to whether the ball will attach or bonk. Fortunately, the solution here is also simple-- in the event of a bonk, you check for whether there is another line segment connected to the one you collided with. If so, then you attach to whichever one best matches the ground velocity that would result from an attachment-causing collision. (That's clear as mud, I know, but I think I'm running out of the patience I can reasonably expect from the reader at this point.)
My plans for this week are to explore the possibility of using EdgeColliders with many vertices, and correct the other physics issues.
(Incidentally, I was working on something similar, also called "Hamsterball", back in 2009. Don't wait to follow your dreams, folks...)
Fuck accelerometer is driving me nuts. Trying to get that final 10% of polish on controls makes me want to pull my hair out.
I really wish I just had access to the Doodle Jump codebase, would love to see what weird calculations they are doing to make their input feel so good.
Managed to get a hold of my computer long enough to do a full playthrough, beat all 10 level and upload a video of my last Epic GameJam entry. (it didn't win)
Lots of AI stuff! Guard hears a noise I made, but turns and sees me and doesn't mind that I'm there so he's just like "hrm" (also "don't sneak up on me like that" etc)
Random AI chatter ala HL1
Smooth stance transitions based on distance from enemy, also a whole new weapon system that shares the same base weapon class between all melee, projectile and hitscan weapons (throwables too eventually)
Jumping back in after a few stressful personal weeks and I stumbled upon a question for gamemaker, but might apply to other games.
For the "ground" when jumping in a strict 2d game......
Invisible collision object piggy backing off of another collision object's code?
Or coding a "stop falling if height = this variable?"
I just have one collider for the ground object. It does all the things.
I also have a "groundDetector" collision volume extending out of my player's legs. If anything from the "Ground" layer intersects with it, the player is grounded and can jump again. The combination seems to work pretty well?
It's installed! I need to do some final touch-up on the cabinet tomorrow, but it's installed!
Also for some reason it doesn't seem to be picking a new key when it restarts but... that is the least of my worries. And since the gallery opens tomorrow, I'm not really going to worry about little things like that.
It's installed! I need to do some final touch-up on the cabinet tomorrow, but it's installed!
Also for some reason it doesn't seem to be picking a new key when it restarts but... that is the least of my worries. And since the gallery opens tomorrow, I'm not really going to worry about little things like that.
Posts
Yeah those are the missile towers.
Before they were still ShootTowers, which play when the sixteenth they're on is >= their note's duration * fireRate. But I had done some stuff with overrides and statics to re-do the MissileTowers to fire every other one(The first tower was advancing the shared counter, and then the 2nd tower was just overwriting its instanced sixteenth counter with the shared one), which worked fine unless the downbeat was an eighth note, at which point it would play two sixteenths. I think it's because it was still running the base advance() from the ShootTower before overwriting it from the static shared sixteenth counter. It wasn't a problem when it was the 2nd tower doing it or if it was longer than an eighth, because it would correct after the first sixteenth advance().
The solution was just basically to copy the advance() void from the intermediary class, and then have it only advance and track the static shared sixteenth counter. And then of course remove it from the ShootTower and only have it inherit from Tower.
Again, easy fix, just annoying after having set up all the ShootTowers as ShootTowers specifically because three tower types behaved in the same way, only to have to re-do it because it turns out some of them don't.
XNA had lots of stuff pre-defined, and it was easy to figure out which controller an input was coming from. It seems harder to detect and configure things programmatically in Unity instead of the Input Manager pane in the editor.
1.) Can I programmatically determine which controller is being used, or do I really have to define a series of axes for d-pad and sticks for every controller index?
2.) Is there a comprehensive way to detect what keyboard key or gamepad button has been pressed in order to assign it on a config screen?
All the time.
Without going third party, you have two options with unity regarding multiple controllers. Either accept input from all controllers (single player) or define each controller separately (multiplayer).
Unity has Input.inputString which returns all of the keyboard string input entered that frame, but that's only keyboard stuff. If you want to do your keybindings in default unity input manager, you probably have to define them all by hand, or at least check for each gamepad button and mouse button before using inputstring to check for keyboard input.
Also, there are at least a couple tools available for download which are replacements for the input manager that attempt to rectify some of the interesting decisions they've made.
Guys! We made a game for the recent UE4 Jam that I'm actually pretty damn proud of. Check out this livestream playthrough:
Usual caveats apply: made in 3 days by mostly 3 people (with a little help from 2 more on the last day), so yay! Theme for this one was "Spring into the Future", whatever that means! I think a robot rabbit jumping around counts, right?
Unreal Engine 4 Developers Community.
I'm working on a cute little video game! Here's a link for you.
Thanks for the response. :-)
I'm definitely angling for a multiplayer mode down the line, so the "all controllers" property wouldn't work for me.
I've seen that link, but the problem is that I can't figure out how to get dpad and sticks via that method. I can for loop over all controller indices, but I don't know the corresponding string to get directional input.
I'm tempted to piece together my own input manager instead of buying a third party module, but I need to get past the axis thing first!
For normal xbox controller dpad, try "joystick [number] button [6|7|8|9]" ?
Not totally sure but figuring out those string identifiers for the buttons and axes seems like it would be imperative if you plan on tooling up your own input manager.
Also has a free trial which just ignores input after 2 minutes so you can develop stuff using it without throwing money at people.
Otherwise, input varies by a couple of different factors, depending on make and operating system.
http://wiki.unity3d.com/index.php?title=Xbox360Controller or http://answers.unity3d.com/questions/8094/what-are-all-the-joystick-buttons-for-an-xbox-360p.html are decent places.
It's funny, one of the threads I was reading was Guavaman complaining about the state of Unity Input support 5 years ago. The thread concludes with him launching the Rewired website & Unity Asset.
With the number of input replacements in the community, I might forego making my own if any of them are good. Even though cInput and InControl are cheaper, I'm looking harder at Rewired since he made exactly the same assessment I did in that thread.
Oh, huh, I didn't realize it was open source. Thanks for the excellent find!
What is it?
I, Falling Robot is a game where you a play as a robot who is constantly falling. It is an obstacle avoidance game with elements of a rhythm game, as the obstacle are tied to the classic music that accompanies each level. There is a heavy emphasis on theme; I've tried to capture the look and sound of early silent films.
Gifs!
It is my first game so I'd really love as much feedback as possible from people.
Click Here for the Beta
System Requirements:
Known issues:
Looking for feedback on:
When you are ready to submit feedback I set up a survey at http://goo.gl/forms/lUdwXDdcHr or you can just give me feedback in this thread.
What a journey to get here, hope you guys like it.
I spent the week mostly in investigative analysis of high-profile JRPG game design, that is to say, I played entirely too much Final Fantasy XIII and got very little accomplished.
HOWEVER.
After finding myself in the Unity documentation for reasons I remain at a loss to quantify, I realized, with serendipity like unto the arrival of prophecy from on high, that everything I've been working toward in raw code could actually be realized with Unity primitives far, far easier than my initial analysis suggested. So, I've sketched out a progression of very simple implementation steps that I plan to act on this weekend, in order to prototype some basic Sonic the Hedgehog-style platforming. So something got accomplished.
I'm "kupiyupaekio" on Discord.
A Star Wars: Rogue Squadron clone. A Roguelike Squadron, if you will. :P
And I'm making it in UE4, because that's what I have.
Wish me luck!
-I've got a prefab with a script containing a public value. If I edit this value in the inspector, it sticks! Great! However, I've tied the value to a custom editor gizmo by decorating the script with [ExecuteInEditMode] and checking in Update() if the gizmo's rotation has changed. If I use the gizmo to change the value, it resets after playing the game.
So script default value = 30.0, I set to 60.0 on the script through inspector, play and stop playing -> value stays 60.0
if I set to 90.0 by rotating my custom gizmo object, play and stop playing -> value reverts to whatever it was before, whether that be the prefab default or some custom value I set directly on the script
how do I keep the value when it's set through the custom gizmo? Why does it wait until I play before resetting? halp
edit: turns out I needed to duplicate my update() code in start(), unity wat r u doin
Good luck, that sounds like a fun project and game.
Could you elaborate on this solution? I haven't seen this problem personally but it seems useful to know how this interaction works.
Music is pretty simplistic and can sound pretty iffy if it decides to get what I'll call "creative", but... it works! Still some weird bugs(If you build two missile towers and nothing else, they refuse to fire until something else has fired. Why? I have no idea).
Now all that's left is to build the arcade cabinet to put it in to install it in a space, and... well, take like a month or two or three off before returning to make it maybe something that's actually good, instead of just something that works.
So you're doing it as an installation piece?
Yeah, for this iteration at least. I think once I've done this installation I'm going to take some time off this project and do a little fun thing that's been bouncing around in my head, and then I'm going to go back to this project and try to make a real game out of it, and then also expand the music generation, do more intense markov analysis of stuff, really dive into the sound, etc, instead of just sort of a tech demo/proof of concept thing. And I think when I do that I'm going to make it a digital-only thing(maybe re-do the UI for phones too)
But for now, it's going to be installed in an art gallery,(The Audain at SFU in downtown Vancouver, from May 5th to the... 19th? if anyone wants to come see it in person who lives near Vancouver), and will be put into a faux-arcade cabinet. The entire idea of the thing was to sort of see if I could find a way to bring a Generative music game into a more traditional art space, so I decided to see how it would feel if I took an already existing way of having games as an installation by referencing arcades. I'll see how it feels when it's installed, but I think that adding the cabinet and shoehorning into a gallery setting doesn't really add anything to the work, while also taking away the nice things about, you know... the internet existing. I think I'll keep the general aesthetic of the pseudo-vector-graphics sort of thing, but scrap the actual cabinet in the future.
Okay, my tiny scenes are working okay in isolation, but what's the idiomatic way of creating level flow? Should I create some kind of DungeonMaster class to manage scene loading, fading in/out, picking the right entrance to spawn at, etc.? Or is there some easier, built-in way of doing that through events or coroutines or something?
The rules are pretty simple; platforms are made up of a series of EdgeCollider2Ds that are hooked together as a doubly-linked list. When the ball hits any Edge and has a velocity contrary to the Edge's surface normal, it checks whether its center projects onto the line segment. If so, it goes into an "attached" state and moves along the Edge, determining its initial grounded velocity with some simple vector math. Any time the ball hits a different Edge (even when grounded), it simply attaches to the new Edge in the same way. Should the ball's velocity allow it to cover the entirety of an Edge in a single frame and no collision occurs otherwise, it moves to the relevant extreme and then attaches itself to the next connected Edge. If there is no next or previous Edge, then the ball detaches and goes back to its airborne state. And, of course, you can manually detach from a platform with a standard-issue jump.
I do have one concern about the way I have things set up the way they are now: I'm not using the ability of EdgeColliders to have multiple vertices in sequence; instead, every individual Edge is its own object. However, I think it's not necessarily a clear win to reduce the number of Edges used in that way for two reasons. The first is that the current implementation is much simpler; the ball only has to track when edge it's attached to, if any. When you add the possibility of your attached edges having many vertices, things get significantly more complicated; you have to find out which of the segments on the collided edge you most plausibly should attach to, then track not only your attached edge but also your index within the Edge's vertex array.
Incidentally, I lied. There was another reason, but with several hours' further idle thought since the original writing of this post, I see now that it applies to the case of having all the Edges be individual single line segments just as well. 1,000 characters of text averted!
Besides that monstrous issue (that turned out not to be), there are two other major design issues that are at least easier to resolve than that one. Currently, the ball doesn't care what the surface normal of the Edges it collides with are-- it just attaches, in defiance of gravity. At some point, the ball is going to have to determine whether an Edge that it just collided with has a walkable surface normal and bounce off if it can't attach. Furthermore, if the ball transitions onto a non-walkable surface from a walkable one, it needs to detach after a certain amount of time spent upside-down, though not instantly-- we do need to support loop-de-loops if we're going to be making a proper Sonic knockoff, after all.
The other problem the system has right now is "elbow bonks". If the ball collides with an Edge while moving against its surface normal, but its centerpoint does not project onto that Edge, then it "bonks"-- reflects its velocity across the surface normal and does not attach. That's the behavior you'd expect, but it doesn't quite work out properly when you have multiple line segments in play. Consider this situation:
The Edges are connected, so if the ball were attached to either of them individually, it would roll over to the next one after reaching the end of the first. But if it collides as shown, the ball's center point won't project onto either line segment-- it bonks off of both of them (or rather, whichever registers the collision first). This turns what otherwise looks like a nice, smooth surface into a coin-toss as to whether the ball will attach or bonk. Fortunately, the solution here is also simple-- in the event of a bonk, you check for whether there is another line segment connected to the one you collided with. If so, then you attach to whichever one best matches the ground velocity that would result from an attachment-causing collision. (That's clear as mud, I know, but I think I'm running out of the patience I can reasonably expect from the reader at this point.)
My plans for this week are to explore the possibility of using EdgeColliders with many vertices, and correct the other physics issues.
(Incidentally, I was working on something similar, also called "Hamsterball", back in 2009. Don't wait to follow your dreams, folks...)
I'm "kupiyupaekio" on Discord.
I really wish I just had access to the Doodle Jump codebase, would love to see what weird calculations they are doing to make their input feel so good.
The entry is called Rumble
Tried out an arrow that bounces off walls and sparks on metal, starting fires
a tool to help me make multi-storey trams
A simple physics rope actor
Lots of AI stuff! Guard hears a noise I made, but turns and sees me and doesn't mind that I'm there so he's just like "hrm" (also "don't sneak up on me like that" etc)
Random AI chatter ala HL1
Smooth stance transitions based on distance from enemy, also a whole new weapon system that shares the same base weapon class between all melee, projectile and hitscan weapons (throwables too eventually)
Added a debug mode toggle
Started paying an artist for concept art
NPCs getting better about fighting each other
NPCs using root motion for their attacks
For the "ground" when jumping in a strict 2d game......
Invisible collision object piggy backing off of another collision object's code?
Or coding a "stop falling if height = this variable?"
Or pits to fall into.
Unreal Engine 4 Developers Community.
I'm working on a cute little video game! Here's a link for you.
Why don't you have the ground be a normal collision object like any other collision object?
I just have one collider for the ground object. It does all the things.
I also have a "groundDetector" collision volume extending out of my player's legs. If anything from the "Ground" layer intersects with it, the player is grounded and can jump again. The combination seems to work pretty well?
It's installed! I need to do some final touch-up on the cabinet tomorrow, but it's installed!
Also for some reason it doesn't seem to be picking a new key when it restarts but... that is the least of my worries. And since the gallery opens tomorrow, I'm not really going to worry about little things like that.
Twitch: KoopahTroopah - Steam: Koopah
Why do I get the feeling you made Polybius?
Thanks! I've got funding for it from multiple sources so either I make it something awesome or I'm bankrupt forever