Backpack Monsters – js13k 2019

Js13kGames is a JavaScript coding competition for HTML5 Game Developers. The fun part of the compo is the file size limit set to 13 kilobytes. The competition started on 13th August and ended on 13th September 2019. The theme for 2019 was back.

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.

image (3)

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)

The Story

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)

js13k0

js13k1

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.

js13k5

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!)

unnamed

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)

sb

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.

The Future

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.
  • Generate monster descriptions and stories.

 

 

 

How to make money as an indie gamedev

Quoting a piece of advice from Paul Eres on a post on Facebook’s Indie Game Developers group

There are only a few things you need to make money as an indie:

  • Choose a genre that is selling, and that you enjoy playing and are good at.
  • Be competent enough at programming and level design that you can make something that plays as well and is as fun, with some slight changes here and there to add your own personal touch based on your own desires and likes and dislikes.
  • Either be an amazing artist, or have an amazing artist on the team, so you can make something that stands out graphically.
  • Make sure either you can make a great trailer, or know someone who can, and make a trailer that stands out above all the other indies trying to make a game in that genre.
  • Know some basics about marketing — know how to use your game’s trailer and screenshots to gather a following for your game before its release, so that a good portion of those interested in your genre know that your game will soon be released.

Note that being original and good at coming up with ideas is not in the list.

Curse of Wallachia – First Days of Dev

Day 0

  • Hesitated to work on this, tried to team up with someone
  • Considered different alternatives for engines.

Day 1

  • Decided to go ahead with Phaser by adapting the OAX6 engine
  • Created test maps
  • Can move sprite around with walking animation

Day 2

  • Arcade Physics, Jumping
  • NPCs moving around
  • Stage transitions
  • Talking to NPCs
  • Started work in portraits, using the amazing 8bit photo lab

Day 3

  • Design levels and intro
  • Added support for lowercase letters and portraits to dialogs
  • Started working on cutscenes support, added simple timed dialogs

Day 4

  • Added animation for dialogs to display one letter at a time
  • Added full Engrish script for cutscene 1

 

Design and technical details about OpenArthurianX6

Adding a bit more detail of the features of OpenArthurianX6. You can still contribute to the campaign (23 days left).

What kind of game will you be able to create?

The engine will allow you to create 2D top down RPGs using orthogonal grid maps with an hybrid real time / turn based mode (real time for normal gameplay, turn based for combat).

The core of the engine is inspired by the Ultima VI engine, which means you can model your game world as a continuous single scale map where all action takes place (including combat) and you will be able to engage in conversation with NPCs to obtain information and advance through the game and its plot, using plot items to resolve puzzles and uncover secrets and exploring the vast world to find surprises.

Graphics

Supported graphic styles include the oblique perspective characteristic of the Ultima IV engine, as well as a 3/4 front facing perspective similar to traditional jRPGs ala RPGMaker, and a full top down perspective for more symbolic, old school games similar to Ultima V.

The game will include two medieval fantasy art packs from Denzi: one will allow creating maps with an oblique, Ultima VI like perspective, while another one will allow creating older school looking top down games. New art packs will be released as allowed by the campaign budget.

Music and SFX

The engine will support situational music triggered by game events or tied to game locations, as well as sound effects for the game actions. Supported formats are MP3, OGG and WAV.

The engine comes bundled with a basic SFX pack. Music is left to the game developer to find for his own game.

Features

  • Multiple characters party: You will be able to have NPCs and pets join your party, they will follow you around and you’ll be able to command them in combat if needed.
  • NPC Schedules: They wake up every day to go to their jobs and come back home in the night. Schedules are customizable per NPC.
  • Day and Night cycles: Reduced visibility during the night, different enemies activity.
  • Camping: Make camp in the wilderness to recover your strength, beware being ambushed!
  • Party AI: When in battle mode, other party members can act on their own optionally, selecting a proper target for attack or running away based on general parameters.
  • Dialogs: Create an history which is unveiled by talking with NPCs, finding clues and using the information you obtain from the to travel the world.
  • Crafting: Gather elements from the world and combine them between themselves or other items to create new items. Obtain leather from dead animals and create clothing from it, bake bread (of course!), create weapons using metals in a forge, and more!

Platforms

The games created by the engine will be accessible for desktop (Windows, Mac, Linux), mobile (Android, iOS) and also playable from modern browsers.

Supported input modes

  • Keyboard: Movement will be done using the arrow keys, numpad or WASDpad.
  • Mouse and touch interfaces: Movement will be done by touching the map in the cardinal direction the player wants to move (without pathfinding). Drag and drop will be supported for inventory management.

Licensing

The engine will be released under the MIT License, allowing you to use the engine for both commercial and non-commercial works, without you having to include any modifications or additional source code. All community contributions will be welcome of course.

Scripting and Programming

The engine is made on JavaScript, and in case you are going to use it directly (without the scenario creation tools), it will provide a JavaScript API which you could use from your own game’s code. JavaScript is also used for scripting events and behaviors.

 

Enhanced process for hybrid apps

Some months ago I wrote about the pain that it was to create a new build, I’d like to update that with my current setup which is much better tho not still super optimal.

I have reduced the manual steps prone to failure as well as the bandwidth cost. The release and announcement part is still manual tho, so I still don’t to release for all platforms and forget to announce thru all channels.

The cocoon.io parts have been removed in favor of a pure Cordova/Crosswalk approach, which have made possible lots of automatisation.

Still, what takes more time is the manual process to be done for each different storefront via its own web interface. Each one requires different info, and all uploads have to be started and monitored manually. It’s pretty uncommon for a store to supply a command line tool.

This is the current process executed for each new release of Ananias:

Packaging

  • Mark the new version in the source code (client and server)
  • Execute the packaging script for each platform, it does the following:
    • Generate a new JS bundle using browserify
    • Generate the player’s manual
    • Copy the required assets based on the platform
    • Do platform specific things like using cordova/crosswalk, nw.js, signing and zipaligning APKs, etc.
    • These are currently shell scripts, no fancy gulp or grunt for now
  • Rename and zip the executable packages for Windows, Mac and Linux (Should add this to the script)
  • Execute the cordova build for iOS
  • Build changes log from git commit messages

Distribution

  • Upload new build to web (ananiasgame.com/play) (About 15MB) (Only Standard edition)
  • Deploy new server version and restart (About 1MB) (including executing migration database scripts)
  • Upload to itch.io via web interface (About 200MB )
  • Sign in to google play developers console
  • Summarize change log for Google Play
  • Upload both x86 and arm APKs (About 100 MB)
  • Upload both APKs to Amazon via web interface (About 100MB)
  • Upload to indiegamestand via web interface (About 200MB)
  • Upload to gamejolt via web interface (About 200MB) (Only Standard Edition)
  • Upload to IndieDB via web interface (About 200MB) (Only Standard Edition)
  • Open xcarchive in xcode organizer
  • Submit package to App Store
  • Wait for processing
  • Go to iTunes Connect
  • Go to Testflight / External Testing
  • Select new build to test
  • Wait for beta review
  • Go back to Testflight / External Testing
  • Set the new build as active.

The process should be executed twice, once for the Standard Edition and then again for the Fellowship edition.

The dream of having a single web endpoint, and have all the clients deal with the updating is still far from happening.