Date: Wednesday December 04th, 2024
Time: 01:46:07 PM MST
From: @vga256
Keywords: programming, history
Subject: Where Exigy began
Time: 01:46:07 PM MST
From: @vga256
Keywords: programming, history
Subject: Where Exigy began
Way back in the mid-90s when I was a teenager, I worked a couple of summers at a new regional ISP that served the sub-arctic and arctic regions of northern Canada. The ISP, Snowshoe Inn Micro, was located in the village of Fort Providence - a place of around 500 people. Aside from going fishing along the Mackenzie River shoreline, or wandering around its dusty dirt roads while the midnight sun rounded the horizon, there wasn't much to do in the evenings after work.
Instead, I spent almost all of my hours back in the office playing Quake deathmatch and chatting with friends on IRC. Seeing me while away my time with games, my boss made an offer: he'd teach me how object-oriented programming using Microsoft Visual Basic 3.0, or just 'VeeBee'.
He taught me the IDE using a Pair Programming style - I sat left-seat, typing in variable names while he sat in the co-pilot's seat, quietly offering suggestions and asking questions. For one month, every single night, he guided me through building a VB application - an image viewer/photo gallery - and taught me OOP concepts like classes and encapsulation. After I got the hang of it, I began programming my own applications and games after work, and into the new school year. I can safely say that without his mentorship, I would have never become a programmer and game developer later in life.
Visual Basic led me to Borland Delphi (Object Pascal); Delphi led me to Macromedia Director (Lingo); and Director led me to Macromedia Flash (ActionScript). With all of these IDEs and languages, working via drag-and-drop components and objects was the central metaphor. The "command line" attitude that was typical of MS-DOS and UNIX programmers was hung up at the door, and thinking user-experience first was the core value.
Fast-forward 25 years ...January 2024... and I once again found myself hungry for an all-in-one IDE and game development toolkit. I spent two years with Unity, and found cold comfort with its 3D-only and poor UX philosophy. Godot, though more thoughtful towards beginners, suffered greatly from its 3D metaphor. A very unique IDE called Polycode was incredibly promising, but was abandoned by its master after a few years of development. IDEs like Tumult Hype were so deeply reliant upon Javascript that they proved useless for game development. Adventure Game Studio - though very amenable to visual development - was so deeply tied to making Sierra and LucasArts adventure games that it was almost useless for something as simple as Tetris.
In short, there were no visual development environments out there to make the kinds of simple, 2D games that I grew up playing in the 90s. Games modelled on Maxis's Sim Farm, Sim Earth and Sim Life, were incredibly frustrating to build with modern tools. Something that might have taken a week to build in Visual Basic would now take two months in Unity. That kind of development cycle is death for small development studios.
It was now April 2024; three months into the launch of Studio Tomodashi, and I had no way forward for making the kinds of simple shareware games I wanted to make. I needed an IDE and toolkit that didn't exist anymore.
So I decided to start making it, with only a vague idea of what I wanted, and no idea how to build any of it.
First commit: Point and click for tile type change is working. by vga256 Apr 3, 2024 at 3:27 PM
And here it is: the first build of what would eventually become EXiGY. Green grass, white snow, and brown dirt tiles rendering randomly.
Instead, I spent almost all of my hours back in the office playing Quake deathmatch and chatting with friends on IRC. Seeing me while away my time with games, my boss made an offer: he'd teach me how object-oriented programming using Microsoft Visual Basic 3.0, or just 'VeeBee'.
He taught me the IDE using a Pair Programming style - I sat left-seat, typing in variable names while he sat in the co-pilot's seat, quietly offering suggestions and asking questions. For one month, every single night, he guided me through building a VB application - an image viewer/photo gallery - and taught me OOP concepts like classes and encapsulation. After I got the hang of it, I began programming my own applications and games after work, and into the new school year. I can safely say that without his mentorship, I would have never become a programmer and game developer later in life.
Visual Basic led me to Borland Delphi (Object Pascal); Delphi led me to Macromedia Director (Lingo); and Director led me to Macromedia Flash (ActionScript). With all of these IDEs and languages, working via drag-and-drop components and objects was the central metaphor. The "command line" attitude that was typical of MS-DOS and UNIX programmers was hung up at the door, and thinking user-experience first was the core value.
Fast-forward 25 years ...January 2024... and I once again found myself hungry for an all-in-one IDE and game development toolkit. I spent two years with Unity, and found cold comfort with its 3D-only and poor UX philosophy. Godot, though more thoughtful towards beginners, suffered greatly from its 3D metaphor. A very unique IDE called Polycode was incredibly promising, but was abandoned by its master after a few years of development. IDEs like Tumult Hype were so deeply reliant upon Javascript that they proved useless for game development. Adventure Game Studio - though very amenable to visual development - was so deeply tied to making Sierra and LucasArts adventure games that it was almost useless for something as simple as Tetris.
In short, there were no visual development environments out there to make the kinds of simple, 2D games that I grew up playing in the 90s. Games modelled on Maxis's Sim Farm, Sim Earth and Sim Life, were incredibly frustrating to build with modern tools. Something that might have taken a week to build in Visual Basic would now take two months in Unity. That kind of development cycle is death for small development studios.
It was now April 2024; three months into the launch of Studio Tomodashi, and I had no way forward for making the kinds of simple shareware games I wanted to make. I needed an IDE and toolkit that didn't exist anymore.
So I decided to start making it, with only a vague idea of what I wanted, and no idea how to build any of it.
First commit: Point and click for tile type change is working. by vga256 Apr 3, 2024 at 3:27 PM
And here it is: the first build of what would eventually become EXiGY. Green grass, white snow, and brown dirt tiles rendering randomly.
Date: Saturday December 07th, 2024
Time: 08:17:27 AM MST
From: @vga256
Keywords: programming, history
Subject: Week 1 - it's okay to be ugly when you're young
Time: 08:17:27 AM MST
From: @vga256
Keywords: programming, history
Subject: Week 1 - it's okay to be ugly when you're young
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.
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.
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.