You can play it now online: A Strange Package
It took a while but I was able to finish it, finally. Definitely a lot more work than I thought at first.
The result is a short but fun visual novel, with multiple choices and three different ending to get. I have mainly worked on the graphical aspect, polishing up the animations and graphics, but I also added more music tracks, a lot more dialogue and, most importantly, I did a lot of coding.
This last part is important because I am going to release, under the welcoming MIT License, the engine that runs the whole visual novel. It will take a few days, so you may want to follow me on twitter for updates (it is in my profile), if you are interested. Now, this may raise the question, why do something like this when I could have just used something that already existed, like for example the magnificent RenPy visual novel engine?
(I know that releasing such a small game more than a month later than when I started it may raise a few eyebrows as to the speed of development in this engine… Well, in fact the problem is that I had a few personal life problems that ate a lot of my time during this period. The engine was very benign under this aspect, by not having any major bugs and allowing for a fluidiy in development that warms my heart.)
I do not want to make this whole post about the engine so I just want to say: if you have a few spare minutes for a fun story, please play A Strange Package. It would mean the world to me.
I want to thank everyone that gave me feedback on the game because that helped make the final version much better. And of course I want to thank the Alakajam organizers for this beautiful event. I am very pleased to have been part of this jam, and you can count on my presence for the next jams. Until then, bye!
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. ;)
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!
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.
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.
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!
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:
Three puzzles in the top 5, what has befallen me?
Considerably lower averate score for team entries this time. There were only 15 of them, which might explain it.
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:
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.
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
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.
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.)
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. ;-)
Should have written this a few days ago, but I simply forgot.
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.
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.
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.
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
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.
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.
last time i have changed research system, now i trying to change crucible crafting
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°