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:
- I had never used HaxeFlixel or Haxe before
- I spent less time on this entry than the DFGame one
- 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.
No comments:
Post a Comment