my first exposure to bitsy was through my friend candle's games in 2017. bitsy appealed to me for a number of reasons: the immediacy of being able to open a web page and get started, the instantly appealing simple graphical style and the extremely limited scope meaning that I could complete an entire game in a matter of hours.
even though I had only played one or two bitsy games before I started making my own, the template was already set in my mind: a bitsy has about 1-3 rooms, takes about 2 minutes to play, has 3-colour palettes (the third colour is for interactive items) and has a single looping mp3 playing in the background. despite that bitsy has never supported audio, hacking music in has been par for the course since before I started using it.
as a web developer, it was trivial to me to add music to my bitsy games, but clearly that's not the case for everyone; from very early on, the process of making a “typical” bitsy game has involved some arcane knowledge and extra steps. this incongruity stirred me to imagine versions of bitsy with the boundaries pushed and pulled in different directions. what would make it easier to use and more accessible? what would enable more complex storytelling and intricate worlds?
especially during my first year of bitsy, those boundaries were constantly being pushed through home-brewed hacks (especially by sean) but the general template of a bitsy still seemed very well-established.
today, hacks are so prevalent (and so much easier to apply due to tools like borksy and add bitsy audio) that a bitsy is a nebulous concept with no clear edges. and despite that hacks are easier to apply, working with them is still convoluted. users must either be aware of slightly lesser-known tools like bitsy saviour or face a difficult playtesting period in which the game must be re-exported, and the hacks re-applied, after every change.
although I can't speak for a new bitsy user, I think it's fair to assume that making a “typical bitsy” is more difficult now. new users did not cut their teeth on simple, single-room bitsies; they want to recreate the complex, masterful but high-effort works that introduced them to bitsy in the years since.
since I started using bitsy, I've often imagined what it would look like with slightly different restrictions and features, and how those changes would affect the games people would make with it and the way creators would approach it.
what if a bitsy room was 16×9 instead of 16×16? would people play bitsy games fullscreen? would the low resolution work at this size? what about on mobile - could people be persuaded to rotate their phones 90°?
what if bitsy's 3-colour palette could be used arbitrarily, instead of being split between tiles and interactive elements? would this lead to the bitsy equivalent of pixel-hunting? creators would have more artistic freedom, but would it be harder to create nice tiles? if bitsy's palette was expanded to just 4 colours, would users experience choice paralysis?
what if palettes were per-tile instead of per-room? we'd have an effect similar to attribute clash on a zx spectrum. could be very interesting; the upcoming game redlander by gadgetpatch has a similar look, using expanded palettes - an undocumented bitsy feature.
so, since I started using bitsy I've been imagining what my own bitsy-inspired game engine would look like. I've made many pages of sketches, notes and half-baked ideas. though my concept feels fairly well-established in my mind, it's subject to change as I develop the engine and make my own games to test it out. at the time of writing I have a design document written, a roadmap and a very basic mockup of the game runner executable.
while I don't have much to show right now, I'm hoping that by writing about my ideas I'll get some useful feedback, and motivation to work on it. so please let me know what you think! the main features of my hypothetical game engine are as follows:
web vs. desktop is a complex topic and I'm not going to claim that one is better than the other, but I do think it would be interesting to have a bitsylike desktop editor and games.
one thing to consider is that web games are seen as “lesser” - if you've ever tried to make money off a web game, you'll likely know what I mean. I'm not even sure that I want to see for-profit smallgames, but I think it would be good to empower creators with that option if they wanted it. I do think there could be a small market for cheap smallgames; I'm happy to hand over a few quid for a friend's zine for example.
perhaps it's more a feature of itch.io's interface, but downloadable pay-what-you-want games confront the player with an arm-twisting “how much do you want to pay?” dialogue, whereas pay-what-you-want web games have no such prodding. a web game of mine has been online for six years now, with over 2000 plays, and no payments whatsoever. I'm not sure how fixed-price web games fare; I'm not even sure I know of any, at least not since the death of flash.
I can see there being accessibility issues for desktop applications; on the web, machine translation and text-to-speech are available to users, although I'm not sure how well they work; I want to make sure I write the editor and engine in a way that allows for easy translations, and see if there are existing solutions for text-to-speech.
and, of course, the web is more universal; it can be accessed from smartphones, odd hardware, unusual operating systems and so on. I plan to target linux and windows; I will try to support mac, but apple do seem to make it incredibly difficult. I may have to borrow my housemate's old macbook for this, since it sounds like cross-compilation is not easily possible…
I have no plans to support smartphones, since I don't use one and have no interest in them. this sort of thing is better left to môsi I think 🥺 - I'm happy to find a niche instead of trying to please everyone.
one of my favourite aspects of the bitsy editor is that you can move, resize and close tool windows as you like. this allows for for varying workflows with ease. I'd like to take this idea further, and allow more than one of each window - e.g. open two rooms and compare them side-by-side.
while investigating different cross-platform gui frameworks, I was very interested by imgui - a toolkit specifically designed for creative tools, with child windows as its main feature. I think it'd be a good choice for for a smallgame editor.
game data will consist of a directory of files and subdirectories, and will make use of existing formats where appropriate. users will be able to easily copy assets from one game to another. I sort of hope this creates a culture of ripping assets from other games, as with the rpg maker 2000 community of yore 😈
engine-specific assets will use TOML (Tom's Obvious Minimal Language) as this is both human-readable and writable without having to particularly learn its syntax, as well as being machine-readable and writable. it can be edited in basically any text editor - no IDE or syntax highlighting necessary.
more generic asset types (e.g. palettes, audio) will use established and well-documented formats; this will allow users to take their pick of programs for editing game assets if they wish. where possible, editing will be available in the game editor itself, but things like audio will likely be outside its scope.
I appreciate bitsy's bespoke game data format and the advantages of having all game data in one place, but there are definite downsides to this approach - it's harder to create tools or parsers, and it can be hard to manually edit game data if the game is very large.
I appreciate the desire to make scripting approachable to new users, but bitsy's dialogue editor can be quite clunky, especially when working with conditions or large branching statements. as much as new users may be scared off by “code”, I think if it's simple enough it might not be a big problem. a basic dialogue script in my engine would look something like this:
say "hello"
say "I'm a cat"
admittedly this could create some problems if the user put a quotation mark inside a string, for example - but it might be possible to have a helpful clippit-style “did you mean to…” prompt for syntax errors.
many simple games could be made with just the above, but a more complex script could look like this:
say "I'm a cat"
if playerhasfish is true {
say "oh! a delicious fish!"
set playerhasfish to false
} else {
say "don't talk to me unless you have fish"
teleport "scene 2" 5,7
}
more complex, but not too hard to understand, I hope. I would make good documentation of the scripting language a high priority.
you may have guessed, but the above say command is a function that takes one string parameter. behind the scenes, say is another script that uses more primitive functions like drawing a rectangle to the screen and then drawing the string on it with a given font. I'd like users to be able to create their own scripts - for example you could copy say to create think and add some little thought bubble effects.
I'd like to be able to attach these scripts to different events; for example a trigger named “when bumped” could fire when the player sprite bumps into this sprite. a scene (or room) could have an “on load” event, with a script attached that changes the game's palette. in this way, many of the hardcoded features of bitsy can be made scriptable.
to keep this friendly to use, I'd like to:
I think 4 colours would be a nice limitation; colourful without being overwhelming. but I'm not sure - when I get to the stage of creating example games I will probably tweak this. I may end up going back to the bitsy standard of 2+1. I can imagine palette-switching might make graphics look weird if they were designed with a specific palette in mind. however, larger palettes (4-6) are good if I want to make puzzle games a possibility, for example.
for now I'd like to stick to palettes affecting the whole screen, but I will keep per-tile palettes in mind as a possibility.
the bitsy bitmap font is cute, but the fact that it's a different resolution to the rest of the game makes it feel like an affectation. I'd be quite happy to use standard text rendering, and allow creators to pick a font that suits them. you could still use a “retro” font if you wanted.
I think this could also be beneficial for internationalisation; right-to-left languages and non-latin scripts could be easily supported.
one thing to note is that some of bitsy's alternate character sets are absolutely enormous; I think unicode_asian is over 10 megabytes…
for the time being, I'd like to support modular music formats (mod, xm, s3m, it), in keeping with the small and lo-fi aesthetic. am I a fucker for not wanting to allow mp3? I'm certainly a hypocrite, since almost all my bitsy games have mp3 soundtracks. but I love tracker music and I like the idea of people searching through and ripping demoscene and keygen music for their games, finding legitimate public domain or creative commons works to use, or better yet, making their own. speaking of which…
consider this one a “stretch goal” or separate project, but I'd like to create a modular music format and editor that's easy to use and has a tiny footprint. like modplug tracker or milkytracker but without looking like a spreadsheet or hex editor.
and ideally:
any ideas? I'm struggling to think of a good one. top of my list so far is peachy but I think it sounds a bit too similar to bitsy…
I have no idea if I'll ever get anywhere with this, but it's worth dreaming about!
max bradbury 28/3/2021