This includes an important tweak I made over 2 years ago to support “intermediate” serialization data, i.e. stuff you need to put into objects in anticipation of their deserialization but don’t want to keep in memory afterward.
I still gotta write a good, up-to-date tutorial for circular, but it’s been indispensable for all my games.
Ananias, Emerald Woods and OpenArthurianX6 use it. You may find it useful to aid you in serializing and deserializing your game data!
I managed to participate in the competition for the sixth time in a row, this year I went mostly on my own, as my fellow game-jammers friends were busier than me.
However mapedorr participated in spirit as his graphics ended up being used, and Ryan Malm contributed with awesome music and SFXs.
We ended up creating a cute dying virtual pet arcade game. You can play online here. Source code is here. There’s a gameplay video here.
Remembrance of the first day, August 13
The theme for this year’s js13k is DEATH. I talked briefly with my pal QuietGecko, but we didn’t have an idea of what to do. Throughout the day I was thinking about possible ideas, trying to avoid the endless loop of “Must think of a cool idea that is not too pretentious” -> “somebody surely thought of this already”. In the end, I thought I had something that clicked with the theme and also tied back to my original ideas.
Remember how the original Tamagotchi could DIE if you didn’t take good care of them? My idea was to take the format of the classic virtual pets, but transform it into a fast-paced arcade game where you must prevent its death; imagine time is running at 30x, and you have to respond to the needs of the pet quickly or risk him getting sick and dying.
The main interaction I planned to include was to pick what to feed the pet with, based on four available and shifting options where some of these may increase its happiness but reduce health, and some others may stuff the pet a lot so you should only use them when the pet’s hunger is empty or it will lose health. The food, happiness, and health bars would decrease steadily, and faster as the pet aged.
I also thought I would add some minigames you had to play with your pet when it reached certain life thresholds.
Following up with last year’s Distant Friends, the idea was to keep the visual style: cute characters using vector graphics. However, I would add a bit more in the shape of some nice-looking animations (with a super low, jumpy frame rate).
Day 2 – August 22
Many days passed since that first day, I was super busy getting stuff done to travel to Cologne to Gamescom. So no work was done all along.
But then I decided to revive the yearly tradition of working in my js13k while flying, so there we go! this time it was a longer flight so that meant more dev time.
In this first coding session, I managed to create a complete game with a simple gameplay cycle. I reused my entry from last year, chopping everything I didn’t need, and created a simple game where you had to keep your pet alive by feeding it when it was hungry, with the caveat that they were doomed to die since it was impossible to hit the precise millisecond of time to prevent its health to degrade slightly due to hunger.
Also, the pet would poop, and if you don’t clean quick enough? DEATH. Death was to be so common that I added a ranking keeping track of your best effort to avoid it, but it’s inevitable.
However, you would also get to see LIFE, as the pets evolved from an egg to a full-grown creatures. It’s the balance of life and death.
When I went hands-on to remove stuff from my 2021 entry, I figured out that, in the end, I only reused some rendering code because the game was extremely different.
The plan was to focus on polishing from day 3, adding animations and cute art.
Days 3-4 – Around September 1
Gamescom was super busy and of course, I had to make the best of my time there, so I only managed to go back to developing the game during my flights back home. Due to timezones stuff and general trip craziness let’s count this as two “days” of dev.
At this point, I decided to regroup my ideas and draft them again in paper now that I had done a first dive into the code. I discarded the initial ideas of having multiple types of food and playing minigames with the pet, and instead focused on the frantic rhythm mechanic. I planned to add some additional distractions in the shape of items you had to pick, which would also give some variety to the gameplay.
I also considered changing the representation of the pet from vectorial to LCD-like, but ditched that in the end since it would have been a LOT of work and in general I think it was not needed, as the idea behind the Tamagotchi was that the virtual pet was inside the screen; the LCD matrix was just a charming byproduct of the technical limitations. (Actually, I was just lazy to remake that part and I wanted to reuse the art I already had from Mateo Robayo).
The paper drafts were also useful to get an idea of how I wanted the game to look like; since I wanted to make this for Gaby (well, at least a variant of it with much less DEATH), I searched the Internet for Pink Fong toys and found this one.
I toyed around with GIMP a little bit and came up with a mockup of how I wanted the game to look like. I wanted it to _feel_ like a plastic toy, with some feeling for physical buttons you would virtually press on the toy. Sadly, since I did this all on my own it ended up completely flat, so that one part was missed.
I went ahead into hardcore coding mode with these two things in mind, and managed to advance a lot into what looked very close to a finished entry now.
Day 5 – September 8
Ryan Malm, a fellow js13k comrade, popped up in slack offering to contribute to some entries with music, how could I refuse such an offer? he’s already created awesome stuff for 2 of my entries in the past! (ArcherFire Duet of Aces and Backpack Monsters).
However, there was a problem: Ryan uses soundbox, while the engine I had working used zzfxm. So I had to migrate all the sound support which was a bit fiddly.
I managed to do this, incorporate Ryan’s initial tracks, and program the “soft” buttons that would be used for the mobile version (at least that was the plan…)
Day 6 – September 9
This was kind of the last big push day; some of the things I did included:
Updated the “conversations” that would serve as an onboarding for the players
Added animations for the pet (low framerate, bopping up and down, blinking with its eyes)
Added unicode “hats” worn by the pet as it grows, to make it more visually appealing and make the players feel curious as to what the next evolution step would look like.
Also added the “animation” of the food flying toward the pet (very important for the player experience) since initially it just displayed the latest food given to the pet but it was very abstract.
I also put up and announced a public version for people to help me test. That was useful to discover a bug on Safari with the audio which was solved by not reusing audio objects (unneeded, harmful optimization), thanks to Ryan for pointing this out too! I also got some accessibility feedback leading to increasing the size of the “LEDs”, improving the mobile UI, and balancing the game to make the difficulty increase as you progress.
Since Ryan had some spare bandwidth, I asked him to produce an extended version of the main track, which he did ❤
Finally, I implemented web monetization features in the shape of a “hard” mode where you had a completely different pet (a gecko, also reusing graphics from last year).
The game was completed, and I felt happy about it.
Day 7 – September 10
Oh, one last thing before we call it a day…
Gaby caught me playtesting the game and went super sad when the pets died, what a shame! this is not what I wanted for a birthday gift for her!
So I went ahead and complemented the web monetization bonuses with a “chill” mode where the pet didn’t die. You just play for fun seeing it grow (at a slower pace to at least add some padding to get the rewards). That worked both to increase the value of the webmon bonus, and to make the client happy!
The Voting – What did the players think?
This year js13k had a brand new voting platform with a more traditional format (just pick a game from the list, play and rate it, compared to previous year’s 1 vs 1 “deathmatch” mode)
Here’s a summary of the feedback we received:
– The Music – The Art – The web monetization implementation
– Lack of keyboard commands – The game is too hard – The “pause” breaks the game flow.
The music and art were cool, of course 🙂 I think you’ll always need this for a successful entry. Competition is more fierce every year. It also helped that my game was SUPER SIMPLE; that allowed having good visuals without a lot of work, you got to be realistic about what you can achieve based on how much time you want to devote.
For the music make sure to partner with someone good like Ryan Malm or QuietGecko. These bytes will be extra worth it!
I was also happy to get some good comments about web monetization, since I really worked towards checking all the boxes, and it seems I succeeded in that. Keep these tips in mind!
[…] Let’s talk about the Coil bonus – the implementation in my opinion is just perfect. You’ve taken care about both – Subscribers and Non-Subscribers. You’re showing the bonuses in a visible way, you’re informing what they are, how they’re impacting the game, what to do to get them – perfect. I also like the idea of the bonuses – I can decide either I want to play easy or hard mode. Although the game wasn’t easy for me to understand right away (maybe you can think about some kind of a tutorial mode?), the Coil bonus is somethin I would call as a perfect implementation. Good job.
Ewa Mazur, expert.
Now let’s talk about the BAD.
And the biggest issue was the lack of keyboard commands, and again I think my biggest mistake: Increasing the difficulty of the game via inaccessibility. I think that’s in general a bad idea unless you are targeting a very specific group. Support for keyboard commands is actually included in the game, I just disabled it because I thought the game would be more challenging in desktop using the mouse and *I* could perfectly play it.
This issue, of course, is non-existing in mobile (the platform for which the touchable buttons were initially conceived). Keeping a different way to interact based on the available input would have been a much better choice, and finding a different way to balance difficulty in case it was needed (or just leaving it like that, with the desktop version being _easier_ than mobile, but still enjoyable!)
October 5 – The Awards Ceremony
We didn’t win, of course.
There are a lot of talented people putting a lot of passion into the js13k every year, and also putting down a lot of raw WORK.
Since the jam is 30 days long, there’s a very broad spectrum of entries with a different quantity of work invested. In my case it was 7 days; this could perfectly have been a 7DRL or similar. With many other things going on it’s impossible to devote a full month to this, but that doesn’t mean you shouldn’t participate.
There is a lot of fun to be had in the challenge, and as long as YOU are happy with the results, and you learned something or made some new dev friends or managed to extend your portfolio with a finished playable game, I believe that should be your main metric of success.
I also warn about this because the scoring system is not perfect, and you may end up disappointed that the game you put so much work on wasn’t “fairly” assessed. In the end, the main point of it is giving you feedback to improve.
This year we were placed #68 overall, #35 and mobile, and #19 in web monetization. I hope the TShirt isn’t stuck in customs this time! 🙂
I managed to participate in the competition for the fifth time in a row, this year I teamed up with fellow game jammers and friends: mapedorr and QuietGecko, as agar3s went lone-wolf with his entry for the decentralized category.
We ended up creating a cute space exploration arcade game. You can play online here. Source code is here. There’s a gameplay video here.
My main inspiration, in the end, was “Tokyo 2020 Google Doodle Champion Island Games”, a fun little game made by a company called “Google” for this year’s Olympics. I wanted to recreate its feeling of relaxed quest-completing gameplay with challenging minigames.
I wanted to do something simple this year, but I also wanted to start as quick as possible so that there was something we could polish along the way instead of rushing it thru the end.
When the theme was announced I immediately thought of the idea of a space exploration sim; however I also thought it would be a common approach, given how easy it might be to exploit procedural generation to create infinitely expanding, boring universes with thousands of planets. I decided instead to have a more focused world, with unique planets, characters and quests, using procgen only for non-critical content (such as the stars in the background, and the random asteroid fields). Everything else was to be made manually, quest types would be sparsely reused, and tied to a hand-written story line.
The theme of cute visuals and audio was also something I thought from the start, maybe I just wanted to make a cute game for my daughter, or I thought the visuals could be easily adapted to vector illustrations without yielding quality, and the nature of the sound tools we could use for the jam worked very well for the type of audio that would support these visuals.
What Went Right
We ended up with a solid, finished entry with nice visuals and audio, and hopefully a fun and challenging experience with some interesting story moments.
What Went Wrong
While I still haven’t received feedback from the community, I don’t think anything went particularly wrong.
One thing I really wish I have had the time (and the bytes) to implement, was the additional game mode focused in building your home in a lonely planed, spaced away from civilization. The idea was for it to be the game mode you would unlock for the web monetization category. Maybe I should have implemented the roots of it along with the core gameplay, so that it wasn’t left out in the end (but then maybe that would have prevented me from filling the core content first, since we did run out of SPACE in the end).
The mobile controls could also be improved with more iteration on it, so that the players could shut down the engine more easily while turning the ship at the same time.
The theme for this year was SPACE. I had an initial idea on my head of making a simple educational simulator, with a cute children theme, showing a journey from Earth to Moon of a multistage rocket.
I decided to use my entry from 2018 as a starting point, and started fiddling around with some “lander” physics and a simple camera that could go back and forth (Duet of Aces was forward only).
I changed my mind about trying to make it physics based. Went in a more “arcade” route by removing gravity and also implemented open movement in all directions. Did some work in the rockets so they exploded after some time instead of only upon impact, as I thought the player would have to make his way thru asteroid fields and aliens in the open space by timing the rocket explosions.
The idea now was for the player to travel to the planets to find the fragments of the song, (a multi-track song in the background would only play the tracks for the instruments you had found already).
To make this possible for the player, I added the navigation pointer at the bottom, and allowed switching waypoints.
As QuietGecko jumped on board, I also set up ZZSFXR, since there was music and sounds to be added.
The plan was to populate the empty space with aliens and asteroid fields. But aliens should behave more like animals than enemies, you had to push them away.
I also increased the resolution of the game to cover all the window (but this was eventually kind of rolled back.)
I managed to integrate some test music and sound effects, including troubleshooting an issue with the ZZFXM web tracker exporter.
I improved vector objects rendering, replacing my own path rendering functions from 2018 into using Path2D directly, which was a great step to allow more complex quadratic / bezier paths, as well as save a big chunk of code. I also did some foundations for the conversation system and drew some “test” objects (spoiler: some of them stood until the very end).
I used MiniSVGcreator by xem, it was great to produce optimized SVG paths (although by this point its usefulness was limited by its inability to save/load)
Decided that the game would be about finding your missing friends instead of completing a song, and made a basic structure for this questline (hoping from planet to planet looking for them)
Also added asteroid fields serving as obstacle for your planet-hoping journey.
For the visuals, I added a parallax effect with cute stars and reused the pseudo 3d effect when turning from Duet of Aces. QuietGecko continued working in the audio.
Sent a small patch to xem’s MiniSVGCreator to allow loading SVG data (to improve the art workflow), also added new music tracks from the gecko, and worked on the plotline to have an idea of how much text I’d be able to fit.
I had to travel to fetch some hardware, but managed to do some airplane coding implementing conversations with multiple fragments, word wrap for text, and a lot of writing for the dialogs and plot (measuring how much is viable to add inside the limits, because text taxes you HEAVILY in js13k!).
Added rocket particle effects, hints to friend locations, and city labels. Also integrated more test conversations.
So far I had a huge JS file with all on it, so I decided to split it into modules and modify the gulpfiles to merge them at build time.
Asteroid mining with minirockets. Character portraits composition with test cat, dog, and fox.
Integrated new SFX by the gecko and added mobile controls and scaling.
Worked on quests (for mining and space racing) and speed booster powerups. The idea was that you would have to complete some quests to get hints to your friends’ locations.
Implemented the “time trial” quest, including improving the obstacles track, and adding boosters to it.
Also worked further in the mobile controls, and added scoring to the game, based on how long it took you to complete it.
Focused on a better user experience, by improving space navigation tying it to the current known location of friends instead of all the planets in the universe, as well as adding some onboarding and hints
Mapedorr jumped into the game designing some nice portraits, I did an initial test integration for them.
Day 15 and 16
Implemented space fishing and Galaxian fishing quest.
Days 17 and 18
As the end drew near, I called for friends to help test and did a lot of small fixes and tweaks in the mining and fishing, and also improved responsiveness for mobile.
We were already over the 13KB limit, so had to call for help on the js13k slack. I was pointed to ECT which was a last-minute life-saver.
Another year another 7DRL. With 17 years into it, Mr. Jeff Lait (the only other human developer to have participated in all of the challenges) has pointed out to me that I have been participating in the 7DRL Challenge for over half of my life now. Cool.
Following is a summary of the journey, which I detailed in daily posts in the new 7DRL Challenge Community blog (which sadly went underutilized due to underpromotion and the preeminence of other channels such as Reddit, Discord, and the boards at Itch). 1, 2, 3, 4, 5, 6, and 7.
This year was weird. I had pretty solid plans about 3 weeks in advance. Wanted to make the most out of it for the development of the ExpeditionX engine, exploit a lot of unused assets we created but are now not that useful anymore for NovaMundi, and build the foundations of a potential future commercial game (because who can afford to WASTE 7 days of development these times! :P)
All that went to the trash can when I recalled 7DRLs must be Free in spirit (and in the past, some people have tried to exploit the challenge commercially, with ugly results), and producing a free game reusing NovaMundi’s underlying engine might affect its upcoming Early Access release. Also, it was looking kinda scary from the scope point of view.
So, I began randomly exploring what to do. During the first two days of the 9 days time window of the challenge, I tried to come up with something that would be doable, interesting, and fun to work on. I toyed around with creating a spectator-sport, a battle arena with AI enemies using roguenet‘s infrastructure, where players could follow the development of gladiatorial leagues, and witness grand events. I was about to go for it but again decided to scrap it due to scope. I’m thinking on maybe doing this for procjam this year.
Then, I thought about doing something similar to my last year’s, Emerald Woods, which was more of an experience backed by the power of ASCII Unicode (and awesome sound effects). For this one I thought I would recreate the feeling of being alone, we all want to be alone sometimes and play some games. I don’t play games anymore.
After all the stress of trying to set a course for the project, I decided to chill out and just see where it would take me. I worked on setting the theme for the game, which kind of held until the end. You start at your home, and it’s raining. You can use your computer to play games, or connect to roguenet, or watch random videos in your room (adapted from the 7DRL theme generator words bank and idea by Evgenii Petrov). Sadly I didn’t manage to allow the player to brew coffee (dammit, that would have been a cool 2 minutes addition).
I also set myself on the visuals. I decided to use a strict ASCII 80×25 monochrome mode, similar to what I did for Rogue Program, including using an IBM VGA look-alike font with a green color emulating P1 phosphor from early monochrome monitors. The reasons for this were I think it looked pretty cool in Rogue Program, taking me back to the first games I played, and I also thought it would give the game a distinct visual style, and would allow me to fully exploit the possibilities of ASCII to represent full-blown environments using the power of imagination.
Then I started thinking, what is the actual game that the player’s character is going to be able to play from within the game? the first idea that crossed my mind was doing SpelunkyRL, an idea I shared with Derek Yu when I met him in San Francisco in 2017. What if Spelunky was a REAL roguelike? (wink-wink) I recall he told me he didn’t think it would work (he’s most probably right).
Alongside, I started toying with the idea of a somewhat “surreal” experience, where the game and the real-life would mix, and you would no longer know what was reality. The idea was you would wound up back at home from within the game, kind of like a parallel dimension or a dark/flip side. That part didn’t hold until the end, since I figured it would require a lot of design to make it feel right, and it would spike the scope of the 7DRL again.
I managed to advance a bit in SpelunkyRL, even doing an initial version of a level generator based on Spelunky’s legendarily simple 4×4 generator but adapted to a top-down perspective. For some reason, it didn’t click on me… again feeling that 7 days was not enough to do it justice (maybe it’s the zillion of previous half-baked attempts at stuff have finally helped a bit).
So, I found myself against without a direction. I taped again at my head for stuff I had done for previous years which was cool but for some reason didn’t end up fun. I decided to integrate and adapt the Stygian Abyss level generator (tweaking it for the fixed screen 80×22 levels and the monochrome visuals of the game). One of the big things I missed from our Stygian Abyss 2015 7DRL entry was an auto-map or better means to prevent people from getting lost; the combination of the overhead view and the fixed-screen levels seems to work great for that (perhaps centering a game around the notion of how easy it is to get lost isn’t that much of a good idea after all).
Following up on the idea of reusing cool stuff that didn’t work out very well, I decided to do add a hand-crafted overworld, linking the main dungeon and 2 caves initially, and then use the “Epic Quest” generator from Heroes of Noresskia (my not-very-exciting entry for 2019’s challenge). My rationale was that it didn’t work in 2019 because the journey between the points in the map was super dull, the combat system was bare and broken, and the interaction at the actual places on the map was minimal. So maybe if I addressed these 3 things I could put it into proper use.
In the end, I dropped the idea mainly because… maybe the “Epic Quest” generator wasn’t really that good for starters? I think we are still a long way from generating interesting plot-lines, and any efforts to do it will ultimately suffer from the “cheap content” curse and be undervalued by players. I decided to instead go for a more straightforward and fixed plot. However, I retained the idea of a fixed overworld, grabbing inspiration from classic ADoM’s Drakalor Chain (but it’s a valley, similar to my hometown’s).
I had another crisis of thinking about what innovation, if any, I was bringing to the genre. What was going to set this entry apart from others and bring something new (even if tiny) to the genre? so far it was heading to just being a traditional roguelike with a fancy monochrome display (which is probably hardly an innovation as that’s how these games were played in the early ’80s?).
Reading a bit on it, I remembered one way to approach innovation is just by mixing different ideas, at least as a starting point. Just what I did (with half-baked implementations) for my first 7DRLs I guess.
At first, I thought I could create a roguelike with strong western RPG elements, like, taking ADOM and stretching it to an Ultima VI level of (hand-made) character and quests design, with its own lore and towns with a unique flavor. At the very least, I could come up with a system of virtues/values, 3 or 4, each one with its town and dungeon, basically an Ultima IV Roguelike. (By the way, I need to check the U4 Randomizer sometime soon). I played a bit of Jeff Lait’s Malachite Dreams, which I always had on my mind was like an Ultima Roguelike at least for the exploration aspects, and found it a bit empty so plenty of possibilities to extend on the idea. BEEP! too ambitious! another idea discarded.
Again, I found myself in the void, one of these un-fun 7DRL Challenge moments. I had a generator creating pretty good-looking cavernous complexes and a working overworld, but what should I populate it with? Damn. That part of the 7DRL where you have to actually create content.
I thought I could instead grab and build upon the setting of Ananias… but that brought the issue of it being a lot of work for little return (the question of making the world of Ananias more interesting is big enough, something I should tackle afterward).
Then I wondered, what games have I been playing lately that I could use as a source of inspiration? luckily, my list is short with just two games I played seriously in 2020: Horizon Chase Turbo and the Final Fantasy VII Remake. I remembered I actually had the idea for 2020’s challenge to create a game based on the then upcoming Final Fantasy VII Remake, thinking about riding the wave of increased interest. (Actually, in 2020 there was an entry based on FF7, but it was mostly focused on the combat, not the setting).
This was super compatible with what I had so far, so I decided to go with it. Yay, a clear direction again.
For gameplay, I took a lot of inspiration from my memories of early DoomRL for ranged combat and mixed it with my own melee-focused skills from Rodney, which were inherited from DrashRL and also permeated the design of some of the classes of Ananias. Again, I think these were good ideas that weren’t fully exploited because of the limitations of their map generators and generic themes. I also brought in the enemy AI from OpenArthurianX6 for ranged combat mainly, as well as its pathfinding implementation.
By day 5, it was about time to start working on the content, so I jumped into defining the locations and enemies that would be found, as well as their stats and behavior. I repurposed the theme of the level generator and placed four “reactors” in this world that you got to pay a visit to, then reach their bottom, place a bomb, and return to the surface, to save the world from devastation.
I also invested some time to make sure the ranged attack animations worked fine, since I believe this is a very important aspect for any roguelike with ranged combat.
Through the week, I had kept QuietGecko up to date with all the crazy stuff that was going on, and he could set apart some time to work in the game during the final days (when things were luckily pretty stable in regards to theme and gameplay).
I reached the final day with a semi-working game, glad to at least had invested quite a bit in advance in content generation, but with a lot of tweaking to do.
The first thing I tackled was making sure there was some kind of progression both in the difficulty of the levels but also in the development of the player character. This including moving a lot of the monster stats and doing some playtesting to see how it felt, and also incorporating a lot more skills from Rodney that the player could acquire by using “Wallemite Chambers” found within the levels.
The “active” melee skills I included were: Charge, Assault, Corner, Counter, and Rage. These demanded a lot of work to integrate them from the old Rodney code (which is actually the basis for JSRL but is super outdated now). Then I also had the “stats upgrade” skills for HP, Attack, Sight Range, and Carry capacity; each one required refactoring stuff at some level in the combat code or the UI.
Another important thing I added was populating the items in the levels. For 2019’s Heroes of Noresskia, I completely forgot about healing! so it was probably impossible to win. In the end, I went a bit overboard with this, adding too many healing items. I also added another facet of inventory management with ammunition for ranged attacks, so you had to balance your inventory between healing items and ammo.
About 30 minutes before the deadline, I got a pack of sound effects and music from QuietGecko. I hesitated on integrating them since I still had to work a bit in the balance of the game, but in the end, decided they were important enough to set the mood of the game. I managed to integrate just one of the three tracks he provided (the one for the Wallemite Reactors), as well as a single SFX for walking, and the plasma shots for ranged attacks. Here’s the Reactor track, with obvious influences from FF7 (but we DID want people to get the references, since that would greatly help to establish the theme).
The final 5 minutes were me frantically trying to address the balancing issues because the game was still too hard! so I nerfed enemies to 25% of their power, and buffed the healing items to 200%. A lot of testing is still required but at least it proved to be enough to make it playable.
And that’s the story so far! I probably say this every year, but I’m happy with the results, and I believe this has potential. Possible small tasks ahead (beside fixing a couple critical things like using items not taking a turn) would be to balance the stats a little bit, some QoL improvements for the UX, and maybe also the audio experience while keeping about the current amount of content in terms of enemies and items.
I managed to participate in the competition for the fourth time in a row, this year I teamed up with an elite team of game jammers and friends: agar3s, mapedorr and QuietGecko. We ended up creating a robot dancing game. You can play online here. Source code is here. There’s also a gameplay video.
This year I had two goals in mind: First off, I wanted to do something using a palette based sprite renderer, so that I could create a visually rich game under the size limit. The basic idea is, instead of drawing image files directly, have image data encoded to a more optimal (and lightweight) format and then using that data to manipulate what is displayed in the end (more details below).
The other thing I had clear was I was not going to jump on it alone; I had been talking with agar3s the months prior to the competition, entertaining the idea of joining forces for this year. Once the compo had begun we started brainstorming ideas and technical aspects and decided it would be nice to have a good pixel artist on board in order to make the best use of all the technical stuff we were doing under the hood, so we invited Mr. Mateo Robayo to join. He was a bit hesitant at first since it seems he didn’t enjoy his previous js13k participation a lot, but since this time he’d focus on the pixel art, he accepted to join.
As the first days passed, we considered doing some kind of action “roguelite” (ugh) with a robot exploring an abandoned factory looking for the correct URL, but as Mateo started coming up with art for the robots, and I implemented a basic “idle” animation with the parts we had, I thought it would be great to have a dancing game. We invited sound and music artist QuietGecko (with whom I’ve done a lot of work in NovaMundi and Emerald Woods), to create some cool tracks and SFX for the robots to dance.
In reality, I had a secret plan to have these 3 guys work back in a game together, but that’s not the kind of things you mention in a blog post.
I was able to do most of my contributions during the first week, luckily the guys were there to push through including the final days which required some big effort to close the scope, integrate everything and deliver an exceptional entry IMO.
The Sprite Renderer
There are many components on this entry, but my main contributions in the coding side I believe were aligned to what I was pursuing with my participation; I’ve always wanted to do a NES or GB emulator, this comes from back when I used to do some simple sprite ROM hacking, and reading about how graphics work in these kind of consoles. js13k seems like a perfect opportunity to use similar techniques for displaying visually rich content using as little storage as possible, and I bet I’m not the first one to think so, but I had never jumped into doing it.
So, with the fundamentals of the idea on my head, I jumped into it and together with agar3s we were able to put it together working great, this a summary of how it works (not that it’s something ground breaking, but I figure someone might find it interesting).
I aimed to support indexed 8 colors sprites, so we had each pixel take up 3 bits, and thus the entire pixel data (128×112 pixels) would fit about 5KB before any encoding or compression. We used a PNG file as the source of image data, thus allowing Mateo to work in whatever tool he wanted (I believe Aseprite is his weapon of choice); this file is then processed by a nodejs script which reads the image data into an array of bytes, encodes the array and exports it to a JS file used by the game.
Encoding the byte array was a bit tricky; my initial ideas worked but the string representations I was able to create ended up using special characters which wound up taking 2 bytes instead of one; as I thought on some workarounds for this, to restrict the symbols to safe 1 byte printable ASCII, we also did some research and ended up following xem’s latin-1 string trick.
On runtime, this data is decoded by the game, and then the renderer displays a sprite by crossing the data from a given palette of RGB values and the index defined in the sprite, thus allowing 24bit color depth display, without having to store the color data for each pixel.
Besides potential savings in storage space, this also allowed us to use palette animation effects (Mateo seems to have had a lot of fun with this) and to include variety in the game.
Ultimately, my contributions to this were mostly infrastructure work; the rest of the team did a great job extending and actually applying it into the game!
This being a dancing game, music and sound effects were bound to have an important part on it. As QuietGecko joined he struggled a lot first with the tools, trying out different trackers trying to make the JS conversion plugins work.
All I could do was recommending using Soundbox, the tool I used for my past two entries which worked great to me; however, everything changed when Keith Clark, the author of ZzFXM, released the beta version of ZzFXM Tracker. Everything worked perfectly from there, and as a plus, the code that was exported made a lot of sense and was much easier to work with.
I’m not sure what happened during the final hours, but in the end we had great SFX too. But you cannot expect less from the QuietGecko.
In his own words:
Having to convert .mod files to .js and translating synths was very difficult until Keith Clark released his tracker, although I experimented creating synths using his sfx creator and it ended up being very helpful. Also, having the issues with the instruments was a bit frustrating at first but it gave me a chance to try different trackers and strengthen the composing muscle which was useful when the time to rush came.
Additionally, having to use 64 note sequences seemed to be a bit too constraining, I wanted to test smaller sequences so we could have a procedural approach but it would be something to revisit next time.
I like that we ended up having a cohesive retro style sound even though I wished to have it more balanced mix wise. I really liked it. I would also have wanted to have a way to teach or suggest rhythm or patterns to players other than beat subdivision.
QuietGecko, September 2020
Discarded Gameplay Ideas
As I mentioned, I could not contribute a lot of code after the first week… besides being stuck with a lot of work in other projects, I also felt kind of stalled regarding the game. In spite of being the one who proposed we went that route, I had never made a rhythm game, and I didn’t think I could contribute a lot to the design so in a way I decided to see what the rest of the team could come up with.
However, one of the things I experimented with after seeing how the game was evolving, was making it so that instead of pressing sequences of random (but varied) letters, you had to do some patterns that would be translated into special moves into the game and give you bonus points. The idea was you would find out about these moves from your opponents, and would replicate them using your individual robot-part movements.
While it technically worked, it was pretty hard! almost impossible as the BPM went up. So we decided not to integrate it in the end, may be it could work for a different kind of robot dancing game.
What Went Right?
Teamwork worked great but this was no coincidence. We are no strangers to game jams and we have worked together in many projects, so everybody knew how to contribute and we also let the project evolve organically with all our ideas. Again, it was great to know the project was going to be completed because the guys were serious about taking it to the finish line.
Besides making the pixel art for the game, Mateo ended up coding a lot of the GUI, as well as the palette animations. I already mentioned QuietGecko’s contributions, and agar3s…. well, let’s say besides contributing a lot of build, tooling and engine infrastructure, he made sure everything worked together and extended the engine towards what we needed. I hope he manages to write down his experience so I can link it here.
What Went Wrong?
Now, if we evaluate the end result, maybe we didn’t really integrate the 404 theme a lot into the game; it ended up being a shallow aspect, when you miss a beat you get the 404, if you don’t find your rhythm, you fail.
Onboarding was also not great, I didn’t like the key layout a lot (D, F, J, K ?), but I was told that’s what people uses nowadays especially on laptops. How the bonus mechanics work inside the game is also not very explicit, but on the other hand it can be deduced after some game play so I don’t think it’s a big deal (as it was in Lost in Asterion).
Overall, one could think if we had a clearer vision of the game design from the beginning, we could have integrated the theme better, and polished the mechanics, but I actually feel the journey of exploring different gameplay ideas was a good experience, and was in a way more fun and exciting than just following a set plan.
This is one of these rare jam entries for which I don’t feel there needs to be any further development; not that it’s a perfect game, but I believe it’s just as good as it should be for a js13k entry (If anything, we could add support for mobile, and that would not be a big deal).
JSConf Colombia 2019, October 18 and 19 at Medellín, Colombia. I was a speaker there for the first time. Here is a brief summary from the talks I was able to check out, based on my live-tweeting. The full talks will soon be available at JSConf youtube channel.
First off, the opening live coding show by algo0ritmos, led by Celeste Betancur. An electronic music and video visualization show where 3 coders connected to a server to manipulate different aspects of the audio and video in realtime.
Sergio Quintero, a local, discussed skimming data hacking via malicious scripts injected into legitimate websites to steal information, and how it can be prevented by intercepting XHR calls using a client-side firewall.
Luis Alejandro Vega, from New York, shared his experience building a career at Bloomberg, as well as how adding “pet characters” to the in-house projects helped increase the ownership of the team over them as well as the visibility for other departments of the company.
Mayra Rodriguez, from Bogotá, discussed the reactive app architecture and shared some tips to achieve good performance in your web app using RXJS stores.
Irina Shestak, from Germany, shared her experiences with Rust and WASM, with lots of tips to make coding, debugging and deploying easier, which she learned thru her quest of learning on the go.
Melina Mejía, a local, spoke about web accessibility being critical to reaching all audiences, and how to implement an accessible interface using ARIA.
Santiago Zapata, a local, did an amazing talk about procedural generation, including an introduction to it, where it can be useful, and a break down of his procedural castle generator.
Missed talk by Anton McConville, from Canada. “Personality hacking: using Node, WebAudio and Houdini to visualize psychology of song lyrics“:(
Vanessa Marely, a local, talked about the power of storytelling as a way to better communicate ideas, and gave some tips for good, effective storytelling.
Missed talk from Kate Beard, from England, “Learn How to Play the Theremin* Today, Guaranteed!” 😦
Adrian Bolonio, from Austria, dug deeper into the issue of web accessibility, focusing on the tools to test it over different aspects of a webapp (code, DOM and final appearance in the browser), including simulating visual impairments of different degrees with NoCoffee.
Jerome Hardaway, from Tennesee, talked about how to make it easier for people to jump into existing software projects. Remove ego from your code, code for the others. Design the onboarding process seriously around building the confidence of new team members. Document and refactor.
Daniel Rico, a local, briefed on how container-baser deployment enables horizontal auto-scaling, and shared the results of his experiments to find degradation points in NodeJS vs Tomcat, which can help finding out the number of nodejs instances required for your app.
Colin Ihrig, from Pennsylvania, gave a very useful walkthru of some diagnostics and debugging tools included in nodejs out of the box, when and how to use them.
Jessica Lord, from New York, shared the history of Electron: going beyond Atom, avoiding a scaffolding approach ala rails, the importance of clear and maintainable docs and building a community around the new tech. Developer Experience is critical for a successful tech tool!
Missed talk by Luis Villalobos, a local, “Desarrollo de interfaces modernas de usuario usando un “viejo” modelo matemático computacional” 😦
Bryan Hughes, from California, believes programming can create art just as any other technology (such as watercolor or oil paint) can. It’s all in the intent of whoever is using the tech: is it to convey emotions or facts? Finding your style is a mix of chance and determination
Finally, Eva Ferreira, from Argentina, went into a trip 10 years back to the past on web development, how things have changed for good and the history behind these improvements. But also how some things have gone amiss… abuse of push notifications, privacy breaches, popup madness, websites heavier than needed, lack of accessibility, fatigue for new frameworks… where are we heading to, can we do things better?
I managed to participate in the competition for the third time in a row, this year I created a monster-catching game. You can play online here or here. Source code is here.
The game itself is pretty simple, you walk around the map using the cardinal directions, and when you land on a spot you may find a monster and catch it. Both moving and attempting to catch a monster will consume your action points, which replenish automatically every 20 seconds to a maximum of 40. It works in both mobile and desktop browsers.
The organizers were encouraging the participants to integrate with coil.com and XRP tip bot to monetize their entries, I implemented a simple bonus for coil subscribers (they get a 25% bonus on the speed for action points to recover). So far I have received 1.08 XBR (That’s Ripple cryptocurrency, converting to about 0.3 USD today)
What was my motivation this year? I was really hesitant to participate since I’ve been busy with other projects and just participating for the sake of it was not enough of a reason. Certainly, after last year’s results, I didn’t care much about “winning” the contest.
So, in the end my motivation ended up being merely to create an interesting procedural generator, to hone my procgen skills. I had just tried to participate in “Advanced Topics in Procedural Content Generation” online summer school provided by the IT University of Copenhagen and New York University, where I was able to watch some talks and gain some insights, but failed to participate in the course project.
The weeks before the challenge started I had an idea for a procedurally generated sports event (that thing has been in my head for some time now), but it was not very compatible with the theme they announced (“Back”). For most of the month, I couldn’t come up with something fun and interesting, that only managed to happen in the last week. So I started late and only managed to invest about 5 days on it, but the last days were super intense.
Being a pokemon fan (and a somewhat proud genwunner), I always wanted to create a monster-catching game (well, I kind of already did). Some years ago I was even working on a Pokemon Go-like game, but it never lifted off due to missing some original designs for them monsters.
So, I thought I could take another stab at a similar project, using procgen to fill the gap. I started by analyzing some pokemon anatomies and coming up with their structure and even used tracery.io to have an idea of how this “taxonomy” was looking (I had wanted to use it for something, for years :P). Sadly I didn’t include these descriptions in my final entry. (then again, I dunno how big the JS lib for tracery is)
Then, I started setting up the project, reusing the structure from my previous entries. In keeping my idea of NOT using pixel art on new projects, I thought of reusing the vector rendering routines I had used in these previous entries, however, the shapes I was planning to use were going to be more complex (I was initially thinking on trying to replicate the look of the original pokemon, like this one), so instead of just coding them by hand I used some online SVG editors and then manually translated the SVG instructions into my rendering routine.
However, as I needed to produce more complex shapes (mainly supporting bezier curves), I found out it would be more straightforward to generate SVG objects rather than extending the “vector script” I had in place, which by coincidence was pretty similar already to the SVG path definitions. This became more important as I looked for ways to get an artist to help me with content for the game since I would have had to translate SVG into my own script language, either manually or automatically.
So I ditched rendering paths and shapes into the canvas and instead started experimenting with generating SVG components from code and overlaying them using CSS.
As the deadline drew closer, it became obvious that I would not be able to replicate the appearance of the reference I had for the monsters in a convincing way. I looked around a lot and finally found something in Etsy that I could use as a reference for my generator. (sadly, the store and the item itself seem to be gone now. Good timing for me tho!)
These designs had several advantages:
They were portrayed as a symmetrical front view
They were more “symbolic”, without relying on individual poses for personality.
They were “inspired” by the original Pokemon designs, so not a direct knock-off.
They were already provided in SVG format.
I bought it, thinking I could at least cut and paste the different body parts and use them as individual SVGs, but my skills with both Illustrator and Inkscape proved not to be enough for it. Luckily, js13k colleague Rybar came to the rescue and helped me with the task, probably having to redo a lot of SVG work following the references.
Now with the individual SVG assets provided by Ryan, I could finally advance in the actual generator, having, at last, some progress to show.
The generator works by picking a random “anatomy” which determines the body parts slots the monster will have, and their location. then it proceeds to select a random type of body part for each slot and positions them together using some anchor points.
It also picks a random “pastel” color for the monster, I did some research and found out an easy way to generate them was using the HSL model, and having both Saturation and Lighting at 70%, and picking a random Hue. Luckily, CSS supports defining colors with the HSLA notation so this was pretty easy to include.
I also build a simple, syllable-swapping based name generator for the monsters. It generates names using two to three syllables, picking from a random list of consonants, vowels and a possible third consonant, for each syllable.
It’s also worth noting that this generator is seeded, which means the “races” of monsters that are generated are always the same, and all players will get the same set! For this, I reused the simple (on implementation!) but effective Park-Miller LCG
Now that I was finally generating some content, I focused on creating an actual game around the generator. I knew from the onset the game would not be deep, but there had to be a game!
I created a world represented by a 10×10 grid of locations and added a simple name generator for them (reusing the monster name generator but also adding some flavor with location types and colors). Also added the energy system to move around and catch the monsters, to serve as a barrier for content consumption.
In the world model, I placed lists of monsters for each location, considering their “rarity” so that very rare monsters can only be found in a single location, and so on. The idea being that players could share their findings, creating something of a social aspect to the game (Hey, what monster are you missing? I found Lesense in the Temple of Serkekol!).
I added a simple model to keep track of the monsters you had captured, and a view where you could see them.
I had managed to have a playable game one day before the deadline, so I could focus on enhancing the UX and testing. Needless to say, this ended up consuming a lot of energies but the end result was very good.
I managed to include a music track (thanks again to Rybar for creating it!) and even modified it in the tracker to make it longer (first time I make something useful using a tracker). We used SoundBox again (here‘s the final version of the track)
I also made the game public and asked around for suggestions to improve it, one of them was adding more variations to make the monsters feel more unique. I fired Inkscape and drew a lot of horns, antenna, mouths and some tails, and also defined an additional anatomy with no “body” (just a head with things attached to it). The structure that was in place made it very easy to add new content.
Also, in order to add some “depth” into their appearance, I was suggested to do some shading into the bodies, which I managed to do with the help of Prinfexita, a fellow indie dev from Colombia. She drew the shadow shapes and I added support for them into the generator (including producing a darker version of the body color)
I also did a LOT of tweaks on the user interface, to make navigation easier for the players and provide a cleaner experience, especially in mobile.
What went right
I was able to create a finished, stable and polished experience
I learned a bit more about SVG
I created something technically different than last year entries.
The monsters look cute.
I was able to collaborate again with Ryan Malm, for the first time with graphics and for the second time with music.
Inadvertently, I think I managed to do just what I set to do from last year’s postmortem:
An easy game, rewarding players without requiring lots of skill.
Gorgeous visuals. (Maybe??? :))
What went wrong
Nothing really went wrong, however, there are some core things I wish I had managed to include to make my entry more fun:
A scrolling map view of the world, since right now it relies a lot on the player imagination
Deeper gameplay mechanics for catching the monsters, maybe collecting some items in the world that would help you lure them.
Allow trading monsters with other players.
More body parts, especially Wings and tails
Scaling variations for the monster’s appearances.
But all in all, I’m very happy with what I was able to create in the short time frame.
However, I got pretty sick and weak for two days after the deadline, I believe I pushed too hard. Would be better to avoid crunch by starting earlier.
I never intended the game to be more than just a collecting game, so things like a plotline or a combat system were willingly ignored.
Some other things that would have been nice to have, as possible points of expansion:
A more in-deep generation of the monster anatomies beyond randomly selecting and swapping parts.
ArcherFire: Duet of Aces is a game I made for the js13k 2018 contest, you can check it out here! (and the source code is here)
I decided to write one final piece of text about my second participation on the contest. I already described my journey in detail here and here, and also did a dissection of the source code, but I wanted to record some lessons learned which may come in handy for other people or myself in the future.
Whenever I participate in a game jam or contest, I ask myself what is my motivation:
Learn a new language or tool
Create something cool
Win the contest prize
This was the second time I participated in the contest; results from last year had been a bit disappointing (regarding the ranking given by the jurors), and I knew my development time this year was going to be very limited. Still, I aimed to rank high into the lists.
The theme for this year was OFFLINE, as mentioned in my first blog post, I started off with a vague idea of a space… thing… where you could collaborate with other players offline to advance through the game.
On the first day of dev, I created some foundations work looking forward to having some kind of space sandbox thing with arcade elements (Similar to this entry, which ended up being one of the contest winners). However, given the constraints I had, I decided to follow my own advice from last year’s postmortem and create:
An arcade game bringing full action from the first second of gameplay
Complete music track
And that’s precisely what I ended up doing! Interestingly, and maybe because of what I set to do and my experience from last year, I didn’t have any issues with the 13KB limit so I didn’t have to cut around any corners. I incorporated the OFFLINE theme by allowing 2 players hot-seat offline play.
However, the results were even less encouraging this year. Despite receiving good feedback from the jurors, the game didn’t even end up in the top 100. (Last year it ended up #40 overall and ranked well in the Community and Social lists). Since this was the first year where some constraints were put on the prizes model (only top 100 entries would get prizes) that meant that effectively I lost the contest. There was a total of 270 entries, and mine ended up ranked #105.
Unlike last year, this time I don’t really have some big factors I think led to this result. I contented myself in thinking that the jurying process is not perfect, and there may have been very good entries this year. Still, here’s what I think worked and didn’t work.
What went right
Seeded Procedural Generation: Managed to create an infinite, increasingly harder, top-down shooter level which was the same every time you played (So, in theory, the more you play the game the more likely you are to memorize the hazards and get farther)
Pseudo 3D Effect: Everyone loved how cool the ships looked when soaring around.
Straightforward action-packed: The game is pretty responsive and quick, with lots of action on screen. No need to explain anyone how to play because it’s obvious!
2 players hot-seat mode: I couldn’t test this much because I have no friends, but I saw some people have fun and yell at each other afterward.
A solid, finished entry: No bugs, no feeling of being an “incomplete game”, it is what it is and it doesn’t break.
Music: One of the game highlights, and I didn’t do it myself 😀 it was all thanks to Ryan Malm. I just gave him a reference and some ideas, and he came up with the track. Thanks again!
What went wrong
Floaty Controls: Since my foundational work on a simple physics engine had support for acceleration, I stuck to the end with the idea of the ships being “hard to control” as a “challenging aspect” for the player. I knew it was frustrating, but I waged on the players trying harder to learn how to control it. In the end, it ended up being too hard and too different to the standard. A model where the ships had less inertia would have been much more playable and enjoyable. Maybe I need to start making easier games!
Balancing: Some people reported the game was a bit too hard. In part, this may be closely related to the controls, but also could have lessened the hit points of the enemies or made the difficulty curve less step.
Lack of theme: Yet another space shooter, no plot, maybe went too much into the arcade direction? So that aspect was pretty uninteresting. There were also too few types of enemies, mainly because of the time constraints I had.
Graphics too simple: I am not an artist, and the game had high-resolution vector art. Unlike last year where I could go around that by using shadows in the darkness, this year I went for colors and maybe it didn’t look too nice. One thing that could have worked would have been using WebGL filters to post-process the bare graphics, which has worked great for other games in the past.
This is not the end of the story for Duet of Aces… I plan to make it evolve into a more complete game, keeping the core design but adding better art, sound effects, more music, a complete plot and more importantly, adapting it to social media mobile platforms. More info soon!
Also, some things I want to do next year:
An easy game, rewarding players without requiring lots of skill.
It seems like the core of the tool is an interpolation function for these values, coupled with some research on how light works in the atmosphere (over-simplified of course). I went ahead and used the original old source code (probably one of my first works in JS) and transformed it into a decent module. It’s now integrated into the engine, in theory, this would allow to change some attributes of the atmosphere and have the color of the sky respond (small details, but it’s fun).
Also allowed defining items for the NPCs, which allows Shamino to fire arrows.
Been considering how the UI should work (full-screen map vs. a layout similar to U6). For now, I think I’m going to continue on the route to create an exult/nuvie-like layout with floating windows. This also means much smaller reliance on the events log/messages window for things like combat, the damage will instead be shown on screen, for starters.
Another thing I’m considering is merging MobTypes and NPCDefinitions, I see a lot of overlap there, and it’s causing the code to be more complex than it should, what I’m thinking is a single list, so you’ll be able to define what a generic skeleton is, and in the future make spawners for them, but in the same set of definitions you would have for example Shamino, including his full dialog and initial equipment the current way things are laid out you reference a mob type from the npc definitions, but I’m finding out that most of the times you will not reuse an existing mob type….
Unless maybe if we need to have a lot of NPCs, reusing the same basic definition for a “townsman” or “children”… gotta think about this more before making the moves in the code