For my Kajam entry, I have decided to go with a top-down, twin-stick shooter. That should give me plenty of opportunities for finetuning the game feel and juicing up the action!

For my last MiniLD entry I tried the exercise of making a whole game design document before coding the game. Even if the actual game was quite small, it was fun writing the doc, and I think it helped keep the development focused and the end result consistent.

I won't do a full GDD this time but still, here's my notes on the upcoming entry:

Design notes

Theme/Art style

• Game set in a strange, futuristic place that feels like a maze made out of hundreds of similar rooms arranged as a grid, with straight corridors in-between them.
• Top-down view with either a pixel-art style (like Hotline Miami except simpler), or a smoother look with simplistic art like Prison Architect. In both cases it will be simple and in full 2D.
• Setting & atmosphere largely inspired by the Cube movie

Gameplay loop

1. Enter a room.
2. The room locks up and something happens randomly: you get loot, or robot enemies appear. Maybe both. Maybe nothing.
3. Kill the enemies until there is none.
4. The room unlocks.
5. (Optional) You see a clue about where the exit of the maze is.
6. You pick one of the 4 directions, enter a corridor to the next room.
7. Repeat.

The goal is to survive while finding the exit. I have a cool idea in mind for the ending, but I don't know if I'll have the time to implement it… If not I'll just make the difficulty ramp up until the player dies :)

Loot

• 1st room after the one you spawn in will always let you find a weapon dropped by a dead robot
• Health
• Maybe ammo (if so I should give the player a way to attack if out of ammo, e.g. by throwing his weapon)
• Maybe a 2nd weapon to have one in each hand
• Maybe maybe, some bonuses to improve the weapon

The problem

The jam was good, but the rating system left me cold. I have a total of three issues with it; let's see if you can spot them.

10
9
8
7
6
5
4
3
2
1

It is obvious right? Ok, I'll give you the first one for free: there are no descriptive words to go with the numbers. Let's fix that.

10 The best ever
9 Amazing
8 Great
7 Good
6 Above average
5 Below average
4 Bad
3 Terrible
2 Abysmal
1 The worst ever

Better. Now everyone has similar expectations of each grade, more so than before. Do keep in mind this is just an example, there are other fitting descriptions and they could even change based on each category.

Second problem? There is no average! In a big jam there are a whole lot of average entries, so-so stuff. With this rating system I'll have to score them slightly better or slightly worse every time. How annoying.

The last problem is more personal than the prior two. In my opinion a scale of 10 has too much granularity. What is the difference between Amazing and Great? How about Terrible and Abysmal? It is not clear and as such we can expect different people to use these grades in fuzzy ways, which muddles the results. In the best case scenario the grade should reflect the (hopefully written) opinions of each reviewer exactly, not close enough.

Suggestions

In light of the prior explanations some propositions are in order. The first one is obvious, simply introduce descriptive words and an average grade to the current system. I'd be fine with that. Next, two more ideas.

7-grade, zero centered model

+3 Amazing
+2 Good
+1 Above average
0 Average
-1 Below average
-2 Bad
-3 Terrible

The old 5-grade model

5 Amazing
4 Good
3 Average
2 Bad
1 Terrible

Conclusions

I rate the rating system 2 out of 5, bad.

Cheers

I'm working out the pixel art style for my entry right now. I have a pretty basic tileset already. ^-^

I don't want to flood the front page, so I'll just keep editing this post for now. I managed to get some free time to finish up the tileset. It looks a bit sloppy, but the level design should make it look a bit cleaner.

I have only ever done jams and compos that last for 48 - 72 hours. But I'm really loving the way Alakajam is coming along, so I figure I shoud give this month-long jam thing a try.

Usually I'm coding like crazy during a jam to make the game as feature-packed as possible. Unfortunately that often results in a buggy mess. So this time I'm trying to focus on delivering a polished experience.

This is how shiny my puzzle will be

The game won't be super innovative or complex but the menus will make you weep for joy! So, without further ado, here's my plan for the 1st Kajam:

Plan

I'm going to make a puzzle game because it's what I'm most comfortable with.

First week

• Make it playable
• Create at least five levels

Second Week

• Force a friend to play-test
• Implement suggestions / features from their feedback

Third week

• Create more levels
• Write music
• Create sound effects

Fourth week

• Polish the UI / user experience like crazy
• Create more levels if there's time

Fifth week

• Test rigorously and fix bugs
• Polish the music & sfx
• Create more levels if there's time

Congrats to all who participated the 1st Alakajam!

So I got a lot of feedbacks concerning the super difficult and unfriendly mechanics of WuXing Rush. The gameplay rating of the game is not good as well. Therefore I took like a week to re-design the whole mechanics, trying to make the game easy to learn but still challenging, and worked out a few new mechanics for testing.

In the GIF above you can see I repainted the main character and his animations. It now takes only one element (or essence as I prefer) as the 'core essence' for certain potion. There are up to 2 enhancers can be used for a single potion, in order to activate additional enhancements. Different essences work differently as enhancers with each core essence, and some essences are exclusive from others. In general, it becomes easier to decide what essence to choose, and you don't have to choose 3 ingredients before tossing a potion.

Another improvement inspired by @HuvaaKoodia is that the tree bridge now finds its own growing path. So the timing of using a tree bridge potion becomes less essential. I'm also considering to make the tree bridge more flexible (like not only to climb but also to cross water area) and more useful (like you can regenerate HP by walking on it). I'm glad there are just so many possibilities.

Hopefully someone interests in this developing game and I'll post updates whenever there is noticeable progress. ;)
Cheers!

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