This will be by 7th LD48, and I have to say, I’m really looking forward to it.
After my wild experiment with Flash last time, I think I’m going to go back to good ol’ Java/PlayN. Here’s my toolkit:
I’ve also done a warm up game, which can be found here.
Here’s a screenshot of my partially completed game “Detour”. For my take on minimalism, I decided to go for an RPG with ASCII art and no sound or music.
Next up: Combat!
Whew! I don’t think I’ve ever cut it that close before. I think this design got a little out of control, so I had to scrimp a bit on testing. Still, I’m fairly happy with how it turned out. Try Detour here.
This will be my 8th LD48. Here are the tools I plan to use, unless I get some crazy idea after the theme is announced:
Despite some deployment issues, my game, “Flameout” is finally done and ready.
Play it here. I’ll try to get a post mortem out later.
This’ll be my ninth Ludum Dare. Unless the theme really calls for something different, I’ll probably be using:
I’ve completed my entry, Ring of Oil, where you must take a single robot through an entire tournament in the eponymous ring without any repairs. I wish I’d had a little more time to balance it, but at least there is a lot of robot destruction in it. See it here.
I’m in! This will be my 11th LD48. My toolset (subject to change in the case of last-minute whimsy, naturally):
Here’s a screenshot of my game, Translation Points. I’ve just exited one of the points into a sort of fiery dimension, and some of the fireballs from this dimension are being sucked back into the point and back into mine.
I’ve finished my submission, Translation Points.
I had some last minute deployment issues that ate into my testing time, but I think its at least reasonably polished. Reasonably.
I’ll see if I can get together a post mortem later.
This will be my 12th LD48. My toolset:
Here’s a WIP screenshot of my game, which is tentatively titled “Crate Commander”, showing smashed crates all over the cargo bay.
I’ve finished my entry, Crate Commander. The gameplay is a bit more simplistic than I’d like, but at least I managed to get it done in time. Play it here.
Play it here. Without further ado:
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 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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
This will be my 13th LD48. My toolset:
Let’s do this!
Here’s a screenshot of my test vehicles that I’m using to get my vehicle physics just right.
My game is tentatively called “Armament Proving Grounds”. Hopefully the final version will be a little less gray though.
I’m in! This will be my 14th LD. My toolset (barring any last-minute changes depending on the theme):
I’ve finished my entry, Vale of Embers:
So far only Windows. I’m hoping to make a HTML5 version, but it looks like it’s going to need some optimization to work in a browser.
My entry 48 hour compo entry was Vale of Embers, a game where you play as a raid boss and must fend off various raiding guilds:
