The post jam version of A Strange Package is coming along quite nice. A new coat of paint on the graphics of the game and (finally!) choices have been implemented in the game! If everything goes according to plans, the game will be completed this Sunday.

So the first Alakajam! is over and for those of you who enjoy data and visualisations, I've made some graphs!

Categories

Let's start with something simple, but certainly important – which categories are the most important for a good result overall? Here is the correlation table of the six categories:

It seems that Gameplay is the most important for a good Overall result, which makes sense. Audio and Graphics correlate less, so good games with terrible graphics and bad games with amazing graphics are both conceivable. Also note that all the values in the table are quite high (values less than 0.5 would indicate negative correlation). In other words, a "good" game will usually get better ratings in all categories, a "bad" game will get worse ratings in all categories most of the time. More on this later.

Next up, category averages by rating:

This probably tells us more about our voting preferences than the games themselves – people rate games high in Graphics more often, while they are more critical of Gameplay, the actual experience and fun of the game.

What about the best / worst categories for ranked games?

Note that there were no games where Overall was the best or worst rating-wise. It is common to rate the game in Overall somewhat close to the average of the five other categories, so this is not a complete surprise.

Votes

Let's look at votes a bit more. These are the counts for each rating value:

This looks like a nice bell curve, though it is skewed somewhat towards 7, as opposed to the true middle of 5.5. We can also guess there are some psychological gaps between giving a game an 8 and giving it a 9. Similar gaps are then 4–5, and 2–3. 2 probably seems extremely harsh to many people, so they'd rather shift their vote slightly towards a 3.

This "spread" is the difference between the lowest and highest rating given to a game in any category. This partly explains the fact that a "good" game more likely gets high ratings in all categories mentioned above.

Popularity

Now let's see whether a game's results are at least somewhat predictable based on its popularity, measured in the number of received ratings:

Interestingly enough, there are quite a few games which ended up very high, despite being quite close to the minimum required votes (10). Some teams / developers may have forgotten about Alakajam! after submitting their games! Let's look at the same graphs, but this time measuring the number of received comments instead of ratings:

Once again not a super clear trend – we can only potentially observe that getting more than ~ 17 comments on your game means you are likely ending up in the top 40%. This may very well be within a statistical error, so until Alakajam! grows a lot and we can get better data, don't depend on this!

Voting days

And finally, let's have a look at when and how people voted. The rating period was exactly 14 days. We can see how many votes were cast on each day:

The first day (first 24 hours) was when most people did their voting. The spike on the third day may have been people coming back to AKJ after resting for some time. There is a minor spike on the Saturday of the second day. The results hype attracted the last spike. 40 or so of these votes were from our stream with Danae though!

And finally, I was interested in whether or not the voting averages differed over the days:

Although there is quite a sizable difference (1.26) between the voting average of the fifth day and the eleventh day, I am not sure how statistically significant this is, as there were not so many votes cast on those days. A possible factor could have been that entries which get rated later on more likely need to be "rescued", because their teams forgot to rate other entries. This, in turn, may have been because the teams weren't very happy with their own games. But that is just wild speculation at this point!

Nonetheless, I hope you found these graphs interesting. Stay tuned for the next ones :)

So the ratings are out and I don't exactly agree on the results. My top overall ratings, for those interested:

Solo

Chrysopoeia (9.00)
The Hermetic Order Of Alchemists (8.00)
Mixium (8.00)
Sil the Alchemist (8.00)
The Six Keys to the Philosopher's Stone (8.00)

Three puzzles in the top 5, what has befallen me?

Team

The Wanderer (7.00)
Modern Alchemy (7.00)
Transformist (7.00)

Considerably lower averate score for team entries this time. There were only 15 of them, which might explain it.

Other?

But this is not about the top titles, you see I always play and comment on as many entries as I can in a jam (this time all of the 58!) For me the best projects are those that don't simply make me think critically, but also make me realize something or remind me of an interesting design.

This time there was one of those, the last title I played, an unranked, fake themed entry:

Redshirt's Escape

So what did I realize? Even exploring an empty, abandoned complex can be exciting with a ticking clock of impending doom in the background. Also reminded me of an older design I haven't gotten to prototyping yet, concerning a rogue AI in a spacestation, so that's good.

Great jam, worth repeating.

This is a cross-post from my blog, where you'll find many more in-depth gamedev-related articles.

Mixium is a puzzle game in which you mix liquids to achieve a particular ratio. The trouble is: your beakers don't have any scale on them, so you can only fill them to the brim or empty them into a larger beaker.

Mixium was my entry for the 1st Alakajam! game jam competition. I entered in the Solo division, which means everything has to be made by a single person from scratch within 48
hours. It ranked 5th place overall, 3rd place in the Theme category, and 1st in Gameplay! Even though Alakajam! is still a relatively small event (there were 36 contestants in the Solo division), this is a new record for me, and one that will be hard to beat as the community grows.

Here's a little postmortem of how things went.

What went wrong

• I didn't have a free schedule this weekend. The competition ran from 21:00 on Friday until 21:00 on Sunday, but all of Friday evening, Saturday morning and Sunday evening were taken up by social activities. This, plus the need to catch up on some sleep, left me with about half a weekend to make this game. If I'd had more time, I would have added a nicer background (a drawing of an alchemy lab, animated if possible). I would also have added some sound effects: just pouring and a poof sound when you make something would already have made a big difference in game feel.

• The original idea was about mixing metals into alloys, and I had chosen the punny name Alloy Vera for that reason. But as I ended up with all sorts of random liquids, whose names mostly end in -ium, I changed the name to the more appropriate Mixium instead. I still like the original name better, because it's catchier and it implies a person whom I could have given some character through her journal entries. On the other hand, you'd have ended up with much more boring substances if all you had to mix were metals.

• Because I was afraid of being bitten by floating-point accuracy problems, I started by implementing a fractions library (there doesn't seem to be one in Haxe). This in itself was easy enough, but because I was expecting to need a lot of operations on these, I wanted to give my Fraction class overloaded operators. Turns out, operator overloading in Haxe is stupidly limited: it can only be done on abstracts, and like most of Haxe, only documented in the form of some examples. I couldn't get it to work, and eventually just went with regular add, subtract, multiply and divide methods. I should not have wasted so much time on this; I guess I've been out of game jams for too long and was having trouble shaking off my “clean code” mentality.

• Then it turned out that pouring fluid back and forth a lot would result in overflow in my Fraction class. Instead of also coding up (or downloading) a BigInteger class, I decided to just use regular Floats instead, and compare them with some tolerance. Yes, this means you can solve some levels by just pouring back and forth until the mixture is close enough to the target ratio! But I deemed this realistic, and a nice “think outside the box” loophole.

• Another technical problem I encountered is that the html5 export of the game did not render the fluids correctly. Actually, it didn't render them at all. HaxeFlixel is supposed to be fully cross-platform, but (like Haxe itself), it doesn't deliver on this promise. I don't remember the exact problem, but I did spend over an hour trying various combinations of rendering sprites to other sprites in order to make it work in the browser. I really should learn to work with the underlying OpenFL library directly, which has fewer such bugs, and they're getting fixed more quickly. HaxeFlixel lets you pick between “legacy”, which gives you an old and buggy OpenFL 3, and “next”, which gives you the new and great OpenFL 4, but with lots of bugs in the HaxeFlixel wrappers instead.

• A bug: when pouring an empty beaker that once contained something into a nonempty one, the fluid disappears in both; and when pouring out such an empty “dirty” beaker into another empty one, it crashes entirely. This turns out to be due to a division by zero bug, which I'm normally really wary of, so I don't know how this slipped through the cracks.

What went right

• Despite the shortage of time, it's still a finished game, with a beginning, an end, several puzzles with a gradually increasing level of difficulty, consistent graphics, and some background music.

• This is the second game that I've ever made music for. It's not exactly Mozart, but it somehow still made 13th place in the Audio category, which must mean that people didn't hate it too much. Bosca Ceoil was new for me, but it's super easy to work with.

• The difficulty curve seems to be alright, judging from the feedback. This was largely luck. I made most of the levels by copying the previous level and changing it to add a twist, but it was tricky to make sure that the changes didn't make it trivially solvable. For example, if you have two spare beakers that differ in volume by only 1, you can make pretty much anything with them. I also found that the more beakers I added to a puzzle, the more options the player has and the easier the puzzle gets.

• I finished the splash screen literally in the last minute before the deadline. It doubles as a tiny tutorial, because you have to click the beaker to continue, teaching the player that beakers can be clicked. It would have been better to make them light up when hovered, but there was no time for that. (I initially had them move upwards when hovered, but that got too distracting, and there was no longer a distinction between the ‘hovered’ and the ‘selected’ state.)

Thanks to everyone who played, commented and voted! Here's the results page with comments, and here's the playable game. Enjoy!

-Quick Post-

I'd like to thank everyone who played my game and gave me feedback.
I really super duper ultra mega appreciate it! I will try to improve
on the game based on your suggestions (once I get my computer fixed).

So… yeah that's about all I wanted to say. ;-)
~Toffie

Should have written this a few days ago, but I simply forgot.

The idea

I read the theme, then the real theme and immediately looked up the history of alchemy on wikipedia, interesting stuff. Then moved on to other resources (mostly on Scribd), more interesting stuff! Somewhere here the idea of an interactive text based story started to take form and then it clicked. Better run with it.

The prose

Wrote 15 pages worth of design and prose before implementing anything. It all came out with relative ease. No stress, no fuss, just writing for 10 hours worth.

The code

Here's why I was feeling so sure about the implementation. I'd been working on another text based project recently and that system, I reckoned, would fit well here too. It did! Had minor issues, but it was mostly smooth sailing (and hard work, of course). The fact that parts of the system were data driven and other parts code did annoy me quite a bit.

Release

Finished the alchemy actions last, at the beginning of the final hour! Managed to draw one quick cover image while setting up the jam and itch.io pages. It came close and there is a RL reason for it. Had to spend 6 hours away from the jam on Sunday morning.

Total effective working hours: 43

Post-Jam

After the jam I realized that the code part was a blessing in diguise. It is always easier to hack things together in code than in a custom data files. It took me many days (only a few hours per day, though) to port all the code logic to a completely data driven system for the post-jam project.

The project is nowhere finished, unfortunately. There are many story elements that I want to add to it and I haven't had the time to do a lot of writing yet. Now that the rating period is over I can concentrate on that some more.

Conclusion

The first interactive short story I've ever made; learned a few writing techniques. Also improved the data driven system for future projects so that's good.

A great jam as usual. I do enjoy these events a lot; the testing and commenting part is a big draw for me. I managed to try every single entry this time, taken that there were only 58 of them. I dread the jam where there are more entries than I can play in two weeks.

Will write some entry recommendations and ideas on the rating system in the up coming days.

Cheers!

last time i have changed research system, now i trying to change crucible crafting

what's new?

added water and temperature bars. Each recipe
now consumes water and can be done only at exact temeratures
for example zirconium(Zr) now consumes 10L of water and optimal temp for it is 40-60°

Hey Everyone,

First thing I have to say before anything, holy hell, I need to step up my Jam naming game. I never seem to find good names for my games.

Now that this is out of the way, let's start this post-mortem.

Solo Jamming

Since I wasn't sure if I would have my entire weekend to do the jam, I decided to avoid leaving others in a pickle if I left. In the end, that was a good move as I had a lot of movement during the weekend.

While my past experience with solo jamming had been poor (couldn't keep going the second day), I was scared I would come out of the jam with an incomplete pile of code that could not be played. But I pulled through. Morning of Day 2 was hard to get into but I found the force to start and everything went without a stop until late into the night.

Game Theme and Mechanics

The aim of my game was to hit on that "mad alchemist, trying to create ressources from scratch" vibe and I think it's easy to see how. Although, as some comments on the game pointed out…

[…] I do feel it turned into a bit of a "try mixing all different combos one by one until I discover something". […]

Lack of time did make me go very simplistic on the recipe system. And that is one of the things I am planning on fixing. In further Jams, I will need to shrink my concept even more when working alone. In retrospect, cutting the "Onion Farming" part and replacing it with a slowly increasing gold would have given me enough time to flesh out the research system or work further on the story of the game as the second part of the comment above mentionned.

[…] Didn't feel like there was a direction for me to go in, or any risk, or real incentive to play.

As another comment pointed out, I did skimp very much on the story in my rush to get a lot of systems in.

[…] Having no tips and just trying to mix counted component is a little harsh.

In the future jams, my focuses will probably be player attraction (through story or tutorial) as well as cutting down on mechanics to make them better.

On Interface Design

[…] Only thing I felt missing is the graphics that you could have added! No Sounds still works! But missing graphics give a emptiness feel. […]

Being alone and not being that good of an artist, I left the game very basic looking. Looking at the game in my editor and fiddling with stuff, I think I understood why it was so weird to some. Removing the cauldron, which I made hastily, looks a lot more natural, especially for any veteran of A Dark Room or similar game.

[…] Perhaps the UI could be improved - I was already getting frustrated at scrolling up and down the list. Maybe I'm not just cut out for alchemy? […]

Another comment I got a lot regarded the Interface and how tedious it became after a while. I have been compiling the comments and will have to do a lot of Quality of Life upgrade before I even accept to present the game HtG will become for another full test. Good thing at least is that the UI upgrades are my main concern at the moment.

From scrolling through an ever-growing list of ressources, to clicking through each and every component of a complex recipe (Pyritic Acid being made of 49 basic elements as one of the commenters pointed out), I have a lot to fix.

Difficulty And Length

…or, in an alternate interpretation, I just spent several hours of my weekend, filling out the blanks in an Excel-sheet listing fictional materials, with 90% of that time being spent on repeating actions I'd already performed multiple times before :-) […]

One of the things I have always been having trouble with (be it video game making, D&D campaigns, etc.) is correctly aligning both pendulum to be centered at the same time. And it seems this time I have let both go far out of sync. As the comment shows, the game can take multiple hours (of repeated actions at this point) to complete, which is far over what you should have in a game jam. I will let another part of the same comment speak as far as difficulty.

[…] Out of these 231 combinations, only 23 are meaningful, i.e. moves the research forward by either discovering a new element, or by winning the game. Also, when an attempt is made, the materials are usually lost. And finally, losing an advanced element means that you have to spend time on rebuilding that element from more basic elements (using processes you have already discovered and followed previously), just to get back to the point where you can continue your research from the point where you left off.

As the game progress and becomes more and more complex, I will be very careful of monitoring both pendulums more accurately. (and a little bird tells me I will most likely need to add some tools in-game for me to analyze some sample playthroughs to understand where the game hitches)

What's Next?

As the game stands right now, I will have two things ahead of me: Improving and Progressing. As such, I will do some progression early but most of the early work will clearly be improvements. Most of those come from the comments I received.

Currently on my shortlist of things to fix:

• Modify the UI to reduce the amount of scrolling through the list.
• Allow for creation of intermediate products easily (to reduce the total amount of clicks to create the ingredients you are currently working on)
• Make recipe results clearer
• Correct the money generation aspect
• Increase the amount of successful recipes (within the currently existing ressources)
• Reduce the price of failure
• Increase recipe hint counts
• Improve the Shop

On the medium to long term list:

• Improve the Story component
• Improve the Recipe System
• Improve the Recipe Book
• Add an In-Game way of tracking your progress
• Work on new features…

after some thinking and experimenting, looks like i found the way to make good, balanced research system for my game.

How will it work

• i will call elements from periodic table "metals" and elements from research game "elements", otherwise whole post will be annoying and hard to understand

Firstly, to do some reaserach you require special metal for each try (it goes on top of couldron)
Then you can add another metal as catalyst (it goes on left side, before step counter), it wil unlock random step even if you don't match anything
Then goes grow-like matching game. You can't use the same element more than 1 time now. Also if you unlock step, you have to follow it, or next researches will not work
After selecting all elements click "research"
When you finish the research it will unlock new recipe for cauldron or some other stuff

short vid about new system
*thanks to @benjamin and @wan for ideas that helped me to make new system. *

(this is a mirror of the article at my website, so forgive the superfluous description of Alakajam!)

Unexpectedly enough, I participated in another rapid gamejam. This time, it was Alakajam! (mind the !), a 48-hour event held over the September 22nd – 24th weekend. I participated in the Solo division and enjoyed the experience thoroughly.

AKJ (the 'official' abbreviation for the event) is a completely new gamejam, this weekend being its first iteration. Some people think of it as a reaction to the terrible management of LD, which is probably not entirely untrue for many participants, including me. But, this is not a post about that, and in any case, AKJ already has a great community and is very interesting in its own right.

Theme

Unlike LD, AKJ is more suited for us, jammers based in European timezone. There was a lot of people eagerly awaiting the theme announcement in the IRC channel. Around 8pm, the theme Space Station was announced with a video. Due to votes in the last hour, the actual theme chosen was Alchemy, however. This was communicated quickly enough, but some people went through with their Space Station games, and then probably submitted in the unranked division.

I was happy with both of the themes, Alchemy was my number one choice, Space Station number two. As the theme voting results reveal, people finally got tired of 'You are the bad guy' and its variation, which LD has seen plenty of.

Initial idea

My initial idea was something along these lines: The player is an alchemist, living alone in a desolate world. However, they can create and mix interesting potions. Using a special looking glass instrument, they can look into their potions and even enter them, finding an entire world inside. Depending on the elements / substances / characteristics of the potion, the world would be different – different terrain, objects, features, people, creatures, etc. (Thinking about it now, this idea seems a bit similar to the linking books in Myst.) The game would then consist of the player entering various worlds and solving problems therein by mixing them with other worlds.

I was aware that this was pretty ambitious for 48 hours, but I wanted to take my game into this direction, even if I did not make it as far. So I started, hoping to waste less time on overthinking my idea. Once again, in gamejams and indie games in general, I find it very important to not be afraid to change directions, even drastically, based on what is fun to develop, what seems feasible, whatever random ideas you find along the way, and so forth.

The journal

Here is the first page of my journal for AKJ:

A lot of it is sketches for page-flipping curves. One of the first things I was actually implementing was the neat page-flipping animation for the (in-game) journal. Here is how it works:

A basic page flip consists of a page moving 180 degrees from the left or the right to the opposite direction. Usually a person would start turning at the corner, creating a curve with an axis not identical to the axis of the book spine. For simplicity, however, I assumed the page is made out of individual 'columns' of pixels – like a bamboo mat. This way, we can model the page flip as a 2D curve animation (if looking at the book from the bottom).
An animation consists of moving the columns along a half-circle – at each point in time (t ∈ [0; 1]), each column (x ∈ [0; 1] radii from the centre), is at a specific angular displacement (a ∈ [0; π]) from its starting point. We can say the angular displacement of any column is a function of its distance from the centre and the time – a(x, t) ∈ [0; π].

A basic assumption to consider – the page will begin flat and will end up flat as well. So, ∀x : a(x, 1) = π.

If the page was completely rigid, as is the case for a normal book cover, it would simply be a solid line tracing the radius of the half circle. In other words, ∀x, t : a(x, t) = t∗π.

Normal pages bend a little bit along the way though. For thinking about this, I imagined 4 points on the page curve (the one seen from the bottom). One quarter of the way along the page, one half, three quarters, and finally the tip of the page. Any points will essentially be interpolated. How do the four points behave? Parts of the page should lag behind, others should go faster than the 'rigid' cover. I imagined the halfway bit to stay exactly on the rigid cover curve, moving at a constant pace from beginning to end: ∀t : a(0.5, t) = t∗π. The point closer to the spine will go faster, points further from the spine should lag behind: ∀t, ∀x < 0.5 : a(x, t) > t∗π and ∀t, ∀x > 0.5 : a(x, t) < t∗π This gives it a nice progression.

To obtain this sort of function, I started with the basic linear one (rigid cover), then added a little bit of a quadratic: I've noticed y = x∗x is almost perfect for the lagging bits on x ∈ [0; 1] – it develops slower, but at x = 1 it catches up to the linear formula. I thought it would be nice to be able to get the same curve with the opposite bias. On a graphing tool I came up with y = (1 − t)∗x + t∗x∗x – with t ∈ [0;1] this is essentially a linear interpolation between the quadratic and the linear formula. Even better – negative values of t produce the opposite trend as expected.

And so, here is the final formula I used:

x ∈ [0; 1] t ∈ [0; 1] a(x, t) = π∗((1−t)∗(x∗2−1)+t∗(x∗2−1)∗2)

And a visual representation of the full animation, with the four points highlighted in red:

Note that the point at the spine would have a curve similar to point 4, except with the opposite trend.

To decide which side of the page has to be rendered, it suffices to know whether the last column drawn was to the left or to the right of the current one. The page shading is a bit more messy, but it is basically calculating an offset in the page colour palette based on the distance between 2π the half-way point and the current angle. I added some Bayer dithering to make it pretty, of course.

The animations led to some minor performance problems towards the very end of the 48 hours – the quest and recipe updates were not added until quite late, and as I was running out of time, I decided to rerender the full 40 frames of a page flip (20 each way) every single time that page changed. All at once! Post-jam I fixed this so the frames are rendered one at a time in the background, or in the worst case, just when they are needed on screen. Some people complained of their browsers messing up a lot and the audio freezing during the lag spikes, so I thought it was an acceptable fix.

Alchemy

Mostly happy with my journal but with little else to show, the first night was here. I started thinking about the gameplay and actual puzzle design. Some basic Wikipedia research led me to the seven planetary metals:

• Lead, dominated by Saturn ♄
• Tin, dominated by Jupiter ♃
• Iron, dominated by Mars ♂
• Gold, dominated by Sol ☉
• Copper, dominated by Venus ♀
• Mercury, (quicksilver) dominated by Mercury ☿
• Silver, dominated by Luna ☽

I thought this was a good place to start. If the seven metals had characteristics (primary, secondary, and tertiary), maybe mixing metals would result in substances with the primary characteristics kept? Maybe some characteristics eliminate one another? So I thought of seven vaguely appropriate characteristics and arranged them with the elements, until each metal had a unique primary characteristic, and each characteristic appeared exactly three times:

• Gold (Sun) – heavy, shiny, slow
• Iron (Mars) – slow, electric, deadly
• Mercury (Mercury) – deadly, soft, heavy
• Lead (Saturn) – soft, slow, heavy
• Tin (Jupiter) – light, shiny, electric
• Copper (Venus) – electric, light, soft
• Silver (Luna) – shiny, deadly, light

Clearly not all of them made sense, but this was alchemy in a jam game, so I was happy with this. To make the inconsistencies less obvious, I gave the characteristics pseudolatin codenames, and made a symbol for each (see previous journal page). I arranged them in a heptagram {7/3}, each characteristic having two vaguely-fitting opposites. Various tools / methods could then 'bring out' a characteristic (by removing its two opposites).
I also gave up on the idea of potions – substances with characteristics seemed a bit easier, since I was happy to draw pretty icons for items, not so much trying to make potions / flasks look unique enough depending on their elements. With this, I worked out a list of steps the player would have to follow to ultimately obtain the Philosopher's Stone, starting with just a couple of substances. Finding pure (containing a single characteristic only) substances would allow the player to fix tools, usually the tool two steps down on the heptagram.

The list was somewhat tedious to create, since I was worried that players could skip steps by using the right tools. At 08:00 in the morning, I was mostly happy with the steps, had the items (20 at the time) all drawn, and decided it was time to get some sleep!

I slept for 3 hours …

All fresh and full of energy (ugh), I started my second day.

I sketched a hub world in my journal with various features, then started recreating it in pixels. Happy as I was with how it looked, I realised it will take some work to make it work – pathfinding, objects in front of the player, interactive objects, and so forth.

Somewhat unhappy that I did not have a better (custom) tool for this, I resorted to having a number of layers in Photoshop: the graphics, the walkmap, the interaction map, the overlay map.

The graphics layer is self-explanatory, I hope. It may be worth mentioning that at this time my palette was finalised, with 19 colours total – most for the journal shading. I reused them for the terrain, and that seemed to work.

The walkmap layer was mostly transparent, except for single coloured pixels at places where the player can stand. I differentiated three basic colours – green for 'normal', yellow for 'transition', and orange for 'behind'. Whenever the player is standing on one of the latter two, the overlay map is rendered. This was a surprisingly painless way to give a 3D aspect to the map. For finding out which walkmap node is connected to which, it was enough to ensure that their distance was below a certain threshold (roughly 17 pixels, with some scaling of x axis). Green nodes cannot connect to orange ones. And finally, A* to find paths. Yet again, surprisingly painless. Some pixels had colours like 0xFF111111 (a very dark gray), 0xFF222222, etc – these serves as markers, their true type was hardcoded. Very ugly, but it worked and allowed me to refer to certain places in the map by a number.

The interaction map was the least elegant solution. There are pure black areas over objects the player can interact with. To identify them in code, I placed a marker pixel somewhere inside the area, and to the bottom and right of it a pattern, usually of 'letters'. In code I duplicated these patterns manually and this is how objects were paired with their scripted interactions.

The desk was mostly the same, except that various objects had to be separable from the graphic, because they had multiple states (i.e. the magnet could be broken or fixed). In the interaction map I placed markers with a pattern at the top-left of the object bounding boxes. The same pattern was then somewhere else in the bitmap (not visible), followed by the sprites for that particular object.

In the future I would very much like to be able to create 'tagged' image files (maybe using PNG metadata?) without having to do all of this during the jam. This would help tremendously when creating GUIs, frame-by-frame animations, tilesets, spritesheets, etc – I will see about integrating it into plustd.

The second night started and I was putting the alchemist's desk / workspace together for a lot of it. I made the crank work. Making the tip of the crank follow the mouse with some momentum was not happening easily with the amount of energy I had (none).

For anyone interested, the angle between the center of the crank and the mouse is calculated using atan2(crank.y − mouse.y, crank.x − mouse.x). This 'target' angle, as well as the current angle of the crank are normalised to [0; 2π]. If the difference between the target angle and the current angle is more than π (180 degrees), we need to turn in the opposite direction.

Final day

After the crank, it was the morning of the third and final day. I was drawing the Looking Glass (the blue device you see on screen when warping). At some point I realised I was not fully aware of what I was drawing – the device ended up looking weird enough for it, so I cannot complain. Morning is always the critical point for me when doing any long stretch of work without sleep. But, seeing as AKJ was ending in about 12 hours, I decided to keep going. In a previous LD, this has not been a good decision, but this time it worked out somehow.

I was also entering panic mode. I had the hub world and the desk, but I had not tested any of the puzzle progression, there was no story to speak of, I wanted to have multiple worlds to warp into, I needed an ending, more music (I have played the piano and transcribed a melody or two into the game at some point), and so on …

So I tried to make it quick – neither the Mars nor the Luna worlds are big, and the Mercury 'world' is … not really a world. I put all the important plot exposition in the final dialogue of the game, but oh well. I had a game that was playable from beginning to end. During the submission hour I packaged the game, added a simple title card, and waited until the AKJ website wasn't crashing due to people submitting all at once.

Conclusion

And … that was it! I made a game. Post-jam I added some prettified instructions to the submission page about the characteristics and the heptagram. It was overall a very satisfying experience for me, despite all the flaws in the game that I am aware of, some of which are:

• The alchemy mechanics are not super clear and the journal provides little to no assistance. A lot of it is too trial and errory.
• There are no sounds.
• The ending looks pretty (I think), but it is still quite lazy in its execution.
• There is a lack of good user feedback – sounds, visual cues (e.g. that a machine just did something), items (e.g. the funghi in Mars world are hard to find), slow journal …
• And much more!

I must say this jam was well organised, and its website a pleasure to use compared to LD. The next iteration is scheduled for February, looking forward to that! Thank you for reading, and I hope you found at least a little bit of this interesting!

Food log