Entry Page

I’m getting this down before I forget everything.

I had the explicit goal of doing a content-driven platformer, since I hadn’t gone for that before and it sounded like fun. I hedged this bet by doing a substantial amount of framework building to get the platforming going and to have a rough-and-ready in-game editor. Even so, it was an enormous crunch to complete this game.

Concept

I currently use a model for game design based around language; every game is described as an expressive medium in its own right, with a  specific vocabulary and forms of sentence construction. The content of the game suggests possible sentences, compelling the player to engage in conversation as their vocabulary affords. It’s the most successful model I’ve used yet and lends itself to any genre without getting mired in worship of a specific mechanic, conventional structure, or balancing.

For this game I went off to Wikipedia and looked up “Loneliness,” and found a reference to rites of passage. This was a promising avenue since it let me work with concrete elements instead of the metaphysical. The basic idea took shape pretty quickly – some tribal warrior type of character doing various outrageous tasks to prove himself – inventory and a task list were the main elements introduced at this stage. I also included a time limit as a way to cap off the concept with a finite structure, although looking back at it I don’t think that was necessary. The day-night cycle added some extra flair to the graphics, but the details involved in being able to lose the game were a chore and don’t add much to the experience other than to pad out playtime.

Day 1 (6:00 PM-12:00 AM PST, Dec 16th)

I fixed some things in the framework early on and started on a prototype scene, developing my concepts in a text file. The day concluded with bits of graphics work to get my player and some tiles started.

The palette I used for this game is one I had made some weeks ago. It is developed from a very color-theory informed basis, using the wheel to build a heavily coordinated set of hues with a saturate-desaturate alternation through the values, and I credit it for 90% of the look of the game. As I get better at game development as a whole I increasingly recognize that fundamentals are the key to all the involved skills – if you get a better understanding of color and shape, you get better not just at illustration or pixel art, but at graphic design, typography, architecture, etc. Similarly: rhythm can affect speech, music, athletics; and writing tends to tie together most skills in doing this sort of self-reflection. (Coding can be reflective writing, too, if you stop being scared of it.)

Day 2 (12:01 AM-12:00 PM PST, Dec 17th)

Early in the morning I did the bulk of work on backgrounds. Although my framework has both scrolling and flipscreen modes, I chose flipscreen for this game specifically because it let me use a more detailed approach to backgrounds in each scene with less reconciliation at the borders. It also lends itself to better performance which is always a boost.

The waterfall came in at this point; the waterfall is both one of the coolest elements and also the most expensive. I told myself, “wouldn’t it be awesome if the first thing the player did was jump off a cliff and dive into a raging waterfall?” Although I had Pro Motion if I wanted a traditional colorcycle setup, Flash doesn’t support palettized color cycling natively, so I had to come up with a technique to emulate those effects on the spot – and I had never tried doing cycling anims before, although I had studied some of the most ambitious color cycle anims in the world earlier this month.  I resorted to four copies of the background and did the rotation by hand, alpha fading one over the next and then swapping. A linear fade gave nasty looking results, but I found a way to overcome the artifact: first I squared the tween value, and then I tuned it some more with a specific exponent factor(my final value was 1.8).

I added in the day-night cycle soon after I had the waterfall in place. I figured that a color shift over the tilemap would look good and would help characterize the backgrounds, even if they didn’t change at all. As it turns out, it was not hard to set up a table with one entry for each hour of the day in game time(the game runs 6 AM to 8 PM – 14 hours game time, 15 minutes real time) and tween a Flash ColorTransform’s multiplier values. Between that, the auto-tiling sets I had made yesterday(this framework has nifty autotiling algorithms – I see room for improvement on more arbitrary uses of tiles though, like what I did on the trees), and the backgrounds, the look was feeling pretty well established. I still had plenty of sprites to work on, though, and the map needed filling out.

As the day drew to a close, I had the task list working, the timer, opening screen, and win/lose working, some sound, and one proof of tasks(pearl diving). I even got the environmental sounds working, which the game massively benefited from. In testing these things the in-game console was a huge help; you lose a lot of iteration time if you have to actually play the game to do anything. The final game has tons of leftover debug commands to tune the colortransform, set time of day, and set task completion, in addition to the map and graphics editing. So much happened all crammed into the later hours of this day that I’ve already forgotten a lot about it.

The last thing I did before I slept was the music. I don’t really like the end result – it starts off with an oppressive, John Carpenter Escape From New York feel, moves to a more contrapunctal style, and then finishes with simple repeated chords and arpeggios. All of those styles have merits; none of them exactly fit the game, in my opinion. However, I did not get a second chance. Ship it!

Day 3 (12:01 AM-6:00 PM PST, Dec 18th)

As on the previous day, I started in with graphics, and had most of my sprites done before my morning walk. One thing I found myself doing a lot, both on the previous day and this one, was to go back and polish completely random things. I did not restrain myself when this happened, figuring that if I had the motivation, I might as well follow through on it. In the timelapse you can see that I did a major revision on the opening screen, for example. The main character also went through four revisions – single color(too low-fi), outline color(too naked), and two revisions of clothing(too neon and then the final, which more-or-less hits my target of reading the outline first, and then the details).

Of course, what really loomed over my head was the completion of the rest of the gameplay. I switched back and forth between the various things to do – making sprites, integrating them as entities, map editing – until I finally hit the point where I really needed to start on more mechanics. If I remember correctly I did the dragon first, then the orange, some of the bird, then the lanterns, the rest of the bird, and then the pickaxe and gem.

The dragon was a scary problem to solve. Any time the character controller changes there’s a potential for massive bugs; fortunately I had had a bit of practice on it from doing the diving mechanics yesterday, in which the controller changes as soon as you touch(or emerge from) water. Those turned out to be more streamlined than I expected, with no actual swimming going on, and the same proved true with the dragon. I knew going in that I would place some entities and make a tweening path for the dragon’s flight to follow. Lack of planning meant that the path steered around the win/lose rooms, which is why the dragon flies up a cliff. After some work I had the player tweening along, and the dragon sprite following. But then the question was what kind of control the player had and how it was integrated; I realized it would be easiest to just add a y value on top of the basic tween y, and move the tween path down to the lowest level in the flight areas. The control turned out stiff but serviceable, and some patching up later, the dragon flight was done. I could have tuned that control to have more acceleration in it…oh well.

The orange was a straightforward addition to the dragon, and the basics of the bird were too – I already had projectile throwing from the framework demo and just adapted that to have a stone and use the inventory system(instead of a bow and arrow, an earlier concept that would have taken more effort). Around this time I finally got all the inventory working. I waited on finishing the bird in favor of the lanterns, though.

The lanterns were simple enough – touch and change animation, do a test to see if all are hit(the framework lets you iterate over tagged entities so this test can be done in a very reliable fashion). They caused a performance issue in that each one has animation callbacks every frame, though. In the final hours I somewhat optimized this so that they weren’t rendering offscreen, at least, but didn’t do anything about the callbacks themselves, which I suspect added a substantial load.

At this point I could see the finish line. I did some environmental sounds, the credits scroll, revised some sprites, got the bird’s flight in, did some more layout work, and finished the pickaxe section(which was again, pretty straightforward – I started from “projectile” behavior and adapted it to be more melee-like – it would have looked nicer following the player but I wasn’t about to care by then).

And….that was pretty much it. I finished with about 1 hour 30 minutes left on the clock, plenty of time to do my uploading and start the submission and documentation process. Later I got some feedback that indicated lack of clarity with dragon controls, so I added up arrow to it(instead of just jump); the LD website was (as usual) blowing up, so the change squeaked into the submission period.

What Went Wrong

Map editing was a bit slower than it could have been – more tool dev needed. Level layout suffered a bit because of this.

Performance got a bit impacted by the end; tuning the framework to let me optimize around flipscreening rules(e.g. making actors disappear when out of the room, putting the anim callbacks on the actors instead of a platforming controller) would help matters.

Some of the later aspects ended up less polished than I wanted as a result of time pressure.

The music wasn’t anything like what I wanted.

Some of the art techniques I used I was unfamiliar with; I could get faster/better at them.

What Went Right

Map iteration was great because it was all in-game.

The console, the console, the console. If you want to debug gameplay quickly, you need one.

The code did not degenerate into an unmaintainable mess, no siree. A lot of this stuff is reusable – and some of it I actually went and reintegrated into the framework base during the jam!

I finished all of that content!

The combination of the palette, the animation, and the environmental sounds really came together.

HaXe and NME were troopers, as expected. My personal stack for HaXe work is probably going to include NME more in the future(instead of my own hand-rolled build system), although I haven’t yet found a way to include SWF libraries  seamlessly as in my own builds. Technology is never perfect…

Finally…

Although it was a really tiring, stressful endeavor to do this, I’m struck by the result. I find myself wanting to return to the little world I made. Maybe elaborate on it with a sequel, even. Maybe that’s why people get stuck so much on pixel platformers – for the amount of effort, you can fabricate concepts pretty quickly, especially if you have nice tools to work with.

As always, I credit maintenance of a sound lifestyle for keeping me healthy and sane during the compo. Getting out of the house, getting enough sleep. Taking my vitamins, balanced meals with a side of vinegar. Caffeine in moderation. If I’m going to party, it’ll be around other people, not just sitting in front of the screen. And even doing all that, I’m still exhausted by this, psychologically speaking.

I should sleep now.

I have a song pretty much done, it’ll play for the “end credits.”

I succeeded at most of my goals for the day – did more polish than I expected, less content. But I’m in good shape. I just have to blast through the rest of the content tomorrow.

	dragon flight code
		get it spawning
	bird flight code
		birds placed in map are spawners?
			or we just have them run on a consistent cycle?
	spriting:
		obstacles for dragon area(attacking birds)
			(reuse birds for hunting segment)
	three tasks:
		diving
		hunting(birds)
		fly dragon
	some sounds
		hit
	finish sounds
	add two or three tasks
		mining
		collect fruit
		make fire

	Ending celebration/failure

I’m getting worried that I won’t hit the targeted scope at this point. The assets needed aren’t too much, individually, it’s just that I have a pretty hefty list and I don’t feel as confident about being able to pump out content consistently right up to the deadline.

Got some environmental sound in – waterfall noise, and it changes as you enter different screens.

However I haven’t made much progress on the gameplay lately. I really want to get some of the gameplay in there before I sleep.

TODO
	new block type for water - the surface toggles platforming/swimming, or somesuch
	start sketching out whole game and getting bgs in place

goals for rest of today:
	inventory working
		pick up stones
		one more button to drop vs. use("shoot")
	dragon flight code
	diving code
	bird flight code
		birds placed in map are spawners?
			or we just have them run on a consistent cycle?
	spriting:
		pearl sprites
		bubbles
		swimming sprites
		dragon sprite
			idling
			flying
			hit
		obstacles for dragon area(attacking birds)
			(reuse birds for hunting segment)
		throwing stones(instead of bow+arrow)
	three tasks:
		diving
		hunting(birds)
		fly dragon
	some sounds
		splash
		throw (replace the current thingy)
		hit
		_integration_
goals for tomorrow:
	finish sounds, add music?
	add two or three tasks
		mining
		collect fruit
		make fire

	Ending celebration/failure

In-game tasklist is working

Win and lose conditions are in(although there is no way to “legitimately” win, just a console command)

Day-night cycle and timer \o/

Some shots

Collecting some thoughts out loud. I already did about 4 hours of work today.

I have the basic platforming structure of my game in place. It’s shaping up to look pretty good(maybe not the best though, I see some pretty competitive entries art-wise) and I have a few more things to do on the art front. What I need to get done by the end of today is some actual content.  A few thoughts came to mind during the walk(in addition to stuff I had in my last post):

Diving for pearls

Minecrafting for gems

Riding a dragon

Shooting down a bird

Still have to do some structural thingies before that, though. Onward!

I spent about 2.5 hours making these:

This  ”rite of passage” game will involve the main character(the pinkish silhouette thingy) adventuring alone through the forest and caves, trying to complete various survival tasks within a time limit(before the sun sets). Examples:

	hunt the bear
	tame the tiger
	find fruit
	make fire
	build idols
	outrun the deer

As of right now my basic character movement and animation is going, with a walk cycle, jump, knockback, and recovery.

I still need to get some core features in – game restart button, view tasklist, display timer, show a title + help thingy. It’s looking good for the first night of work, though.

My concept for the game will be “rite of passage,” some kind of platformer in which the main character goes into the woods/caves/etc. to prove him or herself.

I am doing a timelapse, I started 20 minutes late though. Oops…

Demonstration app

Source .ZIP

My previous post described the stuff I built for this framework. To get an idea of what is in the demo, follow these steps:

1. Press Ctrl+` to open/close the console
2. Type “help” in the console to show the available commands
3. Type “loadmap testmap” to run the demo level. Arrow keys move, A and S jump/shoot.
4. Type “edit” to enter the map editor, “setdef”, “setentity”, and “delentity” to browse/set the painting tool. While editing the camera is scrolled with the arrows or ctrl+arrows. Type “play” to resume play.
5. Type “tileedit” to enter the tile editor. Commands are shown at right.

In the past I’ve tried building “frameworks.” They never did what I expected them to do. But this past week I’ve worked on another one and it’s actually shaped up reasonably well. Calling it “TriadNME” – it is a haXe/NME/Flash10 2d platforming engine with applicability to other 2d games. Some notes on interesting elements of the design and things I discovered in the process:

• Mostly based on stealing existing good code from old projects. Proven code is golden, and possibly worth more than the architecture itself. I would actually consider Triad a second generation framework(the first being some bits of code for timing, the entity system, build system, etc.)
• Very centered around the haXe dynamic/static typing mix. Entities are anonymous objects, with a component system based on “conventions” of data layout(field names, an array of component destructors, etc.) attached to them. I’ve used this for about a year on many projects – it feels like the right mix most of the time.
• Lax approach to performance to favor reusable functionality. Essentially, I give myself room to use a layer or two of  indirection(callbacks, lookups, etc.), but try not to go much deeper. So, e.g., instead of a hardcoded timer I now use an Alarm class with callbacks. Character controllers, camera movements, etc. are similarly based on callbacks, thus it’s easy to go from (e.g.) flipscreen camera to scrolling and centered around the player. If I want to regain performance from those things – I can usually rewrite the specific functionality.
• Minimal contextual instancing. By this I mean – at the start I prepare all the core structures(whether as singleton instances or as static classes) and never destroy or replace them. Instead I call reset methods and toggle visiblility on the Flash displaylist. As a result, I never have to litter tests in the code for whether a certain kind of data is available, because it always is. To change contexts, I disable some functionality. As a result, there’s a whole body of code that simply doesn’t exist, since disabling is (in general) easier than destruction. This goes hand-in-hand with the approach to performance.
• My approach to algorithms has generally improved. I’ve started making my own “xxxTools” static classes for common algorithms – so I have some for math/trig/probability now,  some bits for strings and hashes, some bits specific to my AABB/tile collision system. Conversions between measurements (degrees/radians, pixels/tiles) and alignments (centered, left, right, above, below) are a major part of the toolbox and my core data structures tend to include a lot of conversion methods. Similarly, more structural algorithms like ”array of objects with name fields” to “string hash of objects” are starting to come into play. In the past I had a horrible tendency to rewrite simple algorithms and inline stuff that didn’t warrant the customization, but hopefully I’ve come around on that.
• [haXe-specific] – I use many more anonymous structures. HaXe is structurally typed and lets me add a bit of extra type checking just by wrapping everything in a little structure – e.g. most of my points are {x:Int,y:Int} or {x:Float,y:Float], instead of being a class. This adds a bit more flexibility in writing the data because I can just inline the structure into a function call instead of going through writing a class, a new() method, etc. Doing this lowers performance for the Flash target somewhat, but adds a ton of code clarity.
• While heaping on engine-level features with sprites, rendering, physics, I specifically tried to engineer them so that they’re easy to rip out if I don’t want to use them for LD. This had the effect of making them modular without an explicitly “modular/pluggable” system design – a field on the main class, one call to initialize, one call to reset, one call to update. Take those out and the system is essentially gone, although other things might reference them – but that’s more of an “integration” problem and usually just requires more things to be deleted.
• The in-game console is increasingly central to the workflow. I try to cram as many in-game tools as I can because – besides the obvious iteration improvements – it has a knock-on effect on the architecture where I need to keep data in both editable and playable forms, thus it starts decomposing towards the “real” constraints.  The console works as a way to quickly expose editing functionality. This is something I could continue to refine considerably with tool-specific namespaces, unix-esque pipes, etc.
• I opted for a tilesheet format that uses a “smallest size” of tile and rebuilds larger ones from that, similar to the character-mapped graphics of older consoles(NES, SMS, etc.). This has some interesting effects on editability – with an in-game editor the downsides are mostly covered, but the benefits in internal architecture are surprising: the structure of graphics access is greatly clarified when you have three ways to inspect a tile sheet – by set name, by set index, by tile index. It works particularly well with the autotiling algorithms I’ve made(one of the main reasons I started down this path). It also means that the framework should port more easily to a 3D-accelerated setting since only the rendering methods have to change – the original data for sprites and tiles is already a nice NPOT-sized thing.

I am entering that stage of low sleep where one is productive again(got up at 6pm, it is now 1pm). Therefore I shall waste it on words!

1. I will be doing next LD’s jam(team project) and compo(solo). So I am setting myself up for double the pressure \o/

2. In preparation for next weekend I am taking my Longcat code and factoring it up to make it a framework for simple platforming and shooting, including built-in map editing as well as image editing. If I find time it will also get sound editing built-in courtesy of SiON.

That’s all for now!

I think I’m done, at least within the compo time limit. I could spend the last few hours trying to fix more bugs, but I’m not very motivated so I’ll share some early postmortem thoughts instead.

I have a process I’ve developed for game design based around these concepts:

1. The way people become interested in a game is through its pieces. Good pieces = instant tutorialization and obvious mechanics. Therefore I now always start off by making good pieces and a fitting playfield for them. In the past I didn’t do this and my games sucked. Now they suck much less.

2. I try to achieve good game dynamics using the available pieces(or tailoring the pieces a bit more to fit). I use a very specific definition of a game dynamic, which is the intersection of two feedback loops produced via game mechanics. In general, the more intersections that occur, the more compelling the gameplay is going to be. Game events that occur outside of a feedback loop should only exist to support the fiction of the game pieces. That said, I don’t follow this rule too rigidly – it’s a model that I’m trying to test, not a dogmatic order – and I try to name and categorize what I’m achieving in broader terms. In this case the theme of “Escape” suggested someone nearly powerless, trying to escape hazards.

Starting from that little kernel of an idea, I drew some inspiration from other games: the “Deathrun” maps seen in some FPS games, Tower Defense games, Transformice… It seemed inevitable that I would do a multiplayer game where you had a whole group teaming up to get past a “big boss” type.

So I drew up my game’s playfield in Pro Motion, making some early assumptions that I’d have a low-res, single-screen game running more-or-less strictly on a tile grid. I was a bit worried that the playfield would be too small, but it turned out not to be an issue. As I drew I quickly decided it would be an ice cave rather than a generic cave, because the ice cave would suggest more interesting pieces. (as someone remarked, I could have done a lava cave instead. Different game, maybe that’s “Heartbreaker part II.”) Quickly I nixed the nascent generic obstacles I had first thought of(spikes, gun turrets, etc.) and replaced them with their ice-cave equivalents: icicles, slippery ice patches, and a yeti. I thought about the obstacles as I drew up the character portraits. First I did the Ice Queen – an obvious villain for the cold setting I was developing. Then I soon decided that it was tending towards a magical feeling, so instead of generic runner characters with torches or something, I opted for the counterpart Fire Mage. The “broken hearts” setting came out of that – I had been wanting to use the title “Heartbreaker!” for a while, though I had had a much different kind of game in mind for it. I had some trouble getting the portraits looking good, but left them for the time being.

By this point it was getting a bit late into my first evening, but I pressed on to set up my base code at this point. It’s all dribs and drabs from earlier projects – the build system, some timer code, the scene initialization process, the Player.IO connection code(the cloud service I’m using to host this and run the multiplayer APIs), the algorithm for collision, the sound management. I finished with just a tiny bit of proof that I could make a real-time multiplayer game – I’ve never tried doing a complete one start-to-finish, though I’ve worked with multiplayer/network code in other contexts.

The next day, I basically pounded away at the game until it succumbed to my will. It’s not pretty code and has some major architecture flaws, which is why I’m unmotivated to try a bugfix now. The biggest flaw is that out of inexperience I tried to push too much data into too little state, resulting in desyncs between the mages and the queen’s viewpoint, and various bits of oddness with how the characters move around(e.g. when a piece is brought onto the playfield the mages can be killed by its tween animation – a very unexpected game mechanic). Also, Flash is generally poor at networking for games – it supports some obscure stuff(various kinds of streams and proprietary protocols) and it has UDP in the AIR client, but if you’re making a web game you’re basically stuck with TCP, which means things periodically go berserk as the reliable delivery “catches up” with the game.

In any case, by the end of the night I had everything in a more-or-less playable state, which I mostly credit to player.io having a sane API and a decent service. I even had some players who got addicted to the game, buggy as it is. So I went to bed, and when I woke up(a few hours ago) I immediately got to work on some sound and music assets in Renoise, cleaned up the portraits a little, and got it all integrated. And that’s where I’m at now…

I’m a bit torn between trying to rearchitect the code after the compo is over and make a bigger game out of it, or just moving on with my main project, Moto. I guess I have some time to think on the matter.

http://www.ludamix.com/games/heartbreaker

It’s multiplayer After a few rounds of playtesting I got it to “still very glitchy but playable,” which is the most I’m going to aim for in the compo timelimit.

I’m going to bed now, when I wake up I’ll try to get some sounds in.

And a screenshot:

I just got the player.io API connecting to a dev server. I have some experience with this from other projects – it’s pretty decent for making a multiplayer or otherwise net-connected Flash game, though I had some issues getting it into haXe initially(my solution was to get rid of the type annotations and use Dynamic on the parts that were breaking).

The game design has developed from “Dungeon Master and Runners” to “Ice Queen vs. Fire Mages.” The title will be “Heartbreaker” – one which I’ve been itching to use for a while. The mages have been spurned by the Ice Queen, and now compete to escape her cold, deadly kingdom, using their fire magic to clear the path. Meanwhile, the Queen toys with them, placing ice-themed traps and obstacles such as spiky icicles, Yetis, and slippery ground.

Some arts(spritesheets not shown – for effort reasons):

I am going to aim for a multiplayer game in this LD, using the player.io AS3 API to handle all the nasty issues of connecting, hosting, etc. It will be very straightforward, based on the “Deathrun” maps you see in some FPS games:

The first player to join is the dungeon master. Subsequent players are “runners.” The runners try to escape the dungeon by reaching the exit, and the first one to succeed becomes the new DM.

The dungeon master tries to defeat the runners by moving around various traps in the level. The DM has limited(recharging) energy to move the traps. I am planning to implement these traps:

• 4-way gun turret
• Hidden land mine
• Sticky patch(slows)
• Bullet reflector

I don’t know if I’ll see an entry through for either compo or jam this time, but I’ll give it a try.

Going to be using haXe/Flash9, and some bits of my old game code(don’t know what yet, but it’ll all end up published in the end) for the code side of things.

For art I guess I will do my usual Gimp/Pro Motion/Inkscape mix, and sound-wise I will probably stick to 8-bit stuff with sfxr or somesuch.

In the first few hours I’m gonna juggle my thinking about the entry with another release of my main game project, Moto. Got some new graphics and stuff to show

It turns out to have some astoundingly deep gameplay for how few elements are in there. I don’t think I took the level design nearly as far as it could go.

Play here.

Play

I have all the tiles in now, and more sounds(“Expert!”). It was a bit tricky for a number of reasons:

• Still coming to grips with the way Pro Motion works. It’s a realllly powerful tool, but that leads to several kinds of modal situations that are unintuitive(working with alpha, picking up tiles so that they can be placed – for some reason you can’t just click in the palette).
• I also wasted time making tiles in an inefficient way or making tiles I didn’t actually need for the system I ended up using.
• I had to make a “chunked” tile engine based on the basic one, which splits each tile of collision into 4 graphical pieces. This also meant some data entry, fortunately I didn’t have too many pieces.
• For some reason, Firefox started caching the swf and refusing to let go. I finally got it going again by manually re-entering the URL.
• I also had to add a second layer of transparent 20×20 tiles on top of the background. This wasn’t tooo difficult but the swf-caching problem really slowed me down.

Anyway, now I think I’m going to do level design, get a title and win screen together, and call it done. I seem to be on track to use almost all the time available. This is probably the best I’ve ever done with any game jam situation, usually I get demotivated or stop at an early point

Check it out here. Although the sound effects are a bit sparse right now, just “shoot” and “explosion”…I’ll probably do a few more.

For your sampling pleasure

All of the note data was made in Busker – I just laid out some notes, then applied a chord sequence and a style. Then I did the instruments and mix in Mixcraft. Not totally happy with it, but hearing it again, it feels like I spent way more time on it than I did.

Now it’s on to some sound design in Renoise.