My #1 beef with almost any piece of game development software - from Unity to Godot to GameMaker - is always the user interface. Right from the outset, you're presented with an overwhelming number of menus, options, buttons and hotkeys, and a massive blank canvas with a bunch of gridlines on it. If you're new to the IDE, you're instantly lost. The UI is built for the person who has already spent 100+ hours in the IDE, already knows their way around, and just wants to get stuff done as efficiently as possible.

I call this (probably unfairly) Programmer-Centered Design or just "Programmer Thinking". It's how people end up raving about why Vim or Emacs are the One True Text Editor, and why many artists say Blender "Is Just Fine (once you get used to it)". I have to be honest - when I get some dumb game idea, I don't want to play it in a week or a month or a year. I want to play it tonight.

In response, I began building exigy around the idea that Rapid Application Development is the right thing to do when it comes to small, indie-sized games that should take hours (not years) to build. Should prototyping a game take 6 months? No. That's a crazy waste of resources and your human finitude.

If I now know what I don't want to make, what are examples of great game development IDEs? Fortunately, there are a few that I consider to this day, exceptional. Very few people know about them, and almost no one has designed game development IDEs around them.

Eric Chahi's Another World Editor
Another World's editor does everything involved in the production of the game: creating and modifying polygons, animating them frame-by-frame, editing scripts for character behaviour and events, and controlling music and sound playback.


Almost everything happens on the polygon editor screen, shown above. You can see how two characters have been placed on the screen, and then pulled apart into their constituent polygons and polygon groups. Note the toolbar full of buttons at the bottom: everything involved in the creation and modification of a polygon is here, and there are no menus to dig through. Every colour of the 16-colour palette is present. Each button is displayed as an icon. It is very likely modeled on Deluxe Paint - an incredibly popular paint program for game developers and artists at the time.

Now, the icon drawings themselves aren't entirely intuitive. It's likely that Chahi mostly made this for himself, so he didn't put tremendous effort into drawing self-evident iconography - you and I would have to guess at their meanings at first.

Mercifully, Chahi provides a quick reference for the editor. Here we can see just how completely functional the interface is: you can do everything on the main screen.


Clicking on the "Ed" button launches the code editor. This is no windowing system here - it just replaces the main interface with his handcoded text editor. Here, all behaviours and events in game can be modified for the particular scene or character that we're working with. I won't go into Chahi's scripting language - which Fabien Sanglard has already done in an extremely elegant manner. (We will get to this topic another day - but, the idea of having an interactive scripting language is an extremely importance influence on how exigy is built.)

For over ten years I've thought about Chahi's editor, and how it might be modernized, and improved upon for a more general purpose game engine. A few thoughts that have went into exigy's GUI design:
* A windowing system is critical. Having toolbars that can be dragged around and re-arranged to the developer's taste are vital.
* Buttons and icons can communicate a lot more to a user than reams of text labels. Chahi's editor is missing Tooltips, so let's make those a core part of the IDE.
* Hiding everything in menus is a mistake; so is exposing the entire engine's options on a single screen. Chahi's editor is purpose-built as a polygon editor, so he can get away with having it all on one screen. Exigy will require some creativity to both expose enough to the beginner, but hide "advanced" options that aren't immediately important.
* Creating and modifying sprites in the IDE with a mini paint program is an important addition. Aseprite is a wonderful tool, but constantly switching between the IDE and an external tool can be very annoying and tiresome.
* The colour and/or tile palette needs to be immediately accessible at all times.
* Single-clicking on any object in a window should reveal its object "inspector" or mini-window that lets you tweak any relevant settings.
* Double-clicking on any object in a window should reveal the code editor.

It was with those design considerations in mind that I began, in earnest, building exigy's windowing system. April 11's commit reveals my first attempt at having separate windows for separate programs.

It's rough, but squint hard enough and you can see the beginnings of a windowing system. There's a Colour Palette toolbar, a Sprite Editor window, Tile Picker window, and the Terrain Map window. Clicking on a tile in the tile picker selects it, and lets me paint tiles to the terrain. Offscreen, I'm scrolling left-and-right with the arrow keys as I paint. Did you notice how after a certain point, the tiles stop painting, or paint in the wrong areas away from the mouse cursor? That's because I hadn't figured out "map offsets" yet - meaning: scrolling the map needs to be meaningfully linked to the mouse position. Every single interaction on screen must be handled conceptually.

The Sprite Editor is full of random pixel colours, because I hadn't figured out how to transform PNG bitmap data into editable sprites yet. But you're beginning to see things coalesce: windows can be created with a single EXiGY API call... Window:new(x, y, width, height) and the mouse can drag around any window element that has .draggable = true set. The window titlebar is a window element.

That's been a week of progress and learning how Windowing GUIs work. Figuring out the math for translating on-screen coordinates (the mouse cursor) to tile map coordinates turns out to be difficult problem for me, and it's something I'll figure out in the coming weeks.

At this point, exigy's little tile editor and related toolbars are a whopping 150 lines of Lua code in a single main.lua file. I'm amazed at just how functional Löve2D is right out of the box. I didn't write any hardcore drawing functions - I just got it to paint some graphics to the screen at specific x/y coordinates. I notably have not figured out "Classes" yet - an Object-Oriented Programming term - but that will come in time. I do know that Lua does not offer Classes, and they are something that must be created using its Metatables concept. Once I have that figured out, I can begin splitted out functions from main.lua into separate files, and making Windows and Buttons their own separate classes.