Pictured here is a mock-up of a game UI that I have mostly wrangled in Godot. While considering UI, I've also been considering a general game resolution for the for the future games I make. I want to produce prototypes quickly, reduce the art workload by keeping the style simple, and keep the software's overhead low with low resolution art.

For web games, I see the initial load as a pretty glaring weakness of most games. I'm hosting my games in a pretty hacky way, with itch.io, so they don't start quickly. Anything I can do to reduce the time it takes to load the game is something I'd like to pursue.

I need to read more into this, but I'd also like to see what options I might have for programmed music that runs in browser. Mp3 audio takes a ton of space, low bitrate ogg vorbis files sound bad. Midi sequenced bleeps and bloops or similar fit the low fi look.

Early console resolutions, and possibly computer game resolutions idk, ran at 256 x 256 (nes / snes) or 320 x 240 (Genesis) and a number of lower arbitrary resolutions because analogue displays don't care what you feed them apparently. Now a days the lowest resolution display you'll find is 720p, and the highest is 2160p. I picked 240p for this UI because every standard resolutions from 480p to 1080, to 8k is cleanly divisible by that resolution.

I picked a square resolution because I want the games I make for web to feel reasonably good regardless of a user's device. It gives me space add in touch controls for games that need it too. I figure if I want to expand on a prototype for pc or mobile, I have the flexibility to do so with this one framework.

On the more practical side of things, Godot uses a system of bounding boxes that mostly make sense if you read the documentation.

I do have a little bit of a bone to pick with the inspector controls for some of these nodes however. Most of these controls have an effect in editor but not at runtime. I understand that these nodes are built with very specific functionality in mind, but the inspector controls could be more intuitive.

10 years ago, I was studying game development in college. The only free, premium 3D game development package available to students was a limited form of Unreal Engine 3 called Unreal Development Kit. Your target was PC, and you could not legally commercialize software built in it without first upgrading to the $50k Unreal Engine 3 seat.

Since then, Unity3D has standardized mobile and console exporting right out of the box. Epic Games has gone from charging $50k for one Unreal 3 license to zero upfront and 5% of your game's profits after the first million or so dollars.

Game engines have essentially gone from enterprise software to free-mium, hobby software. Which is great. You no longer have to be a hired professional to have access to these tools. You don't need a business plan or a pitch deck for a venture fund. The upstart costs are no longer a cause for concern for friends and family.

The Game Development Software Market now allows for amateurs game developers to exist in the same way that hobby musicians, painters or filmmakers can. Flash and Cocoa2D notwithstanding.

So what's the deal with Godot?

Well it fits my purposes. There you go. That's the end of the post.

Ok, fine, what are my purposes?

1. I want to target web.

2. I also want to target RaspberryPI.

3. I want my software to run on my GPU-less laptop.

4. I want 3D and 2D.

5. I want a WYSIWYG, artist oriented interface.

6. I need strong documentation.

1&2. My first two points are easy to explain concisely. I like web and I like RaspberryPI's. They are fun. At some future point I am hoping to explore WebGPU. That technology will hopefully, at some point, be introduced in the next 5 years. Hopefully, at some point, support for it will be added to game engines like Godot.

Dare to dream.

It does feel like placing a bet on software that already prioritizes web as a target has a greater chance of integrating WebGL, but this is a total guess on my part.

3. I work as a hardware salesperson in my day to day life. I enjoy my work, but I am bound to a sitting desk for 8-9 hours a weekday. When I'm in my home, I don't really want to be at another desk. It's isolating and it aggravates my carpel tunnel. I like being able to hang out with my partner while she watches TV or something.

Godot is really fast, even on my GPU-less thinkpad. The scenes I've created don't hitch or stutter. It boots up in a blink, and it launches my projects just as fast. Testing projects in editor isn't quite as snappy, but it is still very, very fast.

And because Godot's creators are esoteric show-offs, Godot's editor is a Godot game. And that game runs in browser. I imagine other hobby developers might aspire to working off a high end desktop workstation, but I like the flexibility of being able to make progress from anywhere around the house or in a local cafe.

4. Godot has strong, out of the box 2D and 3D support. There are good demos of both available for free on the Godot website. It targets three standards, WebGL, OpenGL ES 2 and OpenGL ES 3. For a quick breakdown, OpenGL is the Khronos Group's, earlier, open source graphics API series before Vulkan.

The OpenGL ES series is their mobile oriented series of APIs. WebGL is, you guessed it, a web oriented version of the OpenGL API, which is mostly based on OpenGL ES 2.

As a developer, reader and human being, you may be asking yourself, what does any of this mean to me? Well, OpenGL ES3 is pretty and a strong candidate for PC, console and more modern android phones. If you do want your game to run on web, old, or cheap minicomputers I recommend using ES2.

5 & 6. I am a salesperson with a background in project management and art production. I've hacked some web software and pc games together, but only by leveraging helpful friends, strong documentation and healthy community support.

Navigation in Godot's interface mostly works like a 3d art package, but even if you've never touched one, the documentation is written with beginners in mind. In particular, Godot's documentation explicitly tells you how it likes its games organized.

As I hope I have revealed, I'm no game development expert. However, in my limited experience, the creators of creative software often have specific solutions in mind for design problems. The value of knowing how the creators want you to solve these problems is that you're not unwittingly creating edge cases, as I have done times innumerable.

So Godot is for me.

But is Godot for you? Well I don't know. There are two successful, well supported game engines with strong asset stores that can jump-start your projects with games systems, art and music. Unreal Engine 4 will allow you to achieve near AAA graphics with no upfront cost. Regardless of game mechanic, Unity's knowledge engineers and community will have a tutorial for you. You can target just about every modern game platform with these engines too.

But in the end it doesn't even matter-ah-er-er-ah-er.

What engine you work with is a matter of product need and personal preference. If you're brand new to the hobby, I'd really just recommend that you stick with whatever engine you start with. Take time with the documentation, check out the forums and stay resilient when people call you an idiot for asking your first technical question. You'll learn more.

William Kesner