Showing posts with label engine. Show all posts
Showing posts with label engine. Show all posts

Monday, April 18, 2022

Why I still use Unity

There's been some game dev twittering about Unity vs. Unreal lately. Why use Unity when Unreal is better?

The basic consensus is that Unity's advantages have been crumbling for years, and its attempt to challenge Unreal on high-end graphics has meant neglect everywhere else. But if you want high-end then UE5 Nanite / Lumen is light years beyond Unity HDRP anyway? And if you're making the typical aspirational photorealistic action game, you'll probably want UE's gameplay architecture and free photoscan assets too.

Most recently, respected developer Ethan Lee has weighed in. For him it's not about the graphics, it's about source engine access and engineering processes. Being able to pinpoint bugs in the core Unreal Engine code, fix them, and submit patches to Epic is how modern software development works. Comparatively, Unity is closed source, and even if you go to the trouble of filing a bug report you'll still have to wait a year for an official bug fix if you're lucky. This is important during the second half of a game dev cycle, when game making becomes a terrible slog -- when your game randomly crashes on Nintendo Switch for some reason and you have to figure out why but you're already so so tired.

So why on earth would anyone still use Unity? Everyone has their own situation, and here's mine:

Sunday, January 16, 2022

Darner's Digest, vol. 3: on the Yarn Spinner v2.0 release + a YS primer

Darner's Digest is a series of blog posts about Yarn Spinner, a free open source Unity dialogue tree plugin.

On December 21st, 2021, the Yarn Spinner project finally made its public YS v2.0 for Unity release

YS 2.0 has gone through six (6!) preview versions / betas over the last few years, with several debates and redesigns that have finally culminated in this version. If you're familiar with Yarn Spinner already, you should go read the changelog for upgrade notes from v1.0 to v2.0.

But a lot about YS and its ecosystem have changed, so it's probably helpful to recap what's going on.

1. What is Yarn Spinner in 2022?
2. When to use Yarn Spinner
3. How to use Yarn Spinner
4. Current Strengths / Weaknesses
5. The Future

Friday, April 9, 2021

Getting started with HaxeFlixel in 2021

Warning: this is a fairly technical game developer-y post. If you came here for gay sex, I'm sorry.

For an upcoming project commission, I'm making a 2D game with crowd simulation and simple controls that works well on mobile browsers. (Reminder: for iOS, that means WebGL 1.0 and no WASM.) The engine should be able to render and simulate 200+ lightweight game objects -- frame-animated sprites with simple collision, no fancy physics or shaders.

Which game engine should I use to maximize ease of learning and compatibility, and manage hundreds of simple objects on-screen? Here was my thought process:

  • Unity WebGL: way too heavy and slow for mobile browsers, and maybe overkill for a no-physics 2D game anyway. (Although the Lil Nas X 3D twerking game runs surprisingly well on iOS's WebGL 1.0, I wonder how much they had to optimize?)
  • Unity Project Tiny: as far as I can tell, Project Tiny and its DOTS dependency is still in early development. The random caveats and various in-dev inconsistencies with regular Unity would also be frustrating. And as with many other Unity side projects, its long term future feels really hazy.
  • Construct: seems ok, and I think I could've gotten used to the visual block scripting, but overall the pricing and licensing feels weirdly restrictive. I have to pay to use more than 2 JS files? I have to pay to use more than 1 font, or make an animation more than 5 seconds long? These are some really bizarre artificial resource limits.
  • Phaser: seems popular enough with decent TypeScript support, but I want the option of building out to a native executable without a weird Electron wrapper or something. Their monetization model (free open source base but you pay for "premium plugins" and tools) is one of the more generous ways to go about this, I get it, but it still feels weird to me and reminds me of Construct.
  • Godot: I've wanted to try Godot for ages, but in the end I felt like I didn't have a good sense of what its HTML5 Web export could do + learning enough of the "Godot way" and GDScript would've taken a while. It's also in the middle of a big break between v3.0 and v4.0, and ideally I'd like to wait until like v4.2 to commit to learning it.
  • Heaps: promising and some people get great results with it, but maybe still too early in public lifecycle for a total newbie like me, with not enough samples / docs / robust official tutorials to learn from yet. If or when I do try out Heaps, I'll probably try using Deepnight's gameBase project template.

In the end, I chose to build this particular project with HaxeFlixel. This post details my early impressions, thoughts, confusion, advice, etc. with learning it.