Royale Week 3: HaxeFlixel

After last week's fiasco of an engine, I was a little worried going into something I hadn't tried before. Haxeflixel, however, was a breath of fresh air!

As you can see, the resulting demo is pretty close to what I made for DFGame. There are a few notable differences:

1. I had never used HaxeFlixel or Haxe before
2. I spent less time on this entry than the DFGame one
   
3. At 395 lines, the resulting game has less than half the DFGame entry's linecount

This is the sort of result I was expecting to see from some of our contenders, and in general I quite enjoyed my time with HaxeFlixel. The engine offers most of the stuff I wanted out of the box, and the documentation is really well-designed. Just look at the HaxFlixel Snippets site for an example of what I'm talking about:

Each page has a minimal example (often just a single line of code!) showing the relevant call, API links, a real demo running in your web browser, and the full demo code acting as a more 'complete' example. It manages to frontload only the most relevant info while still offering enough depth to understand what you're doing.

Overall, I was impressed and I think HaxeFlixel is actually a quite good starting point for new gamedevs. There are a few negatives that make me unlikely to use it for big projects going forward though.

The first negative is the engine/language's compile times. A 'dirty' build (ie. no code modifications) of my 400-line game for linux takes ~13 seconds. A clean build takes 2 1/2 minutes building to an SSD on a 12-thread Ryzen CPU!!! For comparison, here are the build times for DFGame:

• Dirty: too fast to perceive
  
• Clean: 4 seconds

The Haxe codebase is nearly 40x slower to compile, and I can only imagine what a 5 or 6-digit linecount would do...

The other issue is a little less obvious, but worries me just as much. Part of what makes HaxeFlixel so quick to develop in is that many of the things you want are already handled in the engine. Want an object with a sprite? Make an FlxSprite and add it in! Want to give it physics? Just turn the physics on! Want to make it disappear when it runs out of health? Just call hurt() on it!

This is awesome for quick development, but it also restricts your visibility of what's really happening with your game objects. For instance, when I tried to make bricks move the ball started randomly teleporting, getting shoved out-of-bounds, etc. The changes I'd made on my end were so small, and the API was so 'foolproof', that there was no clear bug in my code. Something was going wrong in the backend, and I didn't have any good debugging options. This always worries me when engines try to hide the details, simplicity can bite back hard when it fails.

With that said, HaxeFlixel seems like it would make for a good prototyping tool. I'll probably keep it around, and I would recommend it for small games and game jams.

Royale Week 2: Godot

Given how many people recommended Godot when I started gathering my list, I was actually pretty excited to try it out. I didn't think it would be as good as claimed, but I figured it would make it into my top 3 and get some use as a prototyping tool, at the very least.

...How wrong I was. As it turns out, Godot is a hot mess.

I'm not bothering with a video this time, there's nothing interesting to see. I got the very basics in place (bouncing a ball around, breaking bricks) and immediately dropped the project, because I didn't want to use this engine any more than I had to. Instead of talking about the game itself, let's talk about why I hate Godot so much now.

First off, let's set the tone with a little anecdote. Here's my first interaction with Godot, step-by-step:

1. Load an example project to see how everything works
2. Open a scene and look around a little
3. Open a script--wait, did that just replace my tab?
4. Try to open the scene again. Nothing happens.
5. Try to close the tab. The tab (and the script within) is still open, but the tab title changes to "[empty]"

If you use Godot, you already know what's happening. But if you don't, I'm sure you're about as mystified as I was when this happened. As it turns out, Godot's designers had a bright idea along the lines of:

"Hey, why don't we force users to open scripts on top of their scenes even though we have tabs?"

For some reason, in addition to 2D and 3D level-editing views they just added a script editing view instead of opening documents in a new tab like any normal piece of software. Just for good measure, double-clicking a script will change the view but double-clicking a scene won't change it back. Like many of Godot's failings, it's so obviously wrong that it almost feels like a deliberate joke.

 

I should also take a moment to point out that I'm a Linux user and casual FOSS advocate. I know that most open-source software isn't the pinnacle of UX, since I use it all the time. Even knowing this, Godot feels like it's on a totally different level somehow. Almost every interaction is slowed or complicated for no reason.

Here's another example: Since we've established that you can technically open multiple files in the same tab, how do you suppose you save them? As it turns out, Godot has 2 save shortcuts, Ctrl+S and Ctrl+Alt+S. Normally, Ctrl+S will save the content of your tab. However, it's bound to save scene so if you don't have a scene open under your script you have to press Ctrl+Alt+S for save script. That's right, they fucked up the most basic action of saving your files.

Of course, that's a bit of a moot point since there is autosave. Unfortunately, autosave always saves open files, even if they're not modified! This means that if you use an external editor, every time you launch the game your editor will detect a file change and prompt you to reload. Nice. The classic loop of "make change, run, go back and adjust" now has an extra step, courtesy of Godot! Oh, but don't worry. In addition to always re-autosaving your files, Godot will also ask for confirmation every time you try to close the editor. Yes, even when nothing is modified. And yes, it also autosaves when you do that, making the entire confirmation pointless.

But you know what? If that was the end of it, I might be able to grit my teeth and push on. So next let's talk about the API documentation. Surely, a team of programmers (because I refuse to believe that there are any "creatives" involved in this engine) would make good docs right?

So the first thing I noticed when I opened the Godot docs was that the API docs were nowhere to be seen. The sidebar is filled with tutorials, but to get to the real API you have to scroll to the very bottom of the list. Or hit Page Down twice. Yes, it's that far down. You could also use the search bar, of course. From my experience, unless you put in the exact name of a type you'll have to scroll deep into the results to reach the relevant API page. Depending on what you search, you might also get the internal engine API, because they put both APIs in the same space for some reason. They also put ads in their documentation, but since Godot itself is free I have trouble blaming them for that.

Ok, so the workflow is bad and the API is annoying to search. But maybe the level editor is good? I'm not going to beat around the bush this time, it's not. The biggest offender is the "Select Mode", which does a lot more than select. Select Mode is ostensibly for selecting objects in your scene, but clicking and dragging moves them. Did your mouse move slightly when you clicked? Your object is now 1px out of alignment, sucker! I hope you noticed before you started doing any real work.

I think that's enough bashing to get my point across, I could keep writing for hours (these past 6 days have given me an endless supply of material), but I think I'll just block this past week out of my memory and move on to the next entry.

Royale Week 1: DFGame

Hello again!

Though it felt like an instant, a week has already passed. I spent my evenings banging rocks together, and a spark emerged. Roll the tapes!

This is not the most riveting game of all time, so I tried to combine all of the game's features (and bugs) into a single segment instead of making you watch a full playthrough. If you're curious, you can check out the code here.

What I got done:

• Basic breakout gameplay, knocking a ball around with a paddle
• Multi-hit blocks, walls
• Moving blocks
• Velocity transfer from moving objects to the ball

I wanted to try a slightly different formula, so instead of bouncing the ball at different angles based on where it hit the paddle I made the paddle give some of its velocity to the ball. I think using paddle movement to 'aim' the ball is a neat idea, but it's a little odd in practice. I'm not sure if I'll keep the idea or try something else next time.

The game itself has a couple of physics bugs as well. Both of them are totally fixable, I know why they're happening. Unfortunately, I simply ran out of time at the end and didn't get a chance to resolve them.

To sum up my thoughts about DFGame after this: It's handy, but needs more time in the oven.

The main drawback of DFGame is that as a C API it's pretty wordy. There are ways to improve this, and most of them involve adding more 'shortcuts' for common stuff to the API. The final game was ~800LoC, which isn't bad, but I think I could cut a quarter of that just with helper functions and refactoring. Since DFGame is my project, that means that any future project using it will have to account for framework development time as well.