Indie Game Development Tools
Spoiled for choices.
the kind of game every developer wishes they could or did make.
Who chooses game development anyway?
If you’ve been around a little while like I have, then you know there are three reasons people get into game development:
because they have what they think is an awesome idea.
they’ve played too many games and had too many moments where they thought I wish x was different. Could I do better?
They saw someone talk about “how much money games can make!” or saw a news report about a game that sold ridiculous numbers of copies.
The truth is, for the most part, most people in group one will quickly burn out. And group three is simply delusional. Yes theres money to be made, but no its not simple, or easy, or quick (unless you’re the developer of flappy bird, or adventure capitalist, but I digress).
Today we are not here to talk about money.
Instead, for those who stuck with it, we’re here to talk about the tools we have and the tools we wish were better. We’re here to talk about in what ways our tools could be better.
In short, we’re here to say I wish x was different. I could do better.
Indie Tools Today
On the market there are tools from Unity, to GM which primarily does 2d (though advocates claim it does 3d, the tooling definitely doesn’t help).
If you’re a veteran or even an amateur like me, there are a wide variety of tools available to suit your needs, but that wasn’t always the case. While for many years games, especially independent development, were not taken seriously as an industry or art form, today it is an industry that surpasses all tv and movie sales, and permeates much of modern life. Despite this, the tools available to your modern dev are crude in comparison to the tools available to movie and tv editors, to digital artists, and even musicians. (I can hear the “citation needed” comments already).
A simple search for ‘game development tools’ brings up a plethora of options. A little research will quickly narrow down the scope of what will do the job. It is a common refrain for amateurs to blame their tools, something even professions sometimes do. Regardless, it is true that the feature set of your tools can make your job heaven, or turn anything you want to do into a grind from hell.
A cursory glance at this list boils down to a handful of options. And while I’m not here to write about 3d engines, I’ll include the standard line up.
For 3d games, there is Unity, which for years had interface issues, memory leaks, and suffered from neglect in key areas like unreliable netcode, and text rendering so bad they just bought and integrated a third party solution. Then theres Unreal with many successes behind it. And while I’ve only used Unity on occasion, I can safely say, a glance at Unreals workflow definitely makes the grass look greener on the other side.
For 2D games, there are a host of options. There is GM, the market leader, with many successful free, and commercial projects that have gone on to be widely loved and distributed. Despite the memory leaks, frozen interfaces, antipiracy measures, one of which lives in infamy for deleting a legitimate developers entire project..despite all of this, for years GM has been all but the gold standard for amateurs not looking to make the next MMOFPSRPGOMGBBQ.
And GMs success is largely due in part to its focus on rapid iteration, making changes, builds, and testing, if not seamless, close to it. It of course could be argued that Game Maker, and Game Maker Studio (despite the amateur name), was simply the first on the scene or market, that lowered the bar sufficiently to introduce development to the non-professional market. Actually thats not entirely true, there *was* flash, and the easy hosting options available to it lead to sites like New Grounds becoming wildly popular, but thats a story for another time.
GM made desktop development for amateurs, what it is today.
Sure there were others that made it possible, SDL, LWJGL, but these were libraries, not fully integrated development environments. For an amateur it was well enough to blit something to screen, and set collisions, while getting input. If you wanted anything crossplatform, if you wanted more, you would have to also do *all* your own data loading/saving, handle navigating the file system, setting up and importing/exporting data from a tile editor (or making your own), all of which takes time and focus away from the core cycle of ideate, prototype, and testing.
The sheer number of titles made under GM (to say nothing of the amount made under the likes of flash), speaks volumes about the rapid-prototyping approach to development for software in general. We’re talking a library of games.
Hyper Light Drifter? Made in GM
Katana Zero? Made in GM
Forager? Made in GM
And the list goes on.
Crash Lands, Minit, Undertale, Stone Shard, Nuclear Throne, Cook Serve Delicious, Downwell (which I admittedly spent way too much time on), Turmoil, Nidhogg,
Is that it? Is that enough? No? Let me continue.
Gods will be watching, Cattails, Spelunky, Risk of Rain, Gunpoint, Skein, Hotline Miami, Blazing Chrome, Deltarune, Tower of Heaven, Shovel Knight, Deaths Gambit.
Ffeeew. Thats one hell of a list, and its by no means complete. You may not be familiar with all the games I’ve listed, but I’m sure you have, maybe, possibly, probably, heard of at least some of the titles among the plethora of games under the GM banner. You would have to be deaf, dead, or in a coma, not to have. Undoubtedly too, the list of games I’ve played or followed fails to mention some of your own favorites that were made with GM.
I’m sure I sound like a fanboy, but this is not to decry other engines. For sure no one can discount the success of Unity, with games like
Rust, 7 Days To Die, Celeste, Hollow Knight, A Valley Without Wind, Dead Trigger, Organ Trail, Plague Inc, Cities In Motion, Gone Home, Kentucky Route Zero, Shelter, Surgeon Simulator, Among The Sleep, The Long Dark, Crawl, The Forest.
And dozens and dozens of others, both indie, and professional, both megafunded, and shoestring, both 3d, and 2d alike.
But when we talk about Unity the issue becomes:
How much C# do you know? How much money do you have to automate the pain points of the UI with third party additions? How much of an amateur are you?
The truth is the bar is higher here, so we’ve seen more professionals use it. And because of this higher bar, the number of titles, with all the professional polish that comes with them, is also larger.
And while the requirements to run it are pretty low, not everyone is running new or even recent hardware. So here we are today, to talk about ‘shoe-string’ development and the tools that enable it.
Enter GM and contenders
Not the best banner, but it will do. They have in recent years focused on polish, helping developers gain distribution, and platform support.
But there are others too.
Theres Godot, although I’m not familiar with it.
Love2D which strictly speaking is a library, but we’ll get into that in a bit.
Theres of course Unity2D
Monogame, with its own plethora of successes.
And the little known OpenFL, the foundation of Defenders Quest, Papers Please, and a handful of others.
Stencyl, which is a highly visual, component oriented engine, marketed strongly toward the classroom and learning environment. A couple of titles have been released for it, save for the sadly yet-to-be-released almost-spiritual-successor metroidvania Ghost Song.
In truth, especially with libraries, its less about the titles that succeeded with it, and more about what those libraries offer out of the box. The big ones are platform support, and making things that *should be easy*, easy, while not imposing too large of an overhead when you try to do something not explicitly covered. Another big one was ‘seamless’ development, which we’ll talk about in a bit.
In my development, I found these affordances to the developer is what made the difference, and today I’d like to talk about four tools: Unity2D, GM, Love2D, and surprisingly, Stencyl. Other libraries and engines may have done it better, faster, cheaper, but today we’re gonna discuss those four.
Unity2D
If all you have is a hammer, everything looks like a nail
My first introduction to unity was a boring summer a few years back while I had the flu. I had been writing pathing code in GM, and just needed a break from that and a dozen other tasks.
I took a few weeks and installed Unity to try my hand at some smaller project. Just sprites, and tiles initially, grabbed from a random folder. The object wasn’t so much as to make as it was to explore and amalgamate.
What I loved out of the box was the staging area. How assets imported were kept in a dedicated space, separate from the files they were imported from. Changes to these assets didn’t cause changes in the original files, which is as it should be. It was a very “functional” asset pipeline so to speak.
I didn’t know much of anything about C# at the time, maybe enough to put together a class file and bind a few listener events. I made things jump. Move. I made objects that ‘killed’ other objects on contact. Lava. Traps. Bullets. But some things never became easy.
At the time I didn’t know anything about quaternions, and matrix math, so that made doing physics and rotations difficult. I stuck to manually altering the location of objects in the world, and collision groups. Actually I’ll be damned if I remember how I did it. Point was, at the time, that was my limit. Here was the ceiling of my ability.
I loved the component oriented design, it made some things easier code-wise, but it definitely wasn’t easy managing complexity by itself. I wanted to prototype and iterate fast and switching between code and figuring out how to instrument my objects so I could use the property inspector properly wasn’t my definition of fast. Maybe I was spoiled. Maybe it was first world problems. Out there somewhere was a veteran developer, who would have said something to the effect of back in my day we had to burn our game to a cd before we could test it!
But Iwas not, and am not, that veteran developer. And all I knew at the time was there has to be a better way. A better way was my bread, my butter, my manna in the desert, the illusion of an oasis on the distant horizon of my vague notions about game development. A ‘better way’ was my whole world.
They say in development if you want to make a game, focus on making the game. If you want to make tools, focus on making tools. Tools development doesn’t usually save you time on the current title so much, as on the next title.
I was neurotic. I was dissatisfied. So I hopped on a plane to the swiss alps for a vacation, to clear my head. Well no, I didn’t actually do that. I’m pretty sure that was a fever dream at one time.
Instead I did what every amateur does, and hoped for something better to come along.
It was not that Unity wasn’t great in its own right, it’s that like all hard to satisfy people, least of all amateurs, every minor issue was really a burr whos very existence seemed to snub both my own, and my ability thereof.
I just want to make games. Is that so hard?
So I went back to GM, for a while, still beavering away. The game changed. It morphed from a theme of zombies and basebuilding in a cozy apocalypse, to a broader theme of the post-apocalypse. I wanted to snub Fallout, for the travesties that both Fallout 4 and Fallout 76 were, even with my fanboy love/hate of Bethesda.
What was it about GM that constantly dragged on me though?
The auto-suggestions for objects, and instances were great. If you wanted a global object on a map, you didn’t need to go to some list or editor and mark an object as ‘global’. You just placed it on a map, and then referred to it in script by its object name which returned the first (and only) instance matching that object the engine could find on a given level. Boom, global controllers.
In the event code GM gave you programmatic access to the current and other object in an event, such as a collision, with built-in variables like “other”. Easy.
Finding the nearest instance to an object was simple, because the function was already provided to do the search among all potential instances. For someone who just wanted to do a simple check, without spending five to ten minutes, breaking the iteration loop, functions like this and many more, were a boon. Don’t think about the code supporting the code. Only think about the code thats directly responsible for this iteration. Only think bout the code responsible for this prototype and its immediate mechanics and behavior.
There is a gargantuan gap in the efficiency between the definitions of very easy and seamless. Unity2D was very easy. Other engines and libraries had been easy or even very easy. GM was and is near seamless in its iteration loop, at least for beginners.
And I was very much a beginner at that time.
And yet, I was dissatisfied. Maybe something was wrong with me. I took almost a year, as circumstances changed in my life. I put the game aside. What was I even doing? Was this what it was like? Always reaching, never achieving. Always searching, never arriving.
I discovered another engine. It definitely wasn’t GM.
Enter Stencyl
It was spring, but still snowy where I lived, in 2019. My sisters were bored, and were both turning fourteen. Both of them were artists and needed an outlet, having progressed significantly in their abilities and skills.
They also wanted to learn to code. I didn’t want them to have to deal with setting up environments, or learning syntax while also learning the core concepts of programming as well. Conceptual learning was enough as it was without piling on a whole new language.
I searched out something that would work for them, and found Stencyl. The programming language was loosely based on Scratch, but had added a lot of tools and niceties. Custom event names (via text box elements), blocks that supported variables, such as references to the other instance in a collision (much the same way GM did). It made the easy things easier, the “80%” of what developers might want to do, while making the hard things easier as well (the other 20% not typically covered).
The learning was usually about an hour a day after school, but after two weeks, they lost interest. Oh well. Not everyone was made to program. Or maybe I’m terrible at teaching, who knows.
And while I had been teaching them, I also was learning.
One night at the dinner table, we started ideating, joking about robots, and talking about survival games. “What if there was this whole little world of robots, all running around, trying to survive, and you got to watch them from afar, had to teach them how to do things, like avoid rain, or gather ‘food’ by explicitly showing them? And you managed them and helped them to survive?”
And we went from there. It snowballed.
By the end of the night, we had dozens of sketches, post it notes, and had a single grass block, courtesy of my sister, and a single, unanimated robot, who was decidedly unrefined. He jumped. He walked. And that was enough.
The next day we worked on the same thing. And the next day. The old project I had been working on in GM, was waylaid, forgotten, as the days turned into a week, then weeks.
And thus was born..
Invasion of The Domobots.
Having an artist present, one that was moderately competent, was fantastic. This was entirely new to me. We would start each day after school, discussing ideas. And then she would sketch it. And then I would say “no, no, no, more like this”, and she’d erase the work, and restart, and this is how it would go, iterating. And then “ok, heres the coloring, heres the references, it should be like this once its turned into a sprite”, and back and forth in email, and then the sprite would be in my inbox, ready to go. To see it go from idea, to sketch, to ‘finished’ and in game, moving, animated, was exhilarating. Sure it wasn’t polished. Wasn’t truly finished, but for a placeholder it looked better than anything I had ever made. I could say I was competent at pixel art at one time in my life (and I was pretty damn good too), but never like she was across the gamut of potential styles.
Before long there was talks of “well why not make it commercial”.
Well for starters it was in *stencyl*. No one would take us seriously would be my guess. Second, I barely knew anything about marketing, only what I read from days and days and days worth of other independent developers, their war-stories, the synopsis of numerous experiences all coalesced into a general and vague understanding of the principles but not the true execution of marketing.
I still didn’t have the experience, either for myself, or team-wise, to do the marketing. Call me hesitate or afraid. I couldn’t afford to mess up, is the way I saw it.
In short, if I didn’t have the expertise, it would take money.
I appealed to some groups that provided funding to independents, but virtually none responded. The ones that did lauded the screenshots but claimed wtf, why flash? Flash is dead, many of whom got their own start in flash, and should have clearly understood it was only a prototype and their funding sites explicitly said any platform is ok, as long as the demo or prototype is good. Others, who had been long time developers, including flash developers, claimed they just couldn’t get it to run or work. Didn’t know how. Even with explicit instructions.
It was excuses, to let us down gently. And the more I looked the more it seemed the people who got funded were already experienced, already veterans, already had titles under their belts. Had been long time friends with the devs that ran the independent funding groups, had gone to their cons, had gone to their meet ups, had met them one time, worked with them, had followed them on twitters for years or donated to the very games the members of the funds had made.
It was all so incestuous, a never ending series of friends-funding-friends back and forth, forever, while claiming to be for the little guy.
I don’t know, maybe our game sucked. Maybe our prototype wasn’t as good as what we thought. The entire thing had been built to communicate the feel of the game, the atmosphere and general thrust of the design. Maybe we asked for too much. In retrospect we definitely did. But even lesser amounts had been roundly rejected.
We were just too new, they didn’t know us, we weren’t in their trusted friends circle of veterans who had already made it.
At the end of the day this is all sour grapes and a disappointing aside to what this article is about.
Point is, platform matters. Platform, engine, absolutely can and does reflect on your competency.
Of course had I chosen to go with Unity2d, maybe it wouldn’t have reflected badly. But then I would still be parameterizing components and writing support code to test ideas, instead of prototyping. The principle was always, build in whatever, get it working, show we *can* do it, get funded, and then start building in a toolset that could take us the rest of the way.
Sadly, the story of the domobots, the shadowy arigatocorp, and their escape from being stranded on a distant world, would be relegated to where all ideas that tried and failed return to: a folder buried on a usb drive, along with lots and lots of unused assets.
RIP Pal 9000, may you, and your many sci-fi puns, continue in your curious and wacky adventures in game development heaven.
Stencyl
While the saga of our summer at last came to a close, I hadn’t left entirely empty handed. What I had learned from Stencyl was how much greener the grass could be on the otherside.
In the span of a couple of months, we had gone from a single green square and a very rough robot sprite, to so much more.
or just put on a sweater.
Stencyl was, for me, a whole new definition of seamless.
Where before I had been used to one dimensional hierarchical lists of files (in the case of using libraries and raw code such as sdl and C#), with at best standard asset or folder icons— instead was presented a two dimensional ordered list of actors and components. And every component could have a sprite assigned to it to make it easy to identity. Big bold 2d dimensional icons, easily rearrangeable, unlike the same in windows file explore. It felt more like experienting and building a recipe then hunting for a given object or instance or function in a file or a massive drop-down list. It was significantly faster. By an order of magnitude, especially when you were in the thick-of-it, iterating, prototyping, and testing.
And speaking of objects, there was consideration to patterns, and architecture. The choice was singular and simple, like ford saying “you can have your horseless wagon in any color, as long as that color is black”. There were actors (objects) which instances were created from. Actors, and *all* their variables, and most of their events, were derived from components. Components were browsable just like actors. Components had fields, and default values. You attached it to an actor, and when you placed an instance of that actor on a map, you had an actor inspector (editor) that let you customize each of the fields for each of the components attached to that actor.
look at it in all its goofy, amateurish, easily-browsable, very rapidly identifiable, glory. Look at it. LOOK AT IT.
No fuss, no muss. Rapid iteration, and testing. Change, and run. It was great. Even for an educational tool. And heres the thing, it wasn’t like GM didn’t do something similar already, it was the little 10% that distinguished the improvement.
Assigning icons or sprites to actors and components. Stencyl allows it, GM doesn’t.
browse in 2d and *freely* rearrange these actors and component in a grid. Stencyl does, GM just uses a top down list.
fields could refer to *many* things not just primitive types. Fields could refer to actor types, other actor instances on-map or in-level, built in types like sprites, events, etc. It didn’t make the baseline easier by making what was complicated harder.
And because component models are well, component based, it was trivial to test a new behavior or mechanic, by adding or removing components.
Even better than that, why add or remove components when you can just mark them enabled or disabled on a per actor, per component basis? Entire behaviors could be toggled from an actor object for testing purposes, seamless, and trivially fast to do.
that event list on on the side? Just right click and hit the toggle button to enable/disable a whole event. No more block-comment style heresy or configuration files.
This likewise applied to data fields on a component, which you could add supporting text to, so you weren’t just filling out the equivalent of CSV fields, with no description or explaination.
What sped up development beside this was affordances that to this day don’t exist in many engines:
Seamlessly rearranging tiles in a tileset.
Tiles didn’t act as one large sprite that you imported and sliced up, like a lot of engines force you to do. Instead they acted as a rearrangable, easily editable grid, with meta data for all sorts of purposes.
This helped me numerous times, not because it’s a big improvement, but because I could regroup tiles, on the fly, tiles I had imported as assets, allowing me to keep the ones I frequently used, physically close together when map building. You could even move *entire* groups around as needed, and I often did.
Tiles had per-tile tag-data, acting more like light-weight instances, and this helped *numerous* ways, and I employed it as frequently, and creatively as I could.
Tile collision shapes (along with sprite collision shapes) could be assigned groups, and even custom shapes, which there was a dedicated tile editor for.
Tiles could have *animation frames*, and we’ll talk about that more in a moment.
Whether you’re making a platformer or even a top down game and just want to break up the movement grid, this is hugely helpful to both simple beginners, and regular amateurs. Typically you would need an external editor for this. Typically you would have to write code to import those collision shapes. That takes time. Typically you have to unpack it, and parse it, and look up the tile from a tileset, and assign it, in code, or worse, do all or most of these steps in an editor, completely defeating the purpose of an editor.
And most won’t make it easy to dynamically add, define, or remove *new* collision shapes, let alone assign them on a per frame basis.
Thats not a trivial improvement. Thats a major improvement even if the software is for ‘educational’ purposes and looks rank and amateurish.
Beside the tile set improvements, you could tag tile instances *on map* which helped tremendously when you didn’t want a particular tag for every instance of that tile. It made finding things in-game trivial, and decoupled tile data from tile type. Multiple tiles could have the same tag, so you could mark all of one set ‘traps’, all of another set ‘slippery’ (ice, wet floors, etc).
Stencyl makes a lot easy, as was its purpose, which many engines make unnecessarily painful, including getting a proper UI up and running. Other engines, GM included, had clipping issues, layering issues, issues with surfaces interfering with UI, UI not staying put on screen. Stencyl handled this by having a simple set of ‘scroll x’ and ‘scroll y’ fields which you could set to zero on a layer, in order to create a static layer for your UI. No scaling issues, no scrolling issues.
And of course there was the animation editor
Beats many engines because it takes what a animation timeline tries to do and boils it down. You set animation time explicitly, per frame, in editor, instead of being forced to import a sprite, and then set timings in code, cleanly separating asset, code, and data.
And of course, you can set collision shape, collision group, events, and physics, per animation, and per frame.
Changing the default animation for this actor object is as trivial as selecting one of the animations in the left hand panel, the animation browser, and hitting the star button, or right clicking and selecting the appropriate option.
All without resorting to a ‘timeline editor’ or what looks like a line readout from an EKG.
Hows that song go? Simple and clean is the way that you’re making me feel tonight.
Back To Square One
There was more to Stencyl of course but it all eludes me now. After I stopped using Stencyl, it left me once again dissatisfied, not because it was bad, but because it was actually good, better than I even expected.
Once Domobots had ended, I took some time away to attend to my actual life. Eventually I found my way back to GM.
It had a lot going for it. The builds were slow (they’ve since fixed it), and its newer features had bugs, but what engine or software didn’t?
I forget the name now, but someone introduced me to Love2d and not long after I discovered moonscript. You may be familiar with Love2d, less so moonscript, which brings pythonic syntax to lua. It was shortly after ludumdare this happened, and once again I wanted to break away from what felt like development hell with my current game.
Enter Love
One title made in love2d. Rogue-like colony builder. looks fun. You can check it out here
As more of a library than an engine, I wasn’t sure.
I liked rapid visual prototyping.
I liked coding.
I did not like coding while trying to rapidly prototype.
I don’t believe GM offered the sequence editor at the time. Nevertheless I decided to go ahead and see what it would be like to rebuild the intro screen to my game, tenatively called P.O.S.T. I had intro music, a studio name (yeah right I’m a one man band. Who was I to play at the pretension of being a full, named, professional studio anyway?), a swanky character that would SWING onto screen with an audible BOING noise, a title that buzzed and flashed like a dying neon sign outside a casino in new vegas, and a tagline that changed after each restart, plastered right next to the title. Completely vapid, completely useless.
What better an intro?
So I did. I remade it. What had been a long obnoxious slog in GM, with finnicky timing and disconnected bit and bobs, cobbled together between the map editor, the script editor, timers in the event editor, and my own custom tweening library—what had taken too much time to put together in GM, took about an hour or two in Love.
“My God, why? Why did I not discover this sooner?”
In truth it was probably more like a day, if you factor in setup, getting moonscript to convert to lua, and a bunch of other small issues as I learned my way around it. But in short, it was a breeze.
I could even easily import libraries, and do effects like scanlines, and proper CRT style corners on the main menu, if I wanted to. I could even play videos of nuclear bombs dropping in the background. And while I ultimately decided against all of that, because it was gaudy and excessive (but who knows, I never ran it by anyone else), in practice options like these, and more, remained available to me.
nothing too fancy. I was rather partial to the video of the bombs dropping in the background. But only because I saw a fallout-meets-citybuilder game called Atomic Society that did the same thing on its own menu screen.
Imagine my delight at how quickly it took to get up and running. Here was potential. Here was real promise. Love took away the pain of most libraries, and combine with moonscript, gave me pythonic like syntax, and removed most of luas worst worts (and dont get me wrong, lua is a lovely language in its own right).
The learning curve, to just *get something on screen* was shallow. There wasn’t a whole lot of work to get anything more complicated going. It didn’t impose its own way of thinking on you, and it mostly got out of the way. What was easy stayed easy, and it made the hard things easier.
And while I gave up most of the advantages of an IDE, I got the advantage of a proper language, unlike GM, or something too broad like C# and Unity. Love hit the sweetspot between ease of use, ease of getting started, learning curve, and power, at least for this amateur and what I wanted to do.
It abstracted the filesystem and gave me access to a sufficient number of tools and libraries, mostly up to date, to mostly do anything I wanted to do, even if I’d have to do it manually.
Just one thing, it wasn’t an IDE.
I’d still have to either find a tile editor, and go through the import/export cycle, and write a tile parser, or build my own tile editor.
Actually this was both a blessing and a curse, because I wouldn’t be relying on any subscription like GM (which could go haywire at any time, or expire, or turn to a subscription model, or up the system requirements in an update, or suffer from memory leaks), and if I needed a new feature, I could probably build it myself.
Building it, especially in Love2d itself, would also mean I could include it for players to use. Modding, depending on scripting and data access, would not just be easy now, but editing would be trivial for players too. And once I built one editor, in theory, it would be, if not easy, at least straightforward to make others.
The curse was I would have to build it myself. I would have to build *all* the editors myself..
And so we return to the old saw, you can make games or you can make tools. Choose.
What I thought I would do is pretend to be one of them deaf mutes
Designing the engine and editor
Often what we want to do and what is possible given our time, and resources, are two different things.
I had tried this route before, but life got in the way at the time. Damn you life! Why must you interfere with my plans!
This was a revisiting of a path I had at least explored at one time, and now here I was again.
What to do, what to do. The first questions to ask were, how much structure? what kind of structure?
I decided on a functional-design, where everything you import is copied, much like GM, much like Unity, much like Stencyl, and becomes an asset in the project.
Before, I had considered bundling. If a sprite was in the asset folder, along with a sprite_name.json then at run time, the project editor would find it, enumerate all like it, and add it to the list of game assets as a single object. The problem with this thinking is, that while straightforward, it relies on the file system alone, for versioning, and asset management. If you make changes in-editor to an asset, where are those changes going?
So while I could still use the bundling concept, I also knew that any assets I worked with, would be imported and copied from the outside of the project folder. Imports go in, and nothing altered goes out, unless its exported. Exports or files saved never alter the originals.
What would it take to implement a full IDE in Love?
Or in any library really? Just one example.
Lets talk undo, redo, and versioning.
Instead of reinventing the wheel, suppose we used git.
Now in principle I could use something like git and a watcher to actually do this automatically. And I wrote a bunch about how to handle undos/redos, dangling references (like objects that had been deleted, but had instances placed on maps), and so on. The reality is git is way overpowered for what amounted to an editor that might support a one or two person team.
After all, we’re independent developers, not activision! What the hell is an “indie” anyway? I’d even grown a sort of disgust at the term, as if saying it, without having published anything, was being fake. The word felt vapid. Like calling yourself an e-celebrity, or apple putting an i in front of everything.
(Don’t you know its year 20xx, we attach coin to brands now! Dogecoin, ecoin, walmartcoin, hospitalCoin for when you really want an appendectomy).
We live in the age, not of the indie, but the wannabeindie. The age not of the indie, but of the one man band. Playing music to the beat of our own drum, and hoping, someone, someday hears it, or by sheer luck & pluck a crowd forms around us to tell us yes this is good. This was fun! It was not in fact all a horrible waste of time, effort, and lifespan you’ll never get back. I enjoyed it. and maybe even heres a few dollars too.
The reality was I didn’t understand the problem well enough. Not the problem of making an IDE. Not the problem of what features were actually needed, and not who the developer is, who the user is.
Maybe I hadn’t wrote enough user stories. Maybe I had just gone insane, and this had all turned into an exercise in buddha-levels of procrastination so I didn’t have to admit the project was once again falling into development hell while my rapidly dwindling savings screamed from my unsmashed piggy bank SMASH ME! SMASH! ME! SMASH THE CERAMIC PIG TO TINY GLITTERING SHARDS LIKE AN OFFERING TO AN AZTEC GOD AND THEN GET A JOB YOU FUCKING HIPPY!
I knew what I wanted though, and I’d spent enough years kitchen-sinking to understand what I didn’t.
Typically in GM, or any engine, when a dev wants to test an idea, the process, unlike a big development team, looked something like this:
1. copying a file (to isolate their changes)
2. renaming it
3. making changes
4. testing it
5. if they like the changes a lot, they delete the old and rename the file to the old files name
6. if they *kind of* like it, they 'stash' it by leaving the new copied file as is, or differentiating it by giving it a new skin (the 'messed up' pigs that eventually became creepers in minecraft, are one example) and name, and possibly new behaviors, expanding on it as they go.
7. If they *don't like it*, they delete the copied files for the test, and continue as normal.
Most of this can be facilitated by a lightweight 'branch' command in a context menu (right click). All it does is copies and renames the files or assets in the editor or asset list.
It might be sufficient to save a copy of an asset as a commit to git when you first open
the asset in one of the editor. Local undo/redo then manages changes IN editor, until that editor is closed (causing changes to the object/asset to be saved).
Thats probably sufficient on its own to get 80-90% of the functionality we would need for git.
But this was a symptom of a broader set of design issues I hadn’t thought about.
More involved than you would imagine
Who is our developer?
Its a 1-2 man team, maybe semi-professional, but probably not. They want to do rapid development, with low overhead, without limiting more advanced concepts.
This is pretty close to a user story, but thats good enough.
How do we get that sweetspot 80-90% ease of use for most development ideas?
Sometimes the grass really is greener on the otherside.
I learned thoroughly and wisely while playing Skyrim, the truth of the prevailing wisdom, handed down like golden apples, through the ages.
A wise man once said “steal everything not nailed down.”
And so I did.
Learning by example
For starters, if I were the developer (oh snap, I am!), I would want tile editors and actor-component editors like Stencyl had. Even on a “triple A indie” title (the quotes make me nauseous just rereading that phrase).
In short, it should be easy, with some structure, but not rigidly-so to, combine with good practices, manage the project, and vastly more importantly rapidly and easily manage CHANGE.
Because ultimately, managing change, is what rapid prototyping is about. A tool that manages change by slowing you down, (high flexibility, resorting to raw code, data, and third party tools to import/export assets), manages change by leaving it all up to you, at the expense of slowing down the iteration cycle. You won’t forget (probably) what changes you made as long as you’re with the project daily, and keep good documentation (which you should anyway), because every. single. change. you make you will have to do everything manually, or spend manhours automating all of it yourself.
What a lot of the best tools do is separate not just asset management, but data, from code. I don’t want to have to write my animation timing in script, thats mixing code and data. Its brittle. If I refactor, and delete a script, I might lose that data. If I want to reuse an animation, I have to go in and copy the damn animation timing. If the timing is included in something like a data file, a csv, json, etc, thats one more file I have to mentally keep track of.
Assets are about bundling related objects such as files, in order to reduce the rising complexity inherent in managing ever-larger numbers of files or objects, in the same way tags or files let you organize related things in your filebrowser.
Its about being able to remember what is what, what goes where, and finding said what among all the other whats.
Its about managing the conceptual size of the project not on-system, but in your headspace.
Strengths and weaknesses.
We already know GMs strengths, and Stencyls strengths, but in general what are we looking for?
An IDE looking professional, is, sadly, important, because otherise it puts off beginners, and puts off professionals-turned-investors. But appearing “professional” is not nearly as important as being functional. That of course is really a tautology. In anycase, take for example, in GM, the curved splines that connect an open subeditor to its parent editor, are very cool, but if you use it long enough, the delay on closing a subeditor, is exhausting. Worse, it doesn’t save your changes until you close the subeditor, so if you want to play with a variable field, or experiment with changes, then your prototyping cycle becomes
→ open panel→ make changes → close panel → wait for it to close → compile/run —> test —> openpanel again —> wait for it to open
It adds seconds to the loop, pre-test and post-test, about five seconds all together for me, which if you’re making hundreds of changes in a sitting, eats half an hour to an hour a day. It’s obnoxious, it’s distracting.
Maps and more
I think 80-90% of why I love visual prototyping, never had anything to do with the visual representation of events, or code, or a map. Its that fundamentally, unless you were learning hotkeys in vim, you could just, at a glance, see the events attached to an object, without endlessly scrolling and hunting. You could see what instances would spawn on a map. And add or remove them quickly. Your asset manager gave you a list, without the bloat of a project folder that otherwise contained a combination of files that were either temporary, .gitignore material, data, or tertiary to what you were trying to do, the scaffolded husk of a game. It removed those distractions, and got to the business of prototyping as fast as possible.
Sure theres tools like Tiled which is overkill, but then if you want scaling, and instance customization, you’re using Tiled objects which are as far as I could tell, map specific (otherwise I couldn’t see how to import/export them). And the property options for those objects were nothing like the expansive list of variable types you got in a proper editor. Fundamentally, third party tools introduce friction into the development cycle when you’re iterating fast enough.
I also coded for a while without intellisense, the easy look up of existing objects, instances, variables, and once you’re used to that, you understand how much faster it makes holding a project in your head with the help of intellisense to guide you.
In short if I made a list of what GM and Stencyl did well, it would be.
seamless map import/export (GM gets this right. Close the map, its saved, you're done. Thats it)
seamless object placement/management on map - so instances can be placed and not just tiles, in the event you want to do more than level building, but also
world/game building (helps enormously with controller objects,easy property editing (GM facilitates this with default and custom object properties)
easy testing - press one button, and you're exported, and ready to test
easy packaging - everything gets copied into the project itself, regardless if it gets moved later, and is packaged all in one WITH the project.
seamless asset explorer
sensible default editors and fields like a map initialization section, easy selection of what map to start first,
helpers - look up instances by object *type* name (returns the first available), so you can do things like global controllers, without declaring them global. All you do is place or spawn at runtime, a single instance and you’re good to go.
instance functions and variables - things like 'other object' in a collision.
easy formatting - things like post-import editing of audio frequency.
intellisense - specifically of *instances* already placed, object types, and properties
Of all these, seamless map building/export/modification, along with instance placement, is what made GM great and quick, whether you were setting up a menu, a start screen, controller objects, or designing a level with stealth mechanics.
With stencyl you gotCLEAN separation between code and data, and easy packaging into objects.
Write code on a component, create fields (with or without defaults) to be presented on actors the component is attached to. No more editing instance or object creation code. No more parameterization.
for setting up defaultsEasy visual management of events lists, actors, components, and testing, via properties, and one-click enabling/disabling components, and events.
The problems with Stencyl and GM I’ve already gone over, but for example, GM required all your fonts to be carefully managed. There was no real resizing of text at runtime (not without doing some surface manipulation). Stencyl, like lots of Java applications, suffered from bloat, etc.
Meanwhile there were a plethora of open ended opportunities with a library like love2d.
build all my own tools exactly as I need them
meaning others dont need GM or a dedicated engine to use those tools
modding support out of the box
much richer script support
trivial/superbly easy tweening out of the box or with related libraried
trivial/superbly easy timing out of the box or with related libraried
trivial/superbly easy scaling out of the box or with related libraried
trivial/superbly easy full screen effects out of the box
project structure is all my own
reasonable platform support
*very* good scripting language support
low level access to what I need
*very* good font support
perfomant, with lua, or luajit.
All in all I was faced with a choice, and wanted to ask, even if I don’t do it, would it be worth it? Would it be possible? What benefits would it offer if I went that route?
A lot of design later I still didn’t know. Maybe I was insane after all. Maybe I had always been insane.
After all was said and done
This post is my first on substack, but hopefully not my last. When I started this morning six hours ago, I never imagined it would be this long. In fact substack is informing its too long for email. Like that “long long man” meme I once saw, that must just mean it’s better than all those short wimpy articles out there! And while I didn’t include a tl;dr, I hope nevertheless you have enjoyed this saga and found some use for it.
And after all was said and done, was the grass really greener on the other side?
As I wrote, I still don’t know. And maybe one day I’ll release my games. But at least I have seen how much faster and cleaner development could be, at least for us amateurs. And while maybe most of us will never successfully publish a title, and while many of us will never be professionals proper, what dreams could we reach for if we were willing to dream at all?
If only we were willing to ask
Could I do better?