Play it here. Without further ado:
Goals
I’ve been in a fair number of Ludum Dares, so by this point I try to mix it up a bit by having goals each time. This time my main goal was to make the game 3D if possible, and to do it in Unreal Engine 4. Every one of my previous games has been 2D, so I thought this would be an interesting change.
The Theme
The theme kind of clashed with my goal of making the game 3D. However, I eventually came up with the idea of a physics-based game where you try to prevent crates (and other cargo) from flying around a cargo bay as a ship makes maneuvers. I also planned a lot of other stuff, like random events where the player must push fuel containers into a chute in order to refuel the ship, and a part where pirates demand that some of the cargo is pushed out the cargo door. I also planned a lot of dialog that would explain why all the various things were happening.
What Went Well
APEX Destruction
APEX destruction worked very well for smashing up the crates in a satisfying way. There were some weird quirks, like in order to access the individual fragments you have to get the PhysX rigid bodies, which requires including some unusual headers, but all in all it worked out well. Getting the level of HP of the crates right to make them destructible when flying around but not so destructible that they fell apart randomly was a little tricky.
Unreal Engine 4’s Rendering
UE4 has an excellent rendering and lighting system. I think the fact that the game looks decent despite my atrocious 3D graphics skills is a testament to what UE4’s materials/rendering system can do.
What Did Not Go Well
The Design
As the game took shape, I realized that doing all the dialog and events was going to be too much for the player to handle at once, so I removed all those aspects. The end result was the game was very simplistic, and had little gameplay. I also originally had the player controlling a robot instead of a force field. I found that the robot was too hard to control and couldn’t react quickly enough to events, so I switched to the force field. This however made the game a bit simpler and less interesting.
UE4 Stability
Since UE4 is still under active development, it still has some random crashes. One was that moving a camera during a cinematic seemed to cause random crashes seconds after the move. I’ve switched cameras in cinematics before so most likely this was something very specific to this game, not sure what. I eventually just manually did the camera move outside of the cinematic editor.
The other significant crash was one that happens if you switch levels while the UI system is in the middle of an animation. In the end I just added a delay to prevent level transitions while the animation was still playing.
HTML5 Build
This has bitten me so many times that It’s still a wonder to me how I’m always caught unawares by it. I assumed that all the HTML5 build issues would be related to the OpenGL ES pipeline (which UE4 uses in HTML5 mode), so I carefully used the “mobile preview” mode to check that everything was good. About 4 hours to release, I actually tried a HTML5 build and discovered that APEX destruction is not compatible with HTML5 mode. At this point destruction was such an integral part of the game that removing it was impossible. So I switched to Plan B, which was two builds, one for Linux and one for Windows. I also changed my lighting setup from “mobile” mode to “desktop” mode, which required deleting my directional light and replacing it with a bunch of spot lights.
However, I soon realized that I didn’t have a Linux machine with the needed specs, so that was out. I also considered making an Android build, it turns out APEX destruction isn’t compatible with that platform either (at least as part of UE4).
Windows 8
Everything worked okay on my Windows 7 dev machine, so I transferred the game over to my Windows 8 laptop for additional testing. After clicking through at least two dialog boxes warning me that my own game looked suspicious, I found that the game crashed on startup about 90% of the time. While regenerating the debug database files so I could get a stack trace with symbol names, I plugged my laptop in and discovered that the crashing had stopped. Although I can’t say for sure, it looks like the power saving features of the laptop were causing the crashes.
I eventually unplugged the laptop again and got a stack trace, which indicated that the problem was in UE4’s Oculus Rift subsystem, which essentially meant that I couldn’t reasonably fix it during the compo. I ended up putting a warning on my game’s page telling people to plug their laptops in, but the whole thing just seems absurd.
Lighting Switchover
When switching the lighting from mobile to desktop as I mentioned above, I changed the lighting setup from a single directional light to a bunch of spotlights. I covered the cargo bay with enough spotlights to light it, but I forgot to light the ramp outside the ship. I only noticed this oversight about 30 minutes into submission hour with my game already submitted. I decided that since it was still during the submission hour it was okay for me to add the extra light and re-submit. I just wish I’d checked for obvious stuff like that more carefully.
Native Deployment
From what I’ve heard so far, my laptop isn’t the only computer that thinks this game looks suspicious. With the HTML5 build not working, there isn’t really anything I can do about this short of getting an Authenticode cert (which costs around $499/yr), unfortunately.
Lessons Learned
Keep it Basic
I’ve noticed a tendency on my part to try very “weird” game designs in recent Ludum Dares. I think the problem is that I’m trying to avoid similarity to previous games I’ve made. But the problem is that these games often end up being confusing and/or not very fun. I should really just try to make a fun game and not worry so much about repeating myself.
HTML5 Build Verification
Considering how many times this has happened to me before, as in Ludum Dare 23 where it turns out that PlayN + Transformation Matrices + HTML5 Build = Blank screen, or Ludum Dare 29 where it turns out that Box2D + Scene Query + HTML5 build = Freeze, I really have no excuse for not verifying that all features work in a real browser. In future Ludum Dares I will be sure to try my game in the final shipping mode in a real browser every few hours to make sure this doesn’t happen again.
)
