Alright, all woke up and ready for seconds! This time I'm gonna try updating the progress a little better when I can, since I'm still simply too scared to just put up a live stream going and endure the chaos that might ensue.

Team:

• @Devastus | https://twitter.com/devastus
• @Mindhead | https://twitter.com/NikoFinsk

Tools of the trade:

• Unity 5.6 - with a bare set of plugins and utilities
• Reaper
• Blender & Maya
• A coffee machine and a ridiculously huge mug (just like my face).

Time to get some coffee. Good luck everyone!

Well, after some much-needed rest it's time for a little memorial for the second Ludum Dare entry we've ever done with @Mindhead.

Check out Unnamed Space Project

As an 180 degree turn compared to Dethroned, this entry is personally a disappointment. The blatant facts of the matter is: - 1) We had, in my humble opinion, several better ideas to work on, but kinda panicked and chose the "easiest" due to presuming that the other ideas took too much work to do correctly - 2) We kinda did not make it in time, as the game was crashing due to multiple reasons at submission time and required extensive fixing in order to get it up to speed. - 3) The end product does not resemble the original idea too well.

To describe the idea in short:

Fly from planet to planet, revitalising and colonizing these tiny barren wastelands with the newest Insta-Grass Pulse Cannon technology installed into your spaceship, and defend the process from angry aliens that don't like strangers. Bullet Hell-gameplay, Tower Defense building mechanics, weapon upgrades, stylized colourful 3D graphics coupled with a banger Synthwave soundtrack.

You can quickly see that only a handful of this actually came to be, starting from planet being a half-cut hemisphere for no other reason than to make things easier to do in a short time.

The project scope was a bit too big for us, and it certainly didn't help that coming in I was already suffering from a rather severe week-long sleep deprivation. Nevertheless, despite the result not being that satisfactory, it worked very well as a practice stretch to design responsive gameplay and 3D assets.

Animated GIF

• I spent a lot more time on individual mechanics this time, like customized physics for precise controls. I put effort in designing things modular so that Entities, Controllers and Weapons would be extendable, reusable and work under the same hood. This cost me time though, possibly too much since I had little to spare on the actual content in the end, and by the end of the Jam things started breaking down as I quickly tried to tack stuff in together. End result was that the game crashed in several different steps and was practically unplayable without doing a sum of bugfixes to it, albeit having pretty good systems underneath.

• I didn't get to make Camera Shake FX stuff, better UI, and most of all, all custom shader work (there was a lot of that up in the TODO lists) and other visual stuff that I was really looking forward to were totally left out of the equation.

• Of course, I did the most unlikely thing and almost totally missed all audio stuff. I was able to tackle up two short loops in the final hours of the Jam. That, considering that I'm a musician and sound technician first and everything else second, is pretty horrible in itself.

However, all this underlying API I made works very well in giving me the controls to extend this further if I deem it interesting enough (just like how I said I was going to do with Dethroned, eh :P). Some of the missing features I've already implemented in a Post version like Camera Shake n' stuff, so I'll post that in the game page at a later date.

That's things in a nutshell. TL:DR; I basically got trampled by the amount of work in an idea that didn't sit comfortably with me. Hopefully next time we'll spend the hours in a more elaborate idea, since that would feel more rewarding even if it didn't get finished.

Alright, we're going for the third. Last time I personally screwed up real good, but maybe we'll aim for something smaller this time around.

• @Devastus | https://twitter.com/devastus
• @Mindhead | https://twitter.com/NikoFinsk

Our approach might be a bit dependent on the theme and idea, but most likely we'll be going with the good ol' basics:

• Unity3D 2017.1 Engine
• Reaper & bunch of VSTis for music
• Blender & Maya
• Pyxel Edit (if going for 2D)

Good luck everyone! Here's to hoping things go smoothly (sure thing bro).

Third's the charm they say, right? Time to have a look at our Ludum Dare 39 entry with @Mindhead.

Check out Gain Quest: The Art of Muscle

Considering how disappointed I was at my own personal performance last time around, I can safely say that I'm relieved. I had this idea pretty much instantly from the get-go, which enabled us to really hammer down on the work right away (well, right after some sleep). We decided to really tone down on the scope which resulted in a much more comprehensive end result. I had some downtime due to some electrical outage, and yet we we're able to push a submission in good time.

What went right? * We aimed for a small game this time. This is the main takeaway for anyone who has participated on Jams and hasn't gotten preferable results. Large-scale ideas will most likely not succeed, for 72 hours, let alone 48 hours, is simply not enough time to flesh out those intricate details. Scheduling and concentrating becomes easier the less filler you have. Even more so, people rarely play LD games for more than 5-10 minutes, so having less content makes it easier for you to make that 5-10 minutes awesome. Add to that how much easier it is to test your game. KEEP IT SMALL. This is obviously something we failed at last time. * Accept that you're going to run out of time. Instead of trying to desperately include things I really liked, I actively shortened our feature list as soon as I had the hunch that things weren't going to get done in time. That was pretty often, and resulted in a playable, fun little game instead of a possible bug-crash-fest. * I started on the UI right away. First, this game was very UI-oriented, with minigames done with UI components being the main mechanic. Second, I have a slight disdain towards Unity's UI system all things considered, so I thought blasting through the painful process from the very start will help me afterwards, and also help with the concurrent problems regarding the lack of visual feedback we've been having in earlier entries. I was right, and while there is still to improve upon, we performed much better on that area overall. * The choice to go with 2D. While 3D is very much manageable and my usual preference, 2D just usually requires less work from both graphical and coding perspective. It is also lighter. * I designed a more efficient, yet still simple state machine to run the game loop. Incidentally, it does not require much code to create a custom IEnumerator-swapping State Machine complete with transitions. Such state machine can make sequential gameplay so much easier to code and manage than with the quick-and-painful Update-loop switch() type crapjob I had in my two earlier entries. Sometimes a more complex solution can land you an easier time afterwards, so plan carefully. This was an adaptation of an earlier, more complex State Machine I had made a Node GUI Editor for, so I had enough experience to build one quickly from scratch.

What went wrong? * Did not take enough breaks. I'd like to believe I did, but the fact of the matter is that I was mostly bashing my keyboard 24/7. I didn't sleep much at all, didn't go get some fresh air, and all that combined really toned down my ability to work efficiently the longer it went on. This is the main reason for mistakes, errors and especially balancing issues in the game. It's a fact, yet I still can't win over my obsession to just keep going :P * No documentation. Ok, I had a small, unfinished feature list lying about somewhere but other than that, I had no documentation on what we were doing. Luckily we had the idea rather clearly set out, but still, it's a grave mistake to not plan things "on paper" and resulted in some time wasted on trying to remember what I was supposed to be doing. * Not much actual game-making documentation either. Not really game-related, but I'd have really liked if I understood to leave a stream on or something to catch my working hours on tape. It's a thing that would only make that time even more valuable as a learning experience, considering all the split-second solutions and efforts you're making to race for that finish line. * Still not enough time left for sounds. This is more of a pet peeve for me, and pretty much related to me simply not being in best shape at the last day. In any case, in reality sound often happens to be one of the most crucial things in getting the feel of the game right, and I didn't get all music and sounds in and that always bugs me. I should start prioritizing them earlier, or try making them the centerpoint of a game for a change.

What was left missing? * Better balancing of minigame difficulties. * Other random people training in the gym. * Status effects that alter the game.

So, we had a blast with this Ludum Dare. I'm currently playing and rating games, and hope everyone else had fun with their creations! Can't wait 'til the next one.

Alright, #40 shall be our fourth trial by fire! This time it's gonna be with added difficulty due to @Mindhead having only one day and a half worth of time to spend on the graphics. It's gonna be a real test of prioritization, project scoping and planning with me being at the helm, that's for sure.

Good luck with LD #40, everyone! I'm definitely gonna need it.

Team (Man In Motion):

• @Devastus | https://twitter.com/devastus
• @Mindhead | https://twitter.com/NikoFinsk

Tools of the trade:

• Unity 2017 - with a bare set of personally made plugins
• Reaper & buncha VSTis (audio)
• Blender & Maya (if 3D)
• Photoshop & PyxelEdit(if 2D)
• SourceTree for Git stuff
• Lots of coffee

I'm gonna try and keep pre-made helper tools to a minimum, but I might have to break my habit of doing every single thing from scratch since I'm already gonna be neck deep in piss with work regardless :P

So we're back at it for the fifth time! I'm hopping in with a new computer at hand, so hopefully I have all the tools up and running before we're stuck in the fray. Maybe even WebGL-exporting works this time.

Team (Man In Motion):

• @Devastus | https://twitter.com/devastus
• @Mindhead | https://twitter.com/NikoFinsk

Tools of the trade:

• Unity 2017.3, accompanied with some pre-made editor tools maybe
• Reaper & buncha VSTis (audio)
• Blender & Maya (if 3D)
• Photoshop & PyxelEdit (if 2D)
• SourceTree for Git stuff
• A squeaky stress ball

I was kinda hoping to get a Linux/Godot environment up and running for this but I'll save that for a later time. Good luck everyone!

What happens when you combine Tower Defense and Snooker/Pool?

Check out Robocalypse: Xtreme Pool Master

I spent a good amount of hours today fixing problem areas and improving the readability, thus I really recommend to take a look at the Post-Jam version.

As eager as I am to see what you guys have come up with, I'll be playing and rating games tomorrow after some well earned sleep. See you then!

Yeah, so, my new computer is completely broken along with several peripherals and thus I have no access to any of my tools, projects, code or software. @Mindhead has to attend to a wedding mid-Ludum Dare.

We're still gonna participate.

The computer I'm using for the time being has Arch Linux installed, so I guess it's time to really go deep. I did say I was saving this for a "later time" last Ludum Dare, didn't I.

Team:

• @Devastus | https://twitter.com/devastus
• @Mindhead | https://twitter.com/NikoFinsk

Tools of the trade:

• Engine: Godot 3.0 (LET'S GO BOIS)
• Music & Sounds: LMMS (if only I had Reaper...)
• 3D: Blender & Maya
• 2D: PyxelEdit (through Wine) I guess?
• Version Control: Git
• Motivation: St. Elmo's fire

I wish everyone luck in what constitutes our sixth run of this jam. Have fun!

So... yeah, it was tough. Here's a little something to recap my experience this time around as I turn over to playing your games instead of stressing about my own.

I started this Jam with my main computer being broken, and used my old computer that now has Arch Linux installed. This meant several changes in my toolset, mainly Unity -> Godot and Reaper -> LMMS (which I aptly didn't even get to use).

I gotta say, the theme wasn't too bad this time around (WHAT?!). I mean, you can get a lot of fun and workable ideas from Running out of space. Our original idea was a hyper arcade shoot 'em up in a destructible arena that encloses on you. Not original, but could've been a fun one.

>> Enter LD Sequence >>

Starting up: Isometric 2D

@Mindhead was offline the whole first day and half, so it was up to me to decide on the course of action. We had a little talk just after the theme reveal on what to do, and I took up the shoot 'em up idea since it rang best to me. I went for an isometric approach, but quickly came to a stop since I couldn't get isometric collisions to import from Tiled to Godot (the plugin didn't seem to support the non-default shapes). In addition I couldn't get the Y-sorting with TileMap to work, which was important because you could fall off in this game.

Next: 2.5D

I decided to rewrite the whole thing to 3D. While this solved my Z-indexing (or Y-sorting) problems, I was now without an outside tool for map making. Godot's GridMap doesn't support custom cell data out of the blue, so I would've had to devise a tool for that (which in the end would have been the right solution here). The bigger problem here was this Sprite3D billboard rotation issue (#18296). Again, you could probably cook up a shader of your own to work around this, but I had already enough on my plate with a totally unknown engine as it is.

Back to plain 2D

Okay, how about angled orthogonal 2D? Let's rewrite again! I had already used up the entire first day trying to find a fitting solution, and now the second day salvaging what was left of the effort. Y-sorting still proved to be a problematic issue. We started scaling down the idea to such degree that it honestly just sounded like shit. Additional roadblocks with my understanding of the engine finally resulted to us giving up.

... Until the last 8-9 hours

Giving up didn't feel like something I do. So instead of leaving things to ruin, I decided that as long as I make something, it's fine. I took a new approach to the theme, a simple puzzle game where moving leaves a trail of walls behind. Collect keys, open locks and go through portals. I quickly fired up Pyxel and drew the barest set of tiles needed to get this stuff working. I threw the earlier code to a backup folder and started from scratch, and got the bulk of the game done in a couple hours. I even got an auto level importer plugin done. Regardless, the mechanics were too few and time was short, so there's only a small handful of levels.

<< End LD Sequence <<

So, how do I feel about Godot?

I really, really like the Node structure. You only need to wrap one concept around your head and you're ready to make the most of the engine in a multitude of ways. I don't necessarily like GDScript (I humbly thank thee for the future C# support) or the fact that you're using Strings for almost everything, but at the very least the "lazy" approach gets you results quickly. This is also a pretty artist-friendly approach, so I could see the prospect of teammates picking up the workflow rather quickly. I also like semi-manual memory management. I have enough Unity under my belt to appreciate the possibility of avoiding big lag spikes due to garbage collection with intelligent design.

But, I need to mention this since I see a lot of seemingly blind praise for Godot though. Godot is a great open source engine that is capable of a lot of things, but it has one glaring problem.

That is documentation.

Throughout this whole time, I fought with either misinformation or lack of information. Godot has undergone a big makeover with its 3.0 release so some documentation problems are to be expected, but many things hampered my progress.

For example, spritesheet animation. You have a Sprite node and an AnimatedSprite node. You'd think the latter is the correct choice, but it isn't. While the Sprite (HFrames & VFrames) + AnimationPlayer (Animate the Frame parameter manually) workflow is just fine once you know it, it is not at all obvious. There's no examples of this in the documentation anywhere either. This is easily misleading and results into frustration.

Or how about setting a script file to a Node through code? If you were to believe Godot's auto-completion, internal or external documentation, such a thing would be impossible. Yet, it isn't. There exists a script variable that takes in a path, which is what I blindly tested while creating the auto-map loader. How many other hidden variables and functions are there?

These are just a few examples though. I truly hope people help out with the documentation of the engine features since there's simply huge potential, and while the engine itself is a very powerful tool while being beginner-friendly in essence, I cannot with good conscience recommend it to anyone who is not as stubborn as me.

As for me, I intend to play around with it some more. I'm interested to see how well the 3D side actually performs compared to other engines out there. I really hope they fix the Sprite3D Billboard rotation issue soon as I've really taken a liking to 2.5D styles as of late.

In any case, that's my weekend in a nutshell. Hope you people had fun, and see you in the rating sections!

Play now!

Bonk pet!

Eat snek!

Run over 30 km/h without breaking a sweat! (that's over 18.6 miles per hour for you american folks)