Did some pretty fun visual tweaks over the last few days.
I was somewhat unhappy with the fact that in an effort to give a big difference between the green/blue player stuff and the red enemy stuff, I ended up basically making all the towers and whatnot, which is the core focus for the player, a sort of boring bland washed-out green that looked pretty shitty. Also seeing all of you guys doing missiles with line trails instead of weird particle-systems-of-smoke-trails made me want to re-do my missile look as well.
First of all, props to @Mahnmut for the advice on running the editor itself in debug mode out of Visual Studio; since then, I've at least been able to identify where failures are happening, even if a few of them still mystify me. And, thanks just for reading the report in general! It's nice to know that people are reading them despite the length.
I've completely translated my pseudocode for the Hamsterball component into C++. Unfortunately, the whole thing is probably going to need a few proofreading passes before it's entirely stable; right now the Hamsterball judders around and teleports oddly when interacting with a surface composed of anything but a single line segment that's perfectly flush with the ground, then crashes the game. Suffice it to say that there are no screenshots or videos to share this week, as they would be brief and uneventful. Some of this behavior I can attribute to my own failings (any time you observe mathematical impossibilities, it's probably your fault), but I've had one fairly repeatable case where my Surface component (the one that turns an Actor into something the Hamsterball can interact with) is causing access violations when trying to get the transform of its owning actor. I get the pointer to the owning actor at startup and never touch it thereafter, so I would assume the pointer remains valid, but evidently that is not the case.
Speaking of bizarre behavior, here's something that other people might have seen before: I built a custom Pawn class and had it get possessed by the first player at the start of the game, so I could maintain a predictable camera angle. But every so often I'll observe this weird reference sphere in front of the camera for just a moment, like one of those material test orbs. It's not visible in the scene viewer. It's just... there, and I have no idea why.
During other design and development periods I've had available this week, I ran myself around in circles for a while trying to solve an intractable math problem before realizing that there was a much easier solution. To wit, since Hamsterball will eventually be a Sonic-like game, it's important to have curved surfaces to roll up and down. Curved surfaces are represented as a set of line segments defined by an array of vertexes, which greatly simplifies the collision detection. The trick is that defining a circular curve by hand is annoyingly typing-intensive, especially since a decent curve can require something like ten to twenty line segments before they start to melt into a curve in the human eye. Therefore, I wanted a system to quickly generate curves. The solution I spent a day or so hacking at was to associate an angle in radians with the start and end points of the Surface, then try to solve for the center of an ellipse that passed through both of them and assign the remaining points on that arc. As it turns out, doing so reliably is mathematically impossible, and the results ranged from passable to crashes as things got divided by infinity. As I was sulking in the shadow of this latest failure, the phrase bezier curves flitted through my mind and I went "oh, right, those exist". I hooked up a generator for points on a bezier curve with an arbitrary number of control points in an hour and that was the end of it.
Finally, I've been thinking ahead to level design and graphical considerations, and something occurred to me: it is probably (at least hopefully) possible to map world coordinates into UV space for a material. Though sprite tiles have to be manual arranged so that they interlock, if I have a material that sets UV coordinates with world space coordinates as a parameter, then I could arrange a bunch of polygons together in arbitrary configurations and just have the same texture flow across the whole thing. It sounds too good to be true... I'll bet actually figuring out what your world coordinates are while in the shader is prohibitively difficult in some way... oh well. I'll burn that bridge when I get to it. (Oh hey maybe it's not so hard.)
For the coming week, my plans are debugging, debugging, and debugging.
My favorite musical instrument is the air-raid siren.
@Kupi: the "reference sphere" is probably the DefaultPawn actor. The "correct" way to set the player's pawn class is by setting it as the default pawn class in a gamemode, and setting that gamemode as the level's gamemode in the map's world settings. Check that that's all set properly!
Is the fact that I'm working with a C++ Project the reason why all those settings are grayed out under "Edit > Project Settings > Maps and Modes"?
... suggesting that I have to define those settings in the HamsterballGameType class, and not anywhere convenient within the editor?
... further suggesting that I'd have to make a Hamsterball Pawn class in C++, as opposed to the Blueprint I have now, because you can't get at Blueprint classes from code?
My favorite musical instrument is the air-raid siren.
Generally greyed out things are things set by C++ and not marked editable. If you want a game mode for example create one that derives from your c++ class and change them in that
Is the fact that I'm working with a C++ Project the reason why all those settings are grayed out under "Edit > Project Settings > Maps and Modes"?
... suggesting that I have to define those settings in the HamsterballGameType class, and not anywhere convenient within the editor?
... further suggesting that I'd have to make a Hamsterball Pawn class in C++, as opposed to the Blueprint I have now, because you can't get at Blueprint classes from code?
I'm not sure about the settings, but you can actually get a blueprint from code (it's just no fun):
Is the fact that I'm working with a C++ Project the reason why all those settings are grayed out under "Edit > Project Settings > Maps and Modes"?
... suggesting that I have to define those settings in the HamsterballGameType class, and not anywhere convenient within the editor?
... further suggesting that I'd have to make a Hamsterball Pawn class in C++, as opposed to the Blueprint I have now, because you can't get at Blueprint classes from code?
No, that could mean that your settings file is not writable. But also, you can set those on a per-map basis! (And should. Otherwise sometimes shit breaks.)
Well, I was able to get around it by making a new GameType Blueprint, so whatever! Good enough.
Ah, well yes, that's what you need to do. Sorry, I misunderstood and thought you were talking about the dropdowns in project settings! The "GameMode" class is the base class that your game modes should be children of
Hi! I'm just starting out doing some Unity stuff for the first time. I'm going through one of the first tutorials, and everything is moving relatively smoothly. However, when I get to the point of adding some text in the UI, weird stuff happens. Basically, the Canvas that gets added when I add the Text is huge. Like, a thousand times or so larger than the rest of my objects.
Why is that? What's the best way to deal with this?
Like, instinctively I just want to know how to resize it, because right now I'm not given that option (it just says "Some values driven by Canvas" in the Rect Transform and the width/height/etc are greyed out). But if there's a better practice or something (make that the correct size and resize the game board, keep it and just reposition the text field (which works normally) so that it's in the right place, etc) I'd rather just do that.
Nevermind! I eventually found this other video which explains what's happening and what to do.
This one is probably obscure enough that I'll have to take it to answers.unrealengine.com eventually, but I figure I might as well take a swing here first.
In Hamsterball, platforms are defined by Surface Components that are attached to Actors. Surface Components can form a linked list so that the Hamsterball can seamlessly transition between them. In code, this looks like this:
class HAMSTERBALL_API USurfaceComponent : public UBoxComponent
{
// Other declarations
public:
UPROPERTY(EditAnywhere, Category = Connection)
USurfaceComponent* next;
UPROPERTY(EditAnywhere, Category = Connection)
USurfaceComponent* previous;
}
Now, there's a virtual function for Actor Components called PostEditChangeProperty() that lets you react to changes to the Component in the editor. As part of this function, I run some detection logic that finds nearby Surface Components that could plausibly join the current Surface Component as part of the linked list. So the code involved in establishing the connections looks like this:
void USurfaceComponent::PostEditChangeProperty(struct FPropertyChangedEvent& PropertyChangedEvent)
{
// Detect a Surface that should follow after the current Surface
surface->previous = this;
this->next = surface;
// Detect a Surface that should come before the current Surface
surface->next = this;
this->previous = surface;
}
Using the step-through debugger, I've verified that a proper candidate Surface is detected and that those assignments are performed, so it's not a matter of the code not getting hit. I've modified other values at the same time, so I know that the editor will immediately show me any changes that my code has made to the values. However, in this case, the pointer assignments don't take effect. Sometimes, neither the Surface I'm editing nor the nearby Surface have either their Next or Previous values set; occasionally, and I'm not sure why, the other Surface (but never the one I'm editing) will have the appropriate Next or Previous reference set (though the reference seems to disappear as soon as I hit "play"). But in any event, after the values have very definitely been set, they are then erased... somehow. It feels like I'm running afoul of some idiom in the way Unreal handles objects, but I've no way of knowing what.
Any ideas?
EDIT: I explored this a bit further, and I at least know what's going wrong... I set a breakpoint in the Surface Component's constructor, and it turns out that control goes into the constructor after the call to PostEditChangeProperty() call. So the object is getting replaced with a duplicate that has the new values, and somehow this is causing the pointers to drop. Further, this Unreal Answers question seems to indicate that the behavior I want simply will not work in the current regime. Sigh.
EDIT2: Well, I could at least work around it. The Surface Component now stores the actor and the name of the Component, then caches the value after using the relevant finder functions. I'm not happy with it, but it's a solution.
Kupi on
My favorite musical instrument is the air-raid siren.
@Kupi yeah I've encountered something similar where as soon as an object is modified in editor the components are recreated, they keep entered values but anything calculated was lost.
So is there any way that a Component can meaningfully react to changes in its containing Actor within the Unreal Editor? It seems like any relevant event function (those mostly being the "on load" type events such as the C++ constructors, the Construction Script in the Actor's Blueprint Class, the PostLoad()) function) happens before the Component is actually given any of its values by the serialization engine, and anything I can find belonging to the Component classes themselves only concerns itself with changes in the Component itself, with no chance of reacting to updates in any other object.
Christ, if only they didn't react to moving Actors by destroying them and putting a new one in its place...! Why?!
My favorite musical instrument is the air-raid siren.
So is there any way that a Component can meaningfully react to changes in its containing Actor within the Unreal Editor? It seems like any relevant event function (those mostly being the "on load" type events such as the C++ constructors, the Construction Script in the Actor's Blueprint Class, the PostLoad()) function) happens before the Component is actually given any of its values by the serialization engine, and anything I can find belonging to the Component classes themselves only concerns itself with changes in the Component itself, with no chance of reacting to updates in any other object.
Christ, if only they didn't react to moving Actors by destroying them and putting a new one in its place...! Why?!
Generally, the point of components is to separate out the things that either only feed data to the actor or operate entirely independently
Why not have the actor update its components when it changes?
For all intents and purposes, my Components in this case are acting entirely independently-- the only thing they need to know from the Actor is their position in world coordinates, which is already a provided function of the Actor by way of a guaranteed Root Component.
The Actor cannot update the components when it changes because, as far as I've observed, moving the Actor entirely destroys it and then reconstructs it with the new values. So if the Actor were to attempt to modify its Components, there would be no meaningful way to do so because the Components' values (such as their relative positions) haven't loaded in yet. It could possibly create them out of whole cloth according to its own settings, at which point the Actor is acting like one of the Components itself, which I thought was what we were trying to avoid.
EDIT: PostInitializeComponents() might actually be what I'm looking for.
EDIT2: ... if I want to inherit from AActor. Looks like it's unavoidable.
EDIT3: Haha, nope. That's only for when you're starting gameplay, not when you're moving things around in the editor. Fuck it, I'm out for tonight...
Kupi on
My favorite musical instrument is the air-raid siren.
@Kupi yeah I've encountered something similar where as soon as an object is modified in editor the components are recreated, they keep entered values but anything calculated was lost.
For all intents and purposes, my Components in this case are acting entirely independently-- the only thing they need to know from the Actor is their position in world coordinates, which is already a provided function of the Actor by way of a guaranteed Root Component.
The Actor cannot update the components when it changes because, as far as I've observed, moving the Actor entirely destroys it and then reconstructs it with the new values. So if the Actor were to attempt to modify its Components, there would be no meaningful way to do so because the Components' values (such as their relative positions) haven't loaded in yet. It could possibly create them out of whole cloth according to its own settings, at which point the Actor is acting like one of the Components itself, which I thought was what we were trying to avoid.
EDIT: PostInitializeComponents() might actually be what I'm looking for.
EDIT2: ... if I want to inherit from AActor. Looks like it's unavoidable.
EDIT3: Haha, nope. That's only for when you're starting gameplay, not when you're moving things around in the editor. Fuck it, I'm out for tonight...
Oh you want stuff to update while its in the editor. That's much trickier because the objects are really only half-constructed in there anyway
Yeah, at this point I think the answer to my problem is to have the Surface Components weld themselves together during BeginPlay() at the command of the owning Actor, and just eat the performance hit. Even if I have 400,000 Surface Components in one level (which is extremely unlikely!), I'm still doing all the related physics queries only once at startup. And if I want finer control over which Surfaces can auto-connect to which others, I can tell them to ignore specific actors in those queries (which is a data member I'm going to need anyway in order to produce switchbacks). That saves me a pair of pointers and two FStrings over the present approach, and RAM is more precious than clock cycles these days. Oh well.
And uh woo Handkor YEAH! \o/ \o/ \o/
My favorite musical instrument is the air-raid siren.
... that doesn't rhyme as well as it was supposed to. Oh well!
This was a great week for Hamsterball. Though I'm still not up to the level it was at in Unity, the core gameplay code basically all there, plus extras over what was in the Unity prototype. What I'm missing right now is the graphics layer; creating and importing 3D models is slightly more difficult than drawing some bitmaps, y'know. But in the meantime, Unreal debug lines are sufficient, so here, have some footage of the prototype in action:
I encountered a couple more of those frustrating C++ idioms that I've talked about in the past that took me much more time to work through than they really ought to have. For instance, at one point a simple data-retrieval function in the Surface Components that gets the endpoints of a line segment within the Surface by index started throwing access violations. This function was well-traveled without error in the past, so to have it suddenly giving me memory errors was odd. Stranger still, the function that was failing was apparently GetOwner(), an inherited function from the base Component class. My original version of the function was written without null-guards (because I could guarantee that any given member in the chain would be found by the lookups), but even after I unpacked it so I could observe the intermediate values, I couldn't see anything that was going wrong. Even when I found the in-game behavior that reliably caused the access violation (moving to a new segment in a Surface with multiple segments), there didn't appear to be anything wrong with the Surface itself.
I finally discovered the problem when I took a step back and re-read the function that was handling the transition from one line segment to the next. The intended behavior was to check if the Hamsterball was attached to the last segment in the line, and if so, move to the first segment of the next Surface (if any). If the Hamsterball was attached to any other surface, it was to attach itself to the same Surface at the next higher segment index. Owing to confusion on my part, that second case actually attached the Hamsterball to the next Surface pointed to by the current Surface... which didn't exist. So on the next frame, when the Hamsterball tried to move along the trajectory determined by the endpoints of its current line segment... its attached Surface pointer was invalid, and trying to get that data caused an access violation. Now, I understand that it's my fault for not putting a null-guard into the attachment function to begin with. But the way C++ handles pointer errors like this, I was made to believe that the Surface Component I was operating on was valid. It was not! In C#, the call stack would have stopped at the attempt to access it, and it would have been pointed out that I was referencing a null pointer. I'd still have made the error, but the error would have been pointed out much sooner.
In an entirely different incident, I noticed at one point that the Hamsterball was teleporting along the Surface when it hit specific segment transitions. Not all of them, and only if you went in a specific direction. It took a careful proofread and a step-through debugging session to determine what was going on, and the root cause turned out to be C++'s variable shadowing rules. In C++, you're allowed to define a variable in as many sub-scopes as you want. Each new definition takes precedence over the one in any containing scopes. Because I so often deal with indexes of segments, I had, without realizing it, created two variables named "segmentIndex", and operated on the nearer one as if it were the farther one, producing bizarre results. By comparison, C# will not allow you to do that-- if you define a variable in a child scope with the same name as a parent scope, it's a compiler error. Once again, I understand that my variable names should perhaps have been more indicative of their purpose, but I made the mistake anyway-- and when I did, the language shrugged and said "you're the boss" rather than demanding clarity, and I lost productive time as a result.
I already brought this particular issue to the thread's attention before, so I'll only briefly recount it now, but UE4's treatment of Actors within the editor is... inconsistent, I want to call it, with the way they're handled in the actual game. They are, in some ways, actual objects, and in other ways they're simply templates for the real objects that will be produced later. Certain initialization code isn't run, and in particular it's not possible for Components to meaningfully react to certain changes in their parent Actors because changing a property of an Actor completely destroys it. It seems to be an artifact of the UE3 model, which used inheritance instead of composition for defining Actors. However, there was actually a bright side to this whole fiasco: it turned out that the implementation of of another feature rendered it mostly irrelevant.
In the video up above, you can see how the Hamsterball passes through a Surface while moving opposite the Surface's surface normal in the part with the loop. Normally that would result in a collision, but each Surface holds a list of Actors whose Surfaces should be ignored during collision detection. So as long as you're moving along the ground, you can pass through the short list of designated ignored Surfaces. That list of ignored Actors is also used at startup to help prevent Surfaces from welding themselves onto certain other Surfaces. For instance, in the switchback at the far left of the test level where two slopes join onto a flat plane, the plane is rigged up to ignore the lower of the two slopes. This prevents you from going back down the hill in certain edge cases. I could conceivably use the same system to ensure that you always go down the hill rather than up, if the natural progression of the level had you coming down from above.
And I'd be remiss if I didn't mention that at least some of my wounds this week are self-inflicted. There's still an infinite loop lurking in the Hamsterball behavior code that results from the imprecision of floating-point values. To put it quickly, after a certain number of decimal places, floating-point values don't play nice with addition and subtraction. 2 + .000000000000001 = 2. And at a certain point in my code, the movement of an object gets so small that it's treated as non-moving within code that expects it be moving, which turns into a chain of events that never lets it escape a loop designed to consume all of the time allotted by a given Tick(). I was able to work around it by increasing the amount of time in individual "Hamsterball ticks", but I have a creeping suspicion that that's only masking the problem and not solving it. It's going to take some further investigation before I'm satisfied that settings alone can guarantee that the game won't lock up.
My next goal is to spend some time learning Blender and then put together some basic platform tiles with a ground texture attached to them (probably just a simple yellow-and-brown checkboard pattern, in keeping with the Unity prototype) and have a stock Unreal sphere mesh run around on them. That's likely to consume the entire week on its own. Past that, I want to get the Unreal Sample Project Guy affixed to the Hamsterball and see if I can drive his running animation speed according to your current ground velocity.
I realize you'll all be heartbroken to hear this, but there will not be a Kupi Weekly Friday Status Report next week, as I will be out-of-town for most of it to visit family. Just take heart in knowing that a double feature is lurking around the corner. See you then!
My favorite musical instrument is the air-raid siren.
A real close friend of mine just released some animation tutorials for the new game he's working on. I highly recommend you check them out if you're at all interested in animation for your game. Seriously, he's been doing this for over ten years and knows what he's talking about.
Here's some tutorials on animating faster and smarter:
And here's some footage of cool stuff he did in Destiny:
Need a voice actor? Hire me at bengrayVO.com
Legends of Runeterra: MNCdover #moc
Switch ID: MNC Dover SW-1154-3107-1051 Steam ID Twitch Page
@Kashaar I've never tried using vr, but I've heard that some types of movement can make people feel sick, how does your style of camera movement fare in that regard?
@Kashaar I've never tried using vr, but I've heard that some types of movement can make people feel sick, how does your style of camera movement fare in that regard?
I always need to test these things on real actual humans, and I myself don't count - somehow I'm completely impervious to motion sickness when developing. However, this movement style feels very safe and intuitive to me - it's more like you move the landscape under you than move yourself over the landscape. Kind of like scrolling on a touchscreen: you fix a point with your finger (in this case, with the metaphorical extension of your hand, the motion controller's laser pointer), and then move the content exactly proportional to how you move the finger.
Nice! It looks like your arbitrary bounding shapes are working pretty well. Is that in an SDK, or did you have to math that up yourself?
I don't know that I could make a recommendation without actually trying it on a Vive and seeing what it's like. Plus, the last RTS I played to completion was Warcraft 3, so I'm not necessarily the target audience.
That being said, it looks kind of fiddly in the way that I dislike about mouse-selection games. Could you do a paintbrush kind of thing where you wave a large-ish cursor at things and select them additively? I liked that aspect of Panzer Dragoon. You could also pluck some "local select" ideas from console RTS games, like Halo Wars.
Nice! It looks like your arbitrary bounding shapes are working pretty well. Is that in an SDK, or did you have to math that up yourself?
I don't know that I could make a recommendation without actually trying it on a Vive and seeing what it's like. Plus, the last RTS I played to completion was Warcraft 3, so I'm not necessarily the target audience.
That being said, it looks kind of fiddly in the way that I dislike about mouse-selection games. Could you do a paintbrush kind of thing where you wave a large-ish cursor at things and select them additively? I liked that aspect of Panzer Dragoon. You could also pluck some "local select" ideas from console RTS games, like Halo Wars.
The math is just a simple "is point inside polygon" check for all relevant actors within the selection mesh's bounds. (Z coordinate discarded)
The selection mesh is generated by drawing polys between the last frame's pointer target and the current frame's, if the distance is above a certain threshold.
@Kashaar I've never tried using vr, but I've heard that some types of movement can make people feel sick, how does your style of camera movement fare in that regard?
I always need to test these things on real actual humans, and I myself don't count - somehow I'm completely impervious to motion sickness when developing. However, this movement style feels very safe and intuitive to me - it's more like you move the landscape under you than move yourself over the landscape. Kind of like scrolling on a touchscreen: you fix a point with your finger (in this case, with the metaphorical extension of your hand, the motion controller's laser pointer), and then move the content exactly proportional to how you move the finger.
I went to talk on VR that went into how fixed points of reference in the VR space can reduce motion sickness, maybe that is what is happening with the landscape.
You could always add a fixed point of reference. Display the game world on a big 3d map, where panning the camera pans the area displayed on the map. That way the room your player character is standing in won't move, and you'll still get to look around at a larger world. Then add virtual push sticks to move your units around with and pretend to be a cold war era general hiding in his bunker while he moves company markers around the map of Europe.
@Kashaar I've never tried using vr, but I've heard that some types of movement can make people feel sick, how does your style of camera movement fare in that regard?
I always need to test these things on real actual humans, and I myself don't count - somehow I'm completely impervious to motion sickness when developing. However, this movement style feels very safe and intuitive to me - it's more like you move the landscape under you than move yourself over the landscape. Kind of like scrolling on a touchscreen: you fix a point with your finger (in this case, with the metaphorical extension of your hand, the motion controller's laser pointer), and then move the content exactly proportional to how you move the finger.
I went to talk on VR that went into how fixed points of reference in the VR space can reduce motion sickness, maybe that is what is happening with the landscape.
A lot of it too is head space. If you feel like you are being moved and your inner ear is not getting expected motion you get sick. This approach like Kashaar said you feel more like god and are moving the world around you.
Being moved as a person is disorienting, being in a vehicle less so and moving the world around you is not nausea inducing at all even though all three instances can have the world moving around you the same way. This is also why teleporting is somehow easier on the player then sliding to the destination.
KoopahTroopahThe koopas, the troopas.Philadelphia, PARegistered Userregular
edited June 2016
I always have trouble working on my games, because I feel like I'm working on them by myself. Even though I know there's a big community here, and people on FB I could talk to about programming things or designer issues/ideas, friends from college or w/e I could talk to online... etc. I still have trouble consistently working on stuff. Also the current mumble people I talk to pressure me into playing games instead of making them which can be annoying sometimes.
So I have an idea, and I'm sure it's been thought of before, but how about I create a Discord server where we could talk about what we're working on and shoot the shit? Maybe we could host a recurring PA dev-night or something on there. Just a thought.
In addition to tons of other stuff I added a new level transition:
Inspired by Steamboat Willie:
Not exact but probably the best I am going to do with my complete lack of shader knowledge.
Oh and I also hacked together made a website. Because making a game by myself isn't enough and SquareSpace is too goddamn expensive.
I don't have an Android device, so I'll just ask; do you need to manually remove the clotheslines and birds? Also, have you thought about a secondary mode where you fall endlessly (getting faster over time) and earn points by popping balloons and/or removing obstacles? Thought it might be a nice alternate mode if you can fit it in.
Need a voice actor? Hire me at bengrayVO.com
Legends of Runeterra: MNCdover #moc
Switch ID: MNC Dover SW-1154-3107-1051 Steam ID Twitch Page
@MNC Dover You tap to scare the birds away, and swipe to cut the clotheslines. I like the idea of popping the balloons, even if you didn't get points for it.
Posts
I was somewhat unhappy with the fact that in an effort to give a big difference between the green/blue player stuff and the red enemy stuff, I ended up basically making all the towers and whatnot, which is the core focus for the player, a sort of boring bland washed-out green that looked pretty shitty. Also seeing all of you guys doing missiles with line trails instead of weird particle-systems-of-smoke-trails made me want to re-do my missile look as well.
Result is pretty nice-looking compared to what it used to be. (Linked because it's a 750kb image.
EDIT: Also, for funsies, here's a comparison of old graphics(left) to new graphics(right)
First of all, props to @Mahnmut for the advice on running the editor itself in debug mode out of Visual Studio; since then, I've at least been able to identify where failures are happening, even if a few of them still mystify me. And, thanks just for reading the report in general! It's nice to know that people are reading them despite the length.
I've completely translated my pseudocode for the Hamsterball component into C++. Unfortunately, the whole thing is probably going to need a few proofreading passes before it's entirely stable; right now the Hamsterball judders around and teleports oddly when interacting with a surface composed of anything but a single line segment that's perfectly flush with the ground, then crashes the game. Suffice it to say that there are no screenshots or videos to share this week, as they would be brief and uneventful. Some of this behavior I can attribute to my own failings (any time you observe mathematical impossibilities, it's probably your fault), but I've had one fairly repeatable case where my Surface component (the one that turns an Actor into something the Hamsterball can interact with) is causing access violations when trying to get the transform of its owning actor. I get the pointer to the owning actor at startup and never touch it thereafter, so I would assume the pointer remains valid, but evidently that is not the case.
Speaking of bizarre behavior, here's something that other people might have seen before: I built a custom Pawn class and had it get possessed by the first player at the start of the game, so I could maintain a predictable camera angle. But every so often I'll observe this weird reference sphere in front of the camera for just a moment, like one of those material test orbs. It's not visible in the scene viewer. It's just... there, and I have no idea why.
During other design and development periods I've had available this week, I ran myself around in circles for a while trying to solve an intractable math problem before realizing that there was a much easier solution. To wit, since Hamsterball will eventually be a Sonic-like game, it's important to have curved surfaces to roll up and down. Curved surfaces are represented as a set of line segments defined by an array of vertexes, which greatly simplifies the collision detection. The trick is that defining a circular curve by hand is annoyingly typing-intensive, especially since a decent curve can require something like ten to twenty line segments before they start to melt into a curve in the human eye. Therefore, I wanted a system to quickly generate curves. The solution I spent a day or so hacking at was to associate an angle in radians with the start and end points of the Surface, then try to solve for the center of an ellipse that passed through both of them and assign the remaining points on that arc. As it turns out, doing so reliably is mathematically impossible, and the results ranged from passable to crashes as things got divided by infinity. As I was sulking in the shadow of this latest failure, the phrase bezier curves flitted through my mind and I went "oh, right, those exist". I hooked up a generator for points on a bezier curve with an arbitrary number of control points in an hour and that was the end of it.
Finally, I've been thinking ahead to level design and graphical considerations, and something occurred to me: it is probably (at least hopefully) possible to map world coordinates into UV space for a material. Though sprite tiles have to be manual arranged so that they interlock, if I have a material that sets UV coordinates with world space coordinates as a parameter, then I could arrange a bunch of polygons together in arbitrary configurations and just have the same texture flow across the whole thing. It sounds too good to be true... I'll bet actually figuring out what your world coordinates are while in the shader is prohibitively difficult in some way... oh well. I'll burn that bridge when I get to it. (Oh hey maybe it's not so hard.)
For the coming week, my plans are debugging, debugging, and debugging.
Unreal Engine 4 Developers Community.
I'm working on a cute little video game! Here's a link for you.
... suggesting that I have to define those settings in the HamsterballGameType class, and not anywhere convenient within the editor?
... further suggesting that I'd have to make a Hamsterball Pawn class in C++, as opposed to the Blueprint I have now, because you can't get at Blueprint classes from code?
I'm not sure about the settings, but you can actually get a blueprint from code (it's just no fun):
static ConstructorHelpers::FClassFinder<APawn> PlayerPawnBPClass(TEXT("/Game/Actors/SomePawn_Blueprint")); DefaultPawnClass = PlayerPawnBPClass.Class;No, that could mean that your settings file is not writable. But also, you can set those on a per-map basis! (And should. Otherwise sometimes shit breaks.)
Unreal Engine 4 Developers Community.
I'm working on a cute little video game! Here's a link for you.
Ah, well yes, that's what you need to do. Sorry, I misunderstood and thought you were talking about the dropdowns in project settings! The "GameMode" class is the base class that your game modes should be children of
Unreal Engine 4 Developers Community.
I'm working on a cute little video game! Here's a link for you.
Why is that? What's the best way to deal with this?
Like, instinctively I just want to know how to resize it, because right now I'm not given that option (it just says "Some values driven by Canvas" in the Rect Transform and the width/height/etc are greyed out). But if there's a better practice or something (make that the correct size and resize the game board, keep it and just reposition the text field (which works normally) so that it's in the right place, etc) I'd rather just do that.
Nevermind! I eventually found this other video which explains what's happening and what to do.
3DS Friend Code: 3110-5393-4113
Steam profile
In Hamsterball, platforms are defined by Surface Components that are attached to Actors. Surface Components can form a linked list so that the Hamsterball can seamlessly transition between them. In code, this looks like this:
class HAMSTERBALL_API USurfaceComponent : public UBoxComponent { // Other declarations public: UPROPERTY(EditAnywhere, Category = Connection) USurfaceComponent* next; UPROPERTY(EditAnywhere, Category = Connection) USurfaceComponent* previous; }Now, there's a virtual function for Actor Components called PostEditChangeProperty() that lets you react to changes to the Component in the editor. As part of this function, I run some detection logic that finds nearby Surface Components that could plausibly join the current Surface Component as part of the linked list. So the code involved in establishing the connections looks like this:
void USurfaceComponent::PostEditChangeProperty(struct FPropertyChangedEvent& PropertyChangedEvent) { // Detect a Surface that should follow after the current Surface surface->previous = this; this->next = surface; // Detect a Surface that should come before the current Surface surface->next = this; this->previous = surface; }Using the step-through debugger, I've verified that a proper candidate Surface is detected and that those assignments are performed, so it's not a matter of the code not getting hit. I've modified other values at the same time, so I know that the editor will immediately show me any changes that my code has made to the values. However, in this case, the pointer assignments don't take effect. Sometimes, neither the Surface I'm editing nor the nearby Surface have either their Next or Previous values set; occasionally, and I'm not sure why, the other Surface (but never the one I'm editing) will have the appropriate Next or Previous reference set (though the reference seems to disappear as soon as I hit "play"). But in any event, after the values have very definitely been set, they are then erased... somehow. It feels like I'm running afoul of some idiom in the way Unreal handles objects, but I've no way of knowing what.
Any ideas?
EDIT: I explored this a bit further, and I at least know what's going wrong... I set a breakpoint in the Surface Component's constructor, and it turns out that control goes into the constructor after the call to PostEditChangeProperty() call. So the object is getting replaced with a duplicate that has the new values, and somehow this is causing the pointers to drop. Further, this Unreal Answers question seems to indicate that the behavior I want simply will not work in the current regime. Sigh.
EDIT2: Well, I could at least work around it. The Surface Component now stores the actor and the name of the Component, then caches the value after using the relevant finder functions. I'm not happy with it, but it's a solution.
Ugh.
That is all.
Unreal Engine 4 Developers Community.
I'm working on a cute little video game! Here's a link for you.
Fun! What platform are you working on?
Oh god I do not want to experience gimbal locking in VR while looking down. bleurgg!
Christ, if only they didn't react to moving Actors by destroying them and putting a new one in its place...! Why?!
Generally, the point of components is to separate out the things that either only feed data to the actor or operate entirely independently
Why not have the actor update its components when it changes?
The Actor cannot update the components when it changes because, as far as I've observed, moving the Actor entirely destroys it and then reconstructs it with the new values. So if the Actor were to attempt to modify its Components, there would be no meaningful way to do so because the Components' values (such as their relative positions) haven't loaded in yet. It could possibly create them out of whole cloth according to its own settings, at which point the Actor is acting like one of the Components itself, which I thought was what we were trying to avoid.
EDIT: PostInitializeComponents() might actually be what I'm looking for.
EDIT2: ... if I want to inherit from AActor. Looks like it's unavoidable.
EDIT3: Haha, nope. That's only for when you're starting gameplay, not when you're moving things around in the editor. Fuck it, I'm out for tonight...
Hah, yeah, nope!
I'm operating on the principle, you grab it with your motion controller, and then pull yourself over the landscape while locked to a fixed Z plane.
Vive on PC, using UE4.
Unreal Engine 4 Developers Community.
I'm working on a cute little video game! Here's a link for you.
Oh you want stuff to update while its in the editor. That's much trickier because the objects are really only half-constructed in there anyway
And uh woo Handkor YEAH! \o/ \o/ \o/
http://www.fallout3nexus.com/downloads/file.php?id=16534
Kupi's Weekly Friday Status Report
... that doesn't rhyme as well as it was supposed to. Oh well!
This was a great week for Hamsterball. Though I'm still not up to the level it was at in Unity, the core gameplay code basically all there, plus extras over what was in the Unity prototype. What I'm missing right now is the graphics layer; creating and importing 3D models is slightly more difficult than drawing some bitmaps, y'know. But in the meantime, Unreal debug lines are sufficient, so here, have some footage of the prototype in action:
I encountered a couple more of those frustrating C++ idioms that I've talked about in the past that took me much more time to work through than they really ought to have. For instance, at one point a simple data-retrieval function in the Surface Components that gets the endpoints of a line segment within the Surface by index started throwing access violations. This function was well-traveled without error in the past, so to have it suddenly giving me memory errors was odd. Stranger still, the function that was failing was apparently GetOwner(), an inherited function from the base Component class. My original version of the function was written without null-guards (because I could guarantee that any given member in the chain would be found by the lookups), but even after I unpacked it so I could observe the intermediate values, I couldn't see anything that was going wrong. Even when I found the in-game behavior that reliably caused the access violation (moving to a new segment in a Surface with multiple segments), there didn't appear to be anything wrong with the Surface itself.
I finally discovered the problem when I took a step back and re-read the function that was handling the transition from one line segment to the next. The intended behavior was to check if the Hamsterball was attached to the last segment in the line, and if so, move to the first segment of the next Surface (if any). If the Hamsterball was attached to any other surface, it was to attach itself to the same Surface at the next higher segment index. Owing to confusion on my part, that second case actually attached the Hamsterball to the next Surface pointed to by the current Surface... which didn't exist. So on the next frame, when the Hamsterball tried to move along the trajectory determined by the endpoints of its current line segment... its attached Surface pointer was invalid, and trying to get that data caused an access violation. Now, I understand that it's my fault for not putting a null-guard into the attachment function to begin with. But the way C++ handles pointer errors like this, I was made to believe that the Surface Component I was operating on was valid. It was not! In C#, the call stack would have stopped at the attempt to access it, and it would have been pointed out that I was referencing a null pointer. I'd still have made the error, but the error would have been pointed out much sooner.
In an entirely different incident, I noticed at one point that the Hamsterball was teleporting along the Surface when it hit specific segment transitions. Not all of them, and only if you went in a specific direction. It took a careful proofread and a step-through debugging session to determine what was going on, and the root cause turned out to be C++'s variable shadowing rules. In C++, you're allowed to define a variable in as many sub-scopes as you want. Each new definition takes precedence over the one in any containing scopes. Because I so often deal with indexes of segments, I had, without realizing it, created two variables named "segmentIndex", and operated on the nearer one as if it were the farther one, producing bizarre results. By comparison, C# will not allow you to do that-- if you define a variable in a child scope with the same name as a parent scope, it's a compiler error. Once again, I understand that my variable names should perhaps have been more indicative of their purpose, but I made the mistake anyway-- and when I did, the language shrugged and said "you're the boss" rather than demanding clarity, and I lost productive time as a result.
I already brought this particular issue to the thread's attention before, so I'll only briefly recount it now, but UE4's treatment of Actors within the editor is... inconsistent, I want to call it, with the way they're handled in the actual game. They are, in some ways, actual objects, and in other ways they're simply templates for the real objects that will be produced later. Certain initialization code isn't run, and in particular it's not possible for Components to meaningfully react to certain changes in their parent Actors because changing a property of an Actor completely destroys it. It seems to be an artifact of the UE3 model, which used inheritance instead of composition for defining Actors. However, there was actually a bright side to this whole fiasco: it turned out that the implementation of of another feature rendered it mostly irrelevant.
In the video up above, you can see how the Hamsterball passes through a Surface while moving opposite the Surface's surface normal in the part with the loop. Normally that would result in a collision, but each Surface holds a list of Actors whose Surfaces should be ignored during collision detection. So as long as you're moving along the ground, you can pass through the short list of designated ignored Surfaces. That list of ignored Actors is also used at startup to help prevent Surfaces from welding themselves onto certain other Surfaces. For instance, in the switchback at the far left of the test level where two slopes join onto a flat plane, the plane is rigged up to ignore the lower of the two slopes. This prevents you from going back down the hill in certain edge cases. I could conceivably use the same system to ensure that you always go down the hill rather than up, if the natural progression of the level had you coming down from above.
And I'd be remiss if I didn't mention that at least some of my wounds this week are self-inflicted. There's still an infinite loop lurking in the Hamsterball behavior code that results from the imprecision of floating-point values. To put it quickly, after a certain number of decimal places, floating-point values don't play nice with addition and subtraction. 2 + .000000000000001 = 2. And at a certain point in my code, the movement of an object gets so small that it's treated as non-moving within code that expects it be moving, which turns into a chain of events that never lets it escape a loop designed to consume all of the time allotted by a given Tick(). I was able to work around it by increasing the amount of time in individual "Hamsterball ticks", but I have a creeping suspicion that that's only masking the problem and not solving it. It's going to take some further investigation before I'm satisfied that settings alone can guarantee that the game won't lock up.
My next goal is to spend some time learning Blender and then put together some basic platform tiles with a ground texture attached to them (probably just a simple yellow-and-brown checkboard pattern, in keeping with the Unity prototype) and have a stock Unreal sphere mesh run around on them. That's likely to consume the entire week on its own. Past that, I want to get the Unreal Sample Project Guy affixed to the Hamsterball and see if I can drive his running animation speed according to your current ground velocity.
I realize you'll all be heartbroken to hear this, but there will not be a Kupi Weekly Friday Status Report next week, as I will be out-of-town for most of it to visit family. Just take heart in knowing that a double feature is lurking around the corner. See you then!
Did a post about it on m'blog.
Unreal Engine 4 Developers Community.
I'm working on a cute little video game! Here's a link for you.
Here's some tutorials on animating faster and smarter:
And here's some footage of cool stuff he did in Destiny:
Legends of Runeterra: MNCdover #moc
Switch ID: MNC Dover SW-1154-3107-1051
Steam ID
Twitch Page
Unreal Engine 4 Developers Community.
I'm working on a cute little video game! Here's a link for you.
I always need to test these things on real actual humans, and I myself don't count - somehow I'm completely impervious to motion sickness when developing. However, this movement style feels very safe and intuitive to me - it's more like you move the landscape under you than move yourself over the landscape. Kind of like scrolling on a touchscreen: you fix a point with your finger (in this case, with the metaphorical extension of your hand, the motion controller's laser pointer), and then move the content exactly proportional to how you move the finger.
Unreal Engine 4 Developers Community.
I'm working on a cute little video game! Here's a link for you.
I don't know that I could make a recommendation without actually trying it on a Vive and seeing what it's like. Plus, the last RTS I played to completion was Warcraft 3, so I'm not necessarily the target audience.
That being said, it looks kind of fiddly in the way that I dislike about mouse-selection games. Could you do a paintbrush kind of thing where you wave a large-ish cursor at things and select them additively? I liked that aspect of Panzer Dragoon. You could also pluck some "local select" ideas from console RTS games, like Halo Wars.
The math is just a simple "is point inside polygon" check for all relevant actors within the selection mesh's bounds. (Z coordinate discarded)
The selection mesh is generated by drawing polys between the last frame's pointer target and the current frame's, if the distance is above a certain threshold.
All fairly simple
Unreal Engine 4 Developers Community.
I'm working on a cute little video game! Here's a link for you.
(If you get a chance to play it survey is up at http://goo.gl/forms/4iMfDL1iDLKex5Dq2 or you can directly respond.)
In addition to tons of other stuff I added a new level transition:
Inspired by Steamboat Willie:
Not exact but probably the best I am going to do with my complete lack of shader knowledge.
Oh and I also hacked together made a website. Because making a game by myself isn't enough and SquareSpace is too goddamn expensive.
I went to talk on VR that went into how fixed points of reference in the VR space can reduce motion sickness, maybe that is what is happening with the landscape.
A lot of it too is head space. If you feel like you are being moved and your inner ear is not getting expected motion you get sick. This approach like Kashaar said you feel more like god and are moving the world around you.
Being moved as a person is disorienting, being in a vehicle less so and moving the world around you is not nausea inducing at all even though all three instances can have the world moving around you the same way. This is also why teleporting is somehow easier on the player then sliding to the destination.
So I have an idea, and I'm sure it's been thought of before, but how about I create a Discord server where we could talk about what we're working on and shoot the shit? Maybe we could host a recurring PA dev-night or something on there. Just a thought.
Twitch: KoopahTroopah - Steam: Koopah
I don't have an Android device, so I'll just ask; do you need to manually remove the clotheslines and birds? Also, have you thought about a secondary mode where you fall endlessly (getting faster over time) and earn points by popping balloons and/or removing obstacles? Thought it might be a nice alternate mode if you can fit it in.
Legends of Runeterra: MNCdover #moc
Switch ID: MNC Dover SW-1154-3107-1051
Steam ID
Twitch Page