As a fallback to make the beginning part a bit easier, spacebar works too.
Try rapidly left clicking with one hand and hitting the spacebar with the other at the same time, or alternate hitting the spacebar with both hands.
A member registered Oct 12, 2016 · View creator page →
Creator of
Play in browser
A game where you play as @dril and venture forth to defeat the infamous Ass Downloader.
Platformer
Play in browser
Recent community posts
Update 7: Oh noes!
Hey! I didn't finish on time. I unfortunately ran into some packaging issues with UE 4.25 today, and I spent most of the hour before jam close trying to package the game and deal with import problems and toolchain differences. Between you and me, it's actually been years since I've last packaged UE4 for distribution!
I had a moment where I contemplated publishing a placeholder entry and upload the binaries after submitting the game, but that didn't feel like the right thing to do. In general, the game is also still in a very unfinished state, much less finished than I'd hoped -- the only difference between last update and now is that I built a simple adaptive soundscape (authored using FMOD) into the demo level.
I like how this project is turning out way more than I anticipated, so I plan to continue working on it a bit alongside my other projects during my spare time. If anyone still wants to somehow link to this game or reference it from the planned site that's mentioned in the submission form, I'm cool with whatever. After all, it's all about the journey, and you were right here with me all the way! :)
In summery, I had a big productivity hit during most of this week, but today was especially messy for a few reasons (most of which is really my fault, not the software I'm using):
- Packaging problems -- I should have been testing production builds all along, rather than leaving it as an unknown until the last hour.
- The biggest blunder was definitely setting up FMOD on the last day -- I should've done it on day one. I know better than this. I wanted to bang out a quick soundscape, but it turned out that the FMOD team hadn't updated the UE4 plugin to support UE 4.25, which totally makes sense since it's been out for only ~1 month and we're living in strange times. I decided that adaptive audio was important enough to bite my lip and spend a couple of hours patching the FMOD plugin and properly configure the sound bank imports. There was some big *sigh* energy today as I pummeled through missing headers and random segfault after random segfault. I love FMOD, so I'm still stoked that I have it working fine now.
- miro.com had downtime today, and that's where all my project notes are stored! I tried to remember and rewrite the plan I had for today in another document, which took a bit of time.
Retrospective
Here's the rolling retro I've been keeping throughout this jam:
What went right?
- Some of my best learning happens during game jams:
- I Managed to learn a lot of important things about UE4:
- You can easily expose public fields for scene authoring in the editor by using EditAnywhere. I can't believe this fact eluded me for more than 3 years of off and on UE4 use! (Well, more off than on I guess)
- UE4's cinematic tools surprised me in terms of how pleasant they are to use! For example, the Cine Camera seems to have pretty accurate and predictable real-world camera emulation parameters like f-stop (to adjust aperture size on a hyperbolic curve) and the distance of the focus plane. No need to manually adjust FOV or blur/distance curves to get realistic looking camera behavior. For example, when I turned down the f-stop and pulled the focus plane close, I was pleasantly surprised to see an accurate-looking bokeh effect, where splotches of color formed that appeared to take the shape of an actual aperture stop for angles with higher light volume, rather than all color just being evenly blurred together. You can even adjust the shape by changing the number of blades on the aperture stop mechanism using the "Diaphragm Blade Count" parameter. I'm obsessed with this virtual camera.
- Authoring the track using a USplineComponent offered many conveniences that saved time.
- I Managed to learn a lot of important things about UE4:
- Blender is always a win. Thanks to muscle memory built over the years, I can usually model, map UVs, texture, and rig what I need pretty quickly. I am a bit slower with animating than I'd like to be, though!
- UE4's C++ hot reloading went above and beyond the call of duty. Last time I used UE4, I pretty much had to restart the editor every time I made any constructor changes. It looks like they somehow managed to fix most of the state desync problems and crashes.
What went wrong?
- Blender's workflow of converting Actions to NLA Action tracks is funky and finicky. I made a lot of mistakes here and had to backtrack and waste time. It'll serve me in the future to look into the UI's behavior more deeply and develop a consistent workflow around it.
- Importing Blender-authored 3D assets into UE4 was difficult to get right, and I ran into several compounding UE4 bugs that caught me off guard and caused some lost work. For example, I was trying to work around a bug where not all of the animations were getting imported from the FBX, but UE4's editor crashed a couple of times when I tried to move a fresh import of the animation assets to another directory, which seemed to leave some of the assets in a corrupt state on disk and no longer visible in-editor. I have some ideas about what happened here that I won't get into, but I eventually just cleared everything out and re-imported things.
- UE4's toolchain out of the box doesn't have some modern C++ features enabled that I like, such as designated initializers for structs.
- I ended up only getting to audio on the last day, and I had to patch problems in the FMOD UE 4.24 plugin in order to get it building against 4.25.
- Packaging for production during the last hour did not go smoothly. :o
Takeaways
- Working with UE4 blew my expectations out of the water this time around, and I absolutely will be reaching for it again in the near future. Over the past couple of years, I've been working off and on reducing my friction with UE4. In addition to optimizing my hardware for much faster build iteration, I can say that I wholly endorse Rider for Unreal Engine -- it's hands down the best IDE experience I've had with UE4 by a long shot. With other IDEs, I've sometimes had to resort to shutting off intellisense due to the extreme performance issues and my low tolerance for IDE lag. Not so with Rider, it's fast and accurate. In all, there has never been a better time to try starting a UE4 project than today. I'm so glad I decided to work with it.
- Participating in this jam was a perfect opportunity to use new tools and improve my existing workflows with more tools. For example, I had some good organizational gains with Blender in terms of animation authoring. I've learned more during this jam than I have during any other for sure!
- Keeping a dev log is always a fun thing for me. I hope you enjoyed it too, thanks for checking it out!
- I like birbs -- if there's another birbjam in the future and you remember me, reach out and let me know, I might miss it!
Feel free to reach out if you have any thoughts, questions, comments. Oh and see you soon in another jam. :)
Places you can find me: YouTube, Twitter (@algebrandon), GitHub (bdero)
Brandon
Update 5: Title display and spline track
Today I decided to incorporate the cinematic I did yesterday as a sort of intro/title screen. I spent a little too much time making a text shader that makes the text wiggle a bit and look like it ha caustics overlaying it. Here's what it looks like right after the bird flies by before fading out:
The contrast isn't really high enough yet and the typeface needs work (just default roboto right now).
Aside from that, I started working on the flight track system, and I definitely that authoring the track with a USplineComponent directly was the right choice. It turned out to already have all the built in editor data visualizers I was planning on throw together myself. In particular, I was pleasantly surprised by the inclusion of a "thickness" radial area visualizer around the spline based on the spline point scale and a constant multiplier.
The plan from the beginning was to to scale the movement speed, restrict the movement area, and adjust the camera's FOV based on some additional value per spline point, and so I was already planning to build some kind of editor-only visualization that does exactly the same sort of thing. Using the spline point scale values as a track size multiplier immediately allots extra conveniences too: For example, I can just use the scaling gizmo to make in-editor adjustments to the track size rather than having to tweak properties -- I couldn't ask for a better level authoring setup!
Real talk: The only serious improvement opportunity for spline authoring I can think of in UE4's editor is having it read my mind so that I can will the spline points into place. Get on it, Epic Games, chop chop!
Here's what the spline looks like for a quick test track I authored:
See you next update!
Update 3: Git LFS setup, animation state machine, and water
Here's a short list of the stuff that got done today:
- Git LFS setup -- not a pain at all these days.
- Built an anim graph; Polly now has smooth state transitions between idling, liftoff, and gliding/flapping, and the transitions look great with minimal effort -- success!
- I decided to make the Bird inherit from Pawn rather than using the Character or CharacterMovementComponent gameplay framework classes, since these things are better for land creatures and human characters.
- I made a C++ Pawn for Polly and a blueprint that inherits from it to override defaults.
- Built a water material with reflection/refraction/edge foam. Here's what the material graph looks like:
I did run into one big issue that sucked up a couple of hours today:
After finishing up with the initial anim graph, I went ahead and bound it to the skeletal mesh in the new Bird Pawn, and was greeted with a slew of new compilation errors in the anim graph. At that moment, I immediately slumped down in my chair, realizing that I hadn't yet slain all the import dragons. It turns out that Polly's imported skeleton asset just suddenly disappeared from existence along with most of the animations. I was able to get the skeleton to re-import and map the one remaining animation to it easily, but couldn't get the re-import to pull in the remaining missing animations. I had to resort to running the importer in a fresh directory and configuring it to only import the animations there. After getting them imported again, the editor crashed while I was trying to relocate the assets, which put the new assets into a broken state where they were no longer visible in the editor, but still existed on disk. I eventually cleared out all the new and old assets, re-imported one final time, and all was well.
Another issue I noticed was that, despite my careful and deliberate attention to getting the axis conversions right during both the Blender export to FBX and the import to UE4, Polly was actually facing in the Y direction, not the +X direction... (UE4's forward direction). After some trial end error, I noticed that an option akin to "Force +X as forward direction" was unchecked on the importer dialog. Flipping that on got it working as I'd hoped.
I feel like it's starting to look kinda neat with that water in place! There's still a lot I'd like to try with the terrain shading, but I should probably focus on building some rocks and trees to use as obstacles soon.
See you next time!
Update 2: Engine choice, importing assets, and terrain
Warning: Much rambling ahead.
Up until today I hadn't actually decided on what engine to use. I'm usually tempted to reach for Unity when attempting game jams for its no-hassle HTML5 packaging and everyone's favorite: Good ol' prefab/live object refs. You know, when you drag and drop things from the scene into inspector properties? It makes prototyping things so genuinely gross (the good kind of gross, I mean).
However, it's been a while since I've attempted a jam in UE4, and there's a lot that's been happening in the UE4 ecosystem that's been getting me a bit fired up. For one, I've always loathed the poor tooling experience around writing C++ for UE4 projects, but JetBrains has been working on a domain-specific IDE for UE4 (Rider for Unreal Engine). I tried it out a few months back, and I was pleasantly surprised at it's speed and accuracy.
To be clear, I have no hangups what-so-ever with UE4's abstractions/tools/frameworks/internals or even C++ itself -- my problem is that VS2019 + Resharper C++ intellisense in a UE4 codebases is:
- dog slow due to UE4 being a huge codebase with 100s of thousands of symbols to index, and
- poor quality due to UE4's heavy reliance on code generation (UnrealHeaderTool) and preprocessing (deeply nested C++ macros).
And codebase-wide intellisense is kind of important for productivity in UE4; I find that remembering common macros isn't much of a problem, but I do often forget where certain headers are located, and without good completion, I tend to spend a lot of time grepping the codebase or surfing docs to re-find headers.
So with a new IDE in hand, my body is ready.
I fired up UE4, exported Polly, and worked through all manner of issue with the imports. First I had multiple root bones, then I didn't have smoothing groups exported correctly, then my axis conversions for UE4 were wrong, then the animations were scaled down 100x due to a unit conversion problem, and then... the worst issue happened.
Time for a little side tangent about Blender...
In Blender, I usually just define actions for animation export. However, the "start" and "end" frames aren't actually stored with actions. And so when exporting actions, Blender automatically renders all frames between the earlest keyframe to the latest keyframe in the action. This behavior works great for non-looping animations, but scales poorly when building lots of loops (which is mostly what I do). So I finally decided to figure out how to do things "right", and defined an NLA action strip for each animation with customized start/end frames, and used the "NLA Strips" option under "Bake Animation" during FBX export. This bakes the contents of each non-muted NLA strip as a separate animation in the FBX.
Out of all the quirky UIs in blender, I've always felt that the NLA editor is among the most quirky. I typically only use Blender to author short animations and loops, and so up until now, my attempts at using the NLA editor have usually ended with me throwing my hands into the air and reverting to a less scalable authoring patterns.
At first, adding these NLA Action Strips seemed to be going smoothy (this can be seen in the timelapse I posted yesterday). It was simple enough to get the animations set up initially... or so I thought.
Once I actually got to the point where I could view animations in UE4 today, my loops were all cutting off at seemingly random spots! After a whole lot of trial and error, I realized that I was accidentally adjusting "Strip Extents" for some of the strips instead of the "Action Extents". After fixing them, it took me a while to realize that when you make changes to "Action Extents", said changes also append to the "Strip Extents". And so after correcting the "Action Extents", Blender automatically adjusted the "Strip Extents" to reflect the difference, and so correcting the "Action Extents" just propagated problems rather than solving them.
So in all, I thought that getting Polly imported would take 10 minutes, but it turned out to suck up hours. Oh well! Future models won't be this hard.
After getting the FBX import tuned right, I moved on to building the start of the terrain material.
See you next update!
Update 0: Groundwork and base asset building
Alright, I was in a jamming mood this weekend and found that this jam met my criteria:
- The jam had just begun -- I wanted to start working on something immediately, not wait a few days.
- Birbs!
- 2 weeks - I usually prefer planning out jam projects that wouldn't be possible to reasonably complete in a weekend. Also, having a couple of weekends in the jam schedule is important; I can't usually squeeze out a large volume of work during week nights after the day job.
- Did I mention Birbs? How does one NOT participate in a jam about Birbs?
The themes sparked interest in a few different genres for me. I immediately thought about building out a sort of side-scrolling platformer with Flappy Bird altitude controls. The mechanics would go something like: You need to fly up into the trees and chirp in order to find a mate, periodically returning to the deciduous forest floor in order to find food and manage stamina.
However, I wasn't really jiving with the idea of building a stressful mechanics-heavy game for this. The idea of gliding through a forest and casually swaying around in a more relaxing setting started to take over, and after fleshing out a few more genre maps I finally ended up choosing this one:
It's a game where you hatch and leave your nest in the morning, glide through a guided forest obstacle course with Star Fox 64-like rail shooter controls, and arrive at a new nest just as night falls, welcomed by the occupants of the new nest. The night completes and the game repeats.
From here, I started to gather reference material for the aesthetic. I haven't really done much of that hipster flatshading/small color pallet/cell shading style. It's kind of polarizing, kind of like it's the 3D version of pixel art. But I think it has a strong association with casual/relaxing games, and so it seems like a clear fit.
Below is a screenshot of some of the reference material that I quickly gathered to help inspire asset ideas (mostly sourced from Google images and Pinterest) for the look/feel. There's a few low-poly Birbs in different poses and wing anatomy references too, of course!
For the music, I liked the idea of having the melody sound kind of like a bird chirping. I got a bit sucked in and lightly mixed down about a minute worth of music.
There's ~30 more bars of very unfinished music off screen, but I might end up just cutting it and using this short loop in the interest of time. It feels like this loop could stand on its own with a little more polish and variation.
From here, I moved on to modeling the Birbs -- essential! Below is a clip of the initial modeled, rigged, and animated untextured Birb protagonist. Keeping the wings very low poly was a little bit tricky. After some mesh surgery and a couple of failed attempts at compressing the wing with 2-3 bones, I ended up with 4 carefully weighted bones branching out from the inner wing to make the wing look OK when both resting and flying.
More (hopefully) soon!
I decided to ignore the WASM problems, since clearly there are some blocking bugs for WASM builds using the GameObject-to-Entity conversion. That workflow is kind of a key convenience measure being pushed in the modern Unity ECS implementation and examples, and I don't really want to deal with working around it by writing tons of factory functions to replace the workflow.
I'll probably do a bug report if I can still reproduce it later and collect more detailed information.
So, I've written a few simple systems to handle input and tank movement, tag components to distinguish between player/enemy, and components and systems from the new ECS Unity physics package.
For movement, I have a pretty simple and naive system setup to start, where the tanks themselves are dynamic physics bodies with a physics shape, and I'm just simulating force impulses based on the direction of input across all tanks every system update in a parallel job.
public class TankMovementSystem : JobComponentSystem
{
private struct TankMovementJob : IJobForEach<TankInputComponent, PhysicsVelocity, PhysicsMass>
{
public void Execute(
[ReadOnly] ref TankInputComponent tankInput,
ref PhysicsVelocity physicsVelocity,
[ReadOnly] ref PhysicsMass physicsMass)
{
var movementMagnitude = math.min(1, math.distance(float2.zero, tankInput.movement));
var movementDirection = math.normalizesafe(tankInput.movement);
var movement = movementMagnitude/5 * movementDirection;
physicsVelocity.ApplyLinearImpulse(
physicsMass,
new float3(movement.x, 0, movement.y));
}
}
protected override JobHandle OnUpdate(JobHandle inputDeps)
{
var job = new TankMovementJob().Schedule(this, inputDeps);
return job;
}
}
[UpdateBefore(typeof(TankMovementSystem))]
public class PlayerInputSystem : ComponentSystem
{
protected override void OnUpdate()
{
Entities.ForEach((ref PlayerTankComponent playerTank, ref TankInputComponent tankInput) =>
{
tankInput.movement = new float2(
Input.GetAxis("Horizontal"), Input.GetAxis("Vertical"));
});
}
}
This lead me into Yet Another set of mysterious problems:
TypeLoadException: Recursive type definition detected
Unity.Jobs.JobHandle:ScheduleBatchedJobsAndComplete(JobHandle&)
Unity.Jobs.JobHandle:Complete()
Unity.Entities.ComponentJobSafetyManager:CompleteReadAndWriteDependencyNoChecks(Int32) (at Library/PackageCache/com.unity.entities@0.1.1-preview/Unity.Entities/ComponentJobManager.cs:374)
Unity.Entities.ComponentJobSafetyManager:CompleteDependenciesNoChecks(Int32*, Int32, Int32*, Int32) (at Library/PackageCache/com.unity.entities@0.1.1-preview/Unity.Entities/ComponentJobManager.cs:200)
Unity.Entities.ComponentSystemBase:CompleteDependencyInternal() (at Library/PackageCache/com.unity.entities@0.1.1-preview/Unity.Entities/ComponentSystem.cs:699)
Unity.Entities.ComponentSystemBase:AddReaderWriters(EntityQuery) (at Library/PackageCache/com.unity.entities@0.1.1-preview/Unity.Entities/ComponentSystem.cs:608)
Unity.Entities.ComponentSystemBase:GetEntityQueryInternal(ComponentType*, Int32) (at Library/PackageCache/com.unity.entities@0.1.1-preview/Unity.Entities/ComponentSystem.cs:622)
Unity.Entities.ComponentSystemBase:HasSingleton() (at Library/PackageCache/com.unity.entities@0.1.1-preview/Unity.Entities/ComponentSystem.cs:549)
Unity.Physics.Systems.StepPhysicsWorld:OnUpdate(JobHandle) (at Library/PackageCache/com.unity.physics@0.2.4-preview/Unity.Physics/ECS/Systems/StepPhysicsWorld.cs:93)
IndexOutOfRangeException: Index 41 is out of range of '4' Length. Unity.Collections.NativeArray`1[T].FailOutOfRangeError (System.Int32 index) (at <5e35e4589c1948aa8af5b8e64eea8798>:0) Unity.Collections.NativeArray`1[T].CheckElementReadAccess (System.Int32 index) (at <5e35e4589c1948aa8af5b8e64eea8798>:0) Unity.Collections.NativeArray`1[T].get_Item (System.Int32 index) (at <5e35e4589c1948aa8af5b8e64eea8798>:0) Unity.Physics.BoundingVolumeHierarchy.Refit (Unity.Collections.NativeArray`1[T] aabbs, System.Int32 nodeStartIndex, System.Int32 nodeEndIndex) (at Library/PackageCache/com.unity.physics@0.2.4-preview/Unity.Physics/Collision/Geometry/BoundingVolumeHierarchyBuilder.cs:571) Unity.Physics.BoundingVolumeHierarchy+FinalizeTreeJob.Execute () (at Library/PackageCache/com.unity.physics@0.2.4-preview/Unity.Physics/Collision/Geometry/BoundingVolumeHierarchyBuilder.cs:850) Unity.Jobs.IJobExtensions+JobStruct`1[T].Execute (T& data, System.IntPtr additionalPtr, System.IntPtr bufferRangePatchData, Unity.Jobs.LowLevel.Unsafe.JobRanges& ranges, System.Int32 jobIndex) (at <5e35e4589c1948aa8af5b8e64eea8798>:0) Unity.Jobs.JobHandle:ScheduleBatchedJobsAndComplete(JobHandle&) Unity.Jobs.JobHandle:Complete()This issue appears to be identical to an issue that two different abandoned threads in the Unity forums
were referencing. around ~90% of the time when I hit play, the console is flooded with errors and the tank falls right through the floor. The other ~10% of the time, there are no errors and collision works. Because these errors continually spam each frame from start-time onwards, I'm not super sure this is actually due to a race condition. I suspected what might be happening here is that the system ordering is not really deterministic and might be executing in some hashed order for any systems which don't explicitly specify ordering rules. And so maybe there is some kind of physics initialization system that needs to run before jobs depending on physics systems, and that's not happening.
Now, removing my own physics-reliant systems doesn't fix it, nor does removing my custom step physics entity.
Taking a look at the EntityDebugger, there seem to be 4 physics-related systems running continuously... let's see if there's a problem by unpacking the system ordering constraints:
- BuildPhysicsWorld - No order constraints
- EndFramePhysicsSystem - [UpdateAfter(typeof(BuildPhysicsWorld)), UpdateAfter(typeof(StepPhysicsWorld)), UpdateAfter(typeof(ExportPhysicsWorld))]
- ExportPhysicsWorld - [UpdateAfter(typeof(StepPhysicsWorld)), UpdateBefore(typeof(EndFramePhysicsSystem)), UpdateBefore(typeof(TransformSystemGroup))]
- StepPhysicsWorld - [UpdateAfter(typeof(BuildPhysicsWorld)), UpdateBefore(typeof(ExportPhysicsWorld))]
I'm not seeing any inconsistencies or ambiguity with this ordering - it should be executing like this:
+----------------------+ | | | BuildPhysicsWorld | | | +------+---------------+ | v +------+---------------+ | | | StepPhysicsWorld | | | +------+---------------+ | v +------+---------------+ | | +------+ ExportPhysicsWorld +------+ | | | | | +----------------------+ | | | v v +--------+----------------+ +---------------+--------+ | | | | | EndFramePhysicsSystem | | TransformSystemGroup | | | | | +-------------------------+ +------------------------+
So clearly, looking at the stacktraces, most of them stem from OnUpdate calls in StepPhysicsWorld, but the exceptions are firing from within the job system itself, which unfortunately I have no visibility into other than a decompiled interface before crossing over into native compiled instructions. The ECS components may be visible to me, but the job system is a complete blackbox... And that kind of sucks, because I probably would have figured out what the bug is and fixed it by now if it wasn't. Based on the totally wonky numbers that the out-of-index is returning (huge negative and positive numbers) I'm assuming that there is either some uninitialized or corrupt memory being used as some indexing value by the job system, but I have no way of really debugging it unless I want to spend weeks trecking through instructions in IDA.
Next I tried adjusting several knobs randomly just to see if there would be any affect, like switching to standalone PC build mode, using .Net 2 instead of 4, Mono instead of IL2CPP, switching from Unity to Havok physics mode, etc. No dice.
I removed all the starter cruft from my project and tossed it in a public git repo just to make sure I can keep track of these issues in a minimal project. Tomorrow I'll probably report these bugs with repro instructions on the public Unity bug tracker.
By the way, itch.io's rich text editor seems to have severe consistency and predictability issues. Things would be a lot easier if they allowed for doing all text editing in markup-mode (markdown, BBC, HTML, whatever format they're storing this text to the database with). Especially for pasting unformatted text. Maybe this would make for a good suggestion to the itch.io team.. I think there's a forum for that, somewhere. :)
I know it's not a requirement, but I just really feel the need to finish something, so I'm going to focus in and build up a fairly simple vertical that I should be able to scale out quickly. In particular, I'm going to make a little browser twin-stick, in the same vein as Wii Tanks.
(Screenshot from this video)
So here's how it went today (7/10/2019):
I fired up Unity Hub, downloaded 2019.3.0b6, and templated a new Universal RP project called "Just Tanks". Immediately tested a WASM build to see if it even works (historically I've never had a beta version actually produce a working WASM build), and it worked.. so far so good.
Next, fired up the package manager, scrolled through the preview packages, picking out all the ECS stuff I was pretty sure I needed. A LOT has changed since I first played with DOTS a few months ago, but I was pleasantly surprised to see most of the old methods I tried to use had unambiguous deprecation notes. Ended up getting confused that there seemed to be no mesh rendering component while writing code to spawn some test entities, and so I skimmed the ECS release notes to find that they moved the mesh renderer I was looking for into the "Hybrid Renderer" package. I don't completely know why, but it seems to have something to do with the scriptable render pipeline not being fully built for DOTS, and I guess that package has a bunch of tape and glue.
Now, here's where the trouble starts: From here, I looked over the current official ECS samples to see what's new, and noticed that most of the samples seem to be doing hybrid-y editor friendly things. For example, the samples seemed to be authoring GameObjects in the editor with regular components and writing a special MonoBehavior implementing "IConvertGameObjectToEntity" and sporting an ominous "[RequiresEntityConversion]" attribute. Then I remembered something from the talks I watched: Wasn't there just a script I could shove on pretty much anything and it'd do most of the ECS conversion work for me? Sure enough, I found "Convert to Entity", which I promptly slapped on my silly placement tank.
Alright, so looking at the Entity Debugger, at this point I had a couple of Entities getting built, and my little tank GameObject hierarchy was also properly converting into a pile of entities.
It was time to try another WASM build -- and BOOM out of bounds exceptions. I tried doing a debug build to get a legible trace, but no dice, we've got a Heisenbug on our hands. I spent the next 2 hours removing plugins and deleting code and rebuilding to figure out what caused it, with each WASM build taking > 10 minutes each. Turns out removing "Convert to Entity" fixes the problem. Taking a quick look, it's not doing anything too crazy, it's mostly just using utilities in "GameObjectConversionUtility", which is also how one of the ECS examples converts prefabs into Entities.
Anyways, that's all the time I have for today. I'll have to try some other conversion methods tomorrow, or failing that I'll just go with writing factories to generate entities per archetype. At least it's building now!
Bask in the professionalism of my 【ｃｏｒｎｆｌｏｗｅｒ ｂｌｕｅ】 .
Been in a bit of a funk for the past few weeks, so I've been thinking about trying some new stuff in a game jam to mix things up. A few days prior to October 1st, I made a note to participate in this jam, but ended up forgetting about it until about a week in. Better late than never, I guess!
I've been working on an engine project for the past couple of months, as well as a couple of UE4 pet projects, but Unity Copenhagen just happened not too long ago and DOTS is starting to look more practical with each passing day -- so I'm giving that another shot with a new project.
FYI, I can't seem to post the whole thing because this keeps happening on itch:
So I'll post in parts. (Also, apparently inline images don't work either, so I'll need to upload them one at a time instead)
