next »

[JustACicada]

(Windows/Linux/Android - Current version: 0.2.0 - First two chapters playable)



A singleplayer turn-based strategy game where each action is a card.

Customize the decks of your characters to overcome enemies and challenges as you learn more about this beautiful, seemingly utopian paradise in a lore-rich fantasy world.

Features:

• Turn-based combat. Choose your actions from an editable deck of cards.
• Alchemy system to create new cards or improve old ones.
• Freely edit the decks that the characters will use in battle.
• How you build your decks will also determine what traits (passive skills) the characters will bring to battle.
• Explore dungeons, collecting materials and solving puzzles in your way.
• No random encounters! Instead you will find on-field enemies that you can avoid if you carefully think ahead and measure your steps.
• Story set in a science-fantasy world full of ancient historians, advanced megalopolises and the occasional snarky dragon.

Screenshot showcase:





Download (free):
Windows/Linux: https://justacicada.itch.io/ubiquatopia
Android: https://play.google.com/store/apps/details?id=com.SamuelVazquez.Ubiquatopia

[JustACicada]

Now with an actual devlog!

Ubiquatopia is an in-development strategy game where each action is a card.

The gameplay it's akin to something like Fire Emblem or Final Fantasy Tactics except that each character, instead of having a specific set of actions, has a customizable deck of cards to pick actions from. Cards will determine things like movement or action range. There are cards for attacking, buffing, debuffing, causing status ailments, and a few weirder ones like... manifesting water or gravitationally pulling everything towards a certain tile.

Dungeon exploring happens in a more traditional RPG fashion, except that instead of random encounters, you have on-map enemies that you can avoid. They move only as you do, and you can use terrain to your advantage to outpace them or otherwise avoid them.

There are also quite a few other systems in play, like your deck composition deciding starting health and passive traits, as well as an alchemy system to create/improve cards.

And as far as the story goes, it's an odd science-fantasy mix (with cutscenes you can thankfully skip), about demigods vying for power and control in a civilization that muddles the line between utopia and dystopia. And lots of world-building, because it's something I cannot help.


I've prepared a few videos for the occasion. First, the in-game tutorial:





And also, an actual battle:






The game is far from finished, but it's playable up to its first chapter (4~6 hours?).

Feedback is naturally welcome.

[JustACicada]

These last few weeks have mostly been spent planning, being sick, and unsuccessfully trying to port to Linux. Great start of the decade.

But at least I managed to finish a few more monster designs. The next few story plots will take place atop mountains, and mountains make me think of eagles and wolves.

This wolf enemy is just a boring old wolf. It will likely fight using Ferocity cards, which are cards patterned around chess tactics. Which makes just as little sense in context. Those cards are mostly about space and positioning control, like pushing things, altering terrain and such.

And then there's the eagle. I don't know what happened there. I cannot draw feathers for the life of mine, so they ended up looking like razor blades. So I decided to roll with that. This is now a special breed of eagle that develops razor-sharp feathers that they use to defend themselves. I could probably even make them use Sword or Spear cards or something.

And I also made robots. Spheres, obviously, since they are easier to draw.

This game is about an incredibly technologically advanced society, so it only makes sense that its knights would bring assistance to battle in the way of these cute little bots. They both will use Cipher cards, which are kind of meta-cards that play around mechanically with cards themselves.

The green one is a "Helper Bot", and will assist its allies by making them draw more cards and whatnot. The red one is more of an "Annoyer Bot" that will discard opponent cards, or return their cards to deck, or shuffle hands. They probably will not attack directly (often) but if you let them do their thing, the situation will escalate out of control rapidly.

I also spent far too many days trying to make a Linux build, only to run into the dreaded Black Screen Bug that is apparently present in the 2018 LTS version of Unity. I scoured the net and tried every solution or hotfix I could find, but it seems like the only reliable solution would be to update to 2019, which would of course break many other things. It's something I will probably want to do at some point, but definitely not right now.

And that's it for now. I'll try to write devlogs more often, because my communication so far has been terribly lacking. I'll see if I can manage at least one log per week.

[JustACicada]

This game takes quite a bit of inspiration from the concept of fundamental interactions, with gravity at the lead. And gravity makes me think of low tide vs high tide, so this one next area is based around that idea.

During battle, every other turn the tide will alternatively rise or fall.

Flooded tiles incur a small movement penalty, but also lower incoming damage. Perfect for a more defensive playstyle. I also coded in a new type of terrain, the highland, which grants a damage bonus against targets not on highland and cannot be flooded.

But tide shenanigans aren't exclusive to battle. This game features your classic box-pushing puzzles, with the little added twist that you can pull things towards you from a distance via gravity. And in this area, there's the added complication of tide manipulation.

On a low tide there's no water and rocks can be pushed or attracted normally, although never able to leave specific regions beautifully delimited by dotted lines. On a high tide everything is flooded, but now the floating rocks can be freely moved around the water using gravity.

The following simple proof of concept also doubles as an introductory puzzle. If there is no water the rock cannot be moved because it's not within the dotted area. If there is water the rock can be moved, but it cannot leave the flooded area. The solution is as simple as positioning the floating rock on the appropriate spot so that it can later be pushed normally when water goes down.





This mechanic can then be reutilized in other puzzles quite devilishly. The entire dungeon will consist of a macro-puzzle where you have to guide a rock from one side of the stage to the other, all while solving smaller puzzles and fighting back annoying foes in the way.

Here's the (yet unfinished) stage:

[JustACicada]

I'm trying to port to Android.

Ubiquatopia isn’t very resource-intensive (advantages of having average graphics at best), and given it is a slow-paced strategy game, I thought it would feel right at home in a mobile platform. I’m creating it in Unity, which has specific utilities to directly port to Android, so it should be easy. It’s just clicking a button, really.

So I built it, which was indeed just clicking a button, and passed it to my Android (luckily I already had the Android development toolkit installed in my computer, so that saved time).

So I run it and… the very first screen has graphical glitches. Okay, that’s understandable. I’m using some weird shader where I use a signal noise to create kind of fuzzy “shadowy” borders, and I’m guessing that shader doesn’t translate well to Android. It’s fine. It’s non-fundamental, I could remove it if needed.

So I start the game and… I cannot move. Well, obviously. I only have keyboard controls for the exploration part of the game, so I clearly need to implement touchscreen controls. I opted for the classic on-screen joystick. Getting its dead zone to respond properly was anything but fun, but other than that it wasn’t that much of a headache. I’m still not entirely happy with how it feels, though.

Now that I can move I decide to enter a battle and… of course, battle has a wholly different set of controls. Now, Unity automatically translates computer clicks into mobile taps, but that doesn’t work all that well. Normally I use mouse hovering to show information on units, cards and the like, and clicking to actually select the unit or card, but there is no “hovering” on mobile. I will have to implement some behavior like tapping once to show info and tapping twice to actually select it.

And that’s just the start of it. I have to also take into account other controls like cancelling orders, zooming or scrolling around, ending the turn, showing unit info, and so on. I might have to create actual onscreen buttons for some of those commands, since there are only so many ways a user can interact with a touchscreen otherwise.

And then there’s every other menu in the game, which I will also have to adapt. Other than actually opening the main menu (by adding an onscreen button, I suppose?), I have to deal with the map screen, the deck edit menu, all the alchemy menus, the collection menus, and a few other specific menus. Thank goodness most of the input behavior for those menus is shared.

Also, I just now realized that I also have to modify the in-game tutorial for Android. So that too.

And then after playing for a bit I reach my first cutscene, and, lo and behold, no characters appear. I’m debugging this right now to try find the problem (I’m actually writing this to make time while the build finishes, since it takes roughly half an hour). My best bet right now is that this is either a positioning problem, some camera or canvas issue, or some issue with some shader. I really hope it’s not the last one, because I wouldn’t even know where to start. (Quick edit: It’s none of those. It’s a stupid formatting error with the XML Reader. Beautiful.)

All of this, of course, also means that I need to learn how to debug in a mobile platform with Unity, which is actually not that bad. For future reference for myself (and anyone else this might help, I guess):

• Download the Android SDK and NDK and assign them to Unity (Edit > Preferences > External Tools). Get the Android SDK command line.
• When building with Unity for Android, make sure to check “Development Build” and “Script Debugging”.
• Connect phone via USB (after enabling debugging in phone and whatnot).  In the Android SDK command line, run “adb devices -l” to ensure that the phone is detected.
• Run “adb logcat -s Unity DEBUG” in computer before the app is launched in phone. Then, launch the app. Any Debug.Log in the phone should appear on the computer.

There’s also the issue of resolution. My phone just so happens to have the same resolution as my computer, so I’ll have to deal with alternate resolutions somehow else. I’m still not even sure how to test this.

So overall this is going to be very time consuming but I think I know what to do and how to do it. Mostly. Now it’s just a matter of actually putting some time into it.

[JustACicada]

Most progress since last update has taken place on the technical side of things, porting to mobile, something kind of dull and boring to do a devlog about. So let’s try something else.

I noticed that I’ve never really talked about the characters or the story or anything. Might be a good time to start. So let me begin by introducing the three first main characters in the party, while also sneakily using them as an excuse to talk about the gameplay and maybe lore.

(Also note that I’m no artist, so I’m afraid the art is what it is.)

The Herbalist

Now that really doesn’t look like a protagonist. The Herbalist is, well, an herbalist. In spite of the sinister getup, this is actually a fairly polite and well-behaved individual. He lives in a once abandoned mansion in the middle of a forest, offering apothecary services to anyone that might need them. Overall, he tries to stay away from conflict.

So why the creepy mask? Lore time. That’s an “Arche”, a unique kind of ancient artifact that grants their wielder diverse advantages, most notably immortality. Each Arche is modeled after a concept (in this case, Fear). An individual may only wield a single Arche, and those who do are known as “chroniclers”. Chroniclers are expected to sit on the sidelines and merely chronicle history without influencing it too much. Most chroniclers ignore that, but the Herbalist more or less follows that ideal. Or at least tries to.

The Arche of Fear is grafted onto its wielder’s face, becoming unremovable. Not necessarily something he wears with pride, but there isn’t much he can do about it. The mask subconsciously instills fear on others, which is just one of the reasons why he prefers to stay away from civilization. He counts among the oldest chroniclers in the continent.

Gameplay-wise, he’s the party’s main healer. RPG protagonists are almost always aces-of-all-trades or physical attackers. And yet it is the healer that usually is the most important character in a party, so why not make them the protagonist?

The game's combat takes place on a grid-based battlefield, with the characters using cards from a deck to execute their actions. The Herbalist can use Herb cards to heal, buff stats, and a few other weird things. Offensively, his choice of weapon cards allows him to attack some moderate distance away from the enemy. He’s actually a decent damage dealer, but cannot tank that many hits. He would really benefit from having some assistance. Speaking of which…

Fio

A manticore. Desert-dwellers, isolated from the rest of the world, and incredibly aggressive and territorial. She’s far more tempered than the average manticore, but that’s not really saying much. Not the most patient girl, but not quite a warmonger either. She chanced upon the Herbalist’s Apothecary and decided to stay to learn more about the many different species that inhabit it.

She owns the Arche of Diligence, which makes it impossible for her to feel tired. So she’s an immortal chronicler too. Most major characters are. She mostly avoids trouble out of respect to the Herbalist, but she’s not necessarily as inclined to peacemaking as he is.

In combat she’s more of an aggressive tank, dealing high damage and able to take it, but with limited range options. She can use Knives for high mobility but low attack, or Axes for the reverse, resulting in a very versatile character. Her specialty cards are Toxin cards, which can cause diverse negative effects on opponents, like lowering stats or the mandatory poison ailment.

Really, one of my main characters is a manticore, so I cannot not have poison in the game (also, I feel like poison is kinda broken in this game, but it’s usually useless in most RPGs so it evens out). However, Fio is severely lacking in ranged attacks. But the next one’s got her covered…

 

Roman

Just when you thought this game finally had a normal human character, you notice the sudden skeleton hand and ribs. Goodness. Necromancy-related mistakes, you see. But that’s a thing of the past. Roman is primarily a scholar, someone who wants to learn more about the world and how it works. Born in the eponymous Ubiquatopia, a megalopolis not too keen on the idea of free thought.

His Arche is Curiosity, which pushes him to always learn more and more. It causes him physical pain if he doesn’t expand his horizons from time to time. He left Ubiquatopia when he was young, and in his travels he eventually ended up at the Herbalist’s Apothecary. Since the Apothecary is a neutral entity that takes no sides in political conflicts in the region, and given that it houses the largest library in the continent, Roman thought it a good idea to stay for some time.

In combat, he prefers to keep his distance and attack from afar. He can use Knives to move great distances and Bows to attack from a safe place. Bows tend to have absurd Areas of Effect, which helps with crowd control. His Spellcraft cards also tend to have good AoEs, with occasional added benefits like causing ailments. Overall, he is a decent support character, although somewhat lacking in durability.

 

You know that fantasy cliché about the strong, ancient character that could easily solve all plot problems but refuses to act? This game is what happens when you get a few of them together in the same place. And then give them an excuse to actually have to act.



With a bit of luck the mobile port should be ready in the next few weeks.

[JustACicada]

The port to Android is pretty much finished, and if nothing goes wrong it should be up on Google Play Store next week.

Quick comparison between PC / Android:

Exploring dungeons requires keyboard interaction for actions such as moving or opening the menu, so I just needed to translate that into on-screen buttons.

Most menus received modifications in the way of resized buttons. The small buttons are fine for a mouse on a computer, but they are too small to reliably tap on a small screen on a phone. The bigger size makes them much more manageable. Scrollbars also received a slight resizing. The overall resizing of elements also means that there are now a few more scrollbars that weren't needed before.

And naturally, there's the issue of aspect ratios. For PC I forced everything into a 16:9 aspect ratio, resizing if needed, but you cannot really do that in a phone given how small they are. It would look horrible. So a different menu configuration is needed for each common aspect ratio.

The most straightforward solution would be to make many different menus for different aspect ratios and then offer the player the one that most closely corresponds to their phone. That would be hell to maintain for a single person. I have way too many menus. So instead, I'm using a single menu for all aspect ratios and resizing elements appropriately with a canvas scaler. All UI elements just need to be anchored to corners of the screen, and then they will expand or shrink as needed. This definitely needed a bit of tweaking and testing, but it seems to work fine.

It's far from perfect. At higher aspect ratios there's a bit of empty space between elements, but at least there are no overlapping buttons. And this means I can use a single menu scene for both PC and Android for all aspect ratios, which makes it significantly easier to maintain and update if needed.

And then there's the issue of shaders. I use ShaderGraph for certain effects, and while they looked just fine on Android, I noticed that many slowed the game down to a halt. After much testing I found the culprit: noise generation. Many of my graphical effects used random noise generation to achieve certain "random" behaviors such as UV distortion and whatnot. It turns out Android is not powerful enough to do this every frame, so anything that used noise generation had to go.

The solution? Well, I didn't care about the noise "generation" per se, I just needed noise at all. So instead of generating random noise on the run, I just feed the system a .png file with pregenerated noise, and loop it if needed. The final result is not quite as nice, but it does the work and runs smooth.

As an example, here's a moderately complex PC shader that generates three different monochrome Voronoi noise signals every frame, each with a different offset and speed, and then combines them as the respective RGB channels of a single output texture (after sampling and whatnot). I swear it is far simpler than it looks. It's just telling Unity to generate three different signals and then combining them.

For Android, the basic idea is the same: create three different Voronoi signals somehow and combine them. The problem now is that we cannot generate noise on the run on Android, so we have to emulate it by passing it a static image that kind of looks like Voronoi noise and then sampling it three times at different offsets and scales. It doesn't look quite as good and it is unneededly contrived, but at least it runs fast on Android.

So basically, porting to Android required quite a bit of tinkering around. No part was excessively difficult or anything, but there were just too many little things to keep track of. But it's done now, and I've done everything I could to keep my code as platform-agnostic as possible, so the game shouldn't require any more massive adaptations like this one going forward.

And that sure was quite the wall of text. So thanks for reading. Now I'll just wait until Google decides to approve the app.

[JustACicada]

Ported to Android. Finally. You can find it here:

https://play.google.com/store/apps/details?id=com.SamuelVazquez.Ubiquatopia

Except for the UI and touch controls, it's the same game as the PC version. No new content.

From now on I should be able to progress on both versions simultaneously without much issue. The game itself is far, far from finished, but it already features quite a few hours worth of content.

Overall, the entire process of porting to Android took a little under ~2 months on my own. Too many little details, and honestly not quite as much documentation on the topic as one would expect. But now I suppose I can go back to working on actual new content again.

[JustACicada]

Most of the week was spent designing a new character. A dragon to boot. Here's the good fellow:

A primeval dragon, manifestation of a fundamental force in nature, electromagnetism. Named him "Magnes" after the mythological real-lfe figure of Magnes the shepherd, who supposedly discovered natural magnetism. Although he of course uses that name only as an alias, as a proud dragon would not so casually share their true name.

There's a few details here and there about its design based on electromagnetism, such as the tips of his horns having the typical coloration of magnets, or his frontal horn kind of being based on a lightning rod. The wings too show shapes somewhat reminiscent of the classic lightning bolt symbol. Not sure why I picked green for the main body color. It looked reasonable, I suppose.

Plot-wise, next chapter involves entering a city with electromagnetic mind-readers (it only makes marginally more sense in context), and so seeking a pact with this good fellow to somehow circumvent that. Gameplay-wise, a pact with a dragon grants the lucky partner the ability to "fuse cards" for stronger, usually non-standard effects. This implies using up two cards in a single turn, which can leave you at a disadvantage later on, so it is a tactic that requires a bit of care.

Most cards resulting from Magnes will use magnetism in some fashion, which is a gameplay mechanic that is halfway programmed. The problem isn't quite so much programming it in (although that isn't trivial), but rather making it intuitive to grasp.

The idea is that units (or obstacles) can be positively or negatively charged, and every turn they will attract/repel each other according to basic magnetism laws. The simplest case would be two characters of different polarity attracting each other, or two with same polarity repelling each other, This could be used, say, to keep enemies close together to more easily hit them with AoE attacks, or to maybe keep dangerous foes away from your weaker units.

The problem comes with more than two units. If you had, say, one negative character and two positive ones, the negative one would be attracted to the other two, and the two positives would simultaneously be repelled from each other but also attracted to the negative one. What if the negative character was positioned between the two positive ones? Wouldn't the attraction forces pull in both directions at once and cancel out? And of course, this gets just stupid when you have a larger number of charged characters.

I will have to think a little more about the entire concept. Still, it probably won't be a very frequent mechanic, reserved primarily for the player and a few specific enemies.

I also spent some time solving some elusive Android bugs having to do, of course, with aspect ratios. But that should be solved now.

Not much more to say. Stay positive. (Although then you would attract the negative, so maybe stay neutrally-charged instead?)

[JustACicada]

Just a quick devlog to stop the radio silence.

Another functional area has been fully built. This one ended up being a little bigger than I expected it to be, but it's a plot-relevant area so it will do.

Named Teorema, it's meant to be a massive mountain chain that divides the peninsula where the game takes place in two. There are multiple monasteries along its peaks, now long since abandoned and not in the best of states. To make it trickier to navigate, a peculiar dragon with control over electromagnetism has decided to temporarily make it his nest, accidentally filling the place with magnetic obstacles.

All through the stage there are... I'm still not sure what to call them. Magnetic rods? They are loosely based on cathode rays. The idea is that each of these obstacles is magnetized with a certain polarity (positive or negative), and they cast up to four orthogonal beams around them. If the player is also magnetized they will interact accordingly, being repelled from rays with the same polarity and attracted to those of different polarity.

I've yet to prepare graphics for them, so for now they're just plain rocks.

This basic idea is spiced up with small additional puzzle pieces, such as using pushable rocks to hold your position and counteract attraction/repulsion, or having open pits that can only be crossed by throwing yourself at one of these rays.

When combining multiples of these, things can get stupid fast:

Additionally, entering battle while the player character is magnetized will result in the entire party showing that magnetization while in battle, repelling each other each turn and making many support strategies less practical.

Future plans involve areas with toggleable or pushable magnetic rays. Pure chaos, I tell you.

I also took care of writing some more plot dialogue and a few other behind-the-scenes things that are not terribly exciting to write about. Also, I never know how to end these devlogs. End.

[JustACicada]

Most dungeons for the next chapter are finished. Here’s one:

It’s supposed to be a dam of some sort. It’s quick and short, and it exists mainly as an extended tutorial for a peculiar magnetism-based mechanic while exploring that is expanded on later. It also exists because there are two particularly long cutscenes before and after and I wanted to sprinkle a bit of gameplay in between to make it more bearable.

It doesn’t even feature monsters or anything. Although I might put in a filler boss maybe. I’ll see.

Here’s another, more ordinary stage:

This is meant to be a mine, and it expands on the puzzles introduced in the dam. By this point in the game you can actually alter your own magnetism to control how you interact with the charged elements in the stage.

Traversal is not as straightforward, although to be fair it is basically a straight line. There’s also enemies everywhere and a few plot battles. You are actually supposed to come here earlier, but you lack the magnetism-changing ability so you cannot proceed further until later on.

All battles taking place in here will start with “Cathode rays” on the battlefield. They are a special kind of neutral obstacle that fires in all four directions every turn, hitting allies and foes alike. It does little damage, but it changes the magnetic charge of the units it hits. And many enemies in this stage will use cards that give them an edge against charged units.

Other than this, I also got the UI ready to allow swapping of skills while exploring. It’s one of those boring things that nonetheless needs to be done. It should also be compatible with Android, although that one I will need to test a little more.

I also finally got the mandatory quest system ready.

This system was born out of a need to distribute goodies to the player such as new card recipes or battle traits. This seems like the most reasonable way to go about it.

To keep things simple, all quests — called “commissions” in-game — are found in a single location, the Apothecary, which is essentially the team’s HQ. You are just helping the dwellers of the Apothecary with their problems, and they reward you with items and dreaded lore exposition (which you can skip, for I am not without mercy).

I’m still considering what types of quests to include. Fetching materials is obvious. Fighting specific minibosses might be another one. From there on, I will have to see what I can come up with that is relevant to the game’s specific mechanics.

And that’s most of it. I also made a bit of music (I think all music for this chapter is ready) and a few sprites for terrain/obstacles. I still have a significant amount of graphical work to do. But next I’ll mostly be focusing on finally making enemies and getting them ready to work.

I’m thinking of cats. Chess cats.

[JustACicada]

I’ve got quite a few new monsters working. Here’s some.

These are part of a family of creatures I’ve named “orebeasts” because I couldn’t think of anything better.

Battles in this game take place via cards, some of which are Weapon types (swords, spears, and the like), others are Specialty (classic magic and a few other oddities like herbs or poison), and there’s a last unnamed category for cards based on physical principles (gravity, space, time, etc). Normally these last few cards are only accessible to a very small subset of plot-relevant characters. Orebeasts are an exception.

Orebeasts, for some reason, have access to these rare cards. The real reason I avoided distributing these cards to enemies is because it’s tricky to get the AI working with them, since they often have very out there effects. But I got at least some of them working reasonably.

The quartz orebeast (purple) uses gravity cards to fling rocks at you or create gravity wells to attract you (and maybe later fling those wells at you). The electrum orebeast (grayish and green) uses electromagnetism to, well, to magnetize you and make it difficult to keep a stable position.

The kobolds! They are cute and have an interesting mechanic. I’m almost considering making them the mandatory “mascot mook” of Ubiquatopia, because no RPG is without one.

The idea behind kobolds is that the presence of each one contributes an effect to all kobold allies (including the user). Kobold scouts (green) increase movement of all kobolds, mages (blue) increase range of attack, and berserkers (red) obviously increase power. All of these effects stack, and disappear as soon as the offending kobold is defeated. These little guys are weak on their lonesome, but can get dangerous if they attack in big groups.

Future kobolds will probably have more dramatic effects than merely upping stats. Perhaps giving everyone drain? Shielding damage? Ailment immunity? So many ideas.

And that’s an amoeba. A gigantic one. It will clone itself when attacked, and sometimes even if you do nothing it will still decide to clone itself by sacrificing health just to spite you. You will want to take them out in few hits, but you won’t want to just sit idle and let them multiply either.

And now for the boring details.

First, I’ve worked quite a bit on the AI, and now the CPU should be able to semi-intelligently use some of the weirder cards. Such as the gravity card Fling, that requires you to target an obstacle within range and then decide on a direction to throw it at, hurting the first unit in its path. Now the AI will actually throw things at your characters, avoiding paths that would hurt enemies or end up crashing against walls.

I also made a quick and simple jumping animation for a leaping attack that I would like to reutilize with some other cards. It required genuine use of parabola equations, which is honestly the only reason I am mentioning this point at all.

Other minor notes: now enemies can be a bit bigger than usual (minibosses maybe?), and I prepared a few data-related things such as new cards to include, recipes, materials and enemy drops. I also improved just a little how my simulations work. Now I can just copy-paste the results on Excel!

Next, I’ll keep working on enemies, and maybe cards and quests. Next enemy tribe will be cats. Chess cats.

[JustACicada]

A few more monsters.

First, the axolotl.

These little fellows use a lot of poison cards, but don’t have that much firepower otherwise. They appear in an area with changing high/low tide, and while most characters have reduced mobility in deep water, the axolotl can move twice as far instead.

This is some form of lightning ghost. Or something. They do magnetism related things, and like to turn invisible to make your weapons useless.

And then there’s the cats.

This tribe of cats, the “grimalkin”, are based on specific pieces of chess. Here we got the pawn, the rook and the bishop. Now, most units in this game move by using their cards. Each card has a movement value, with stronger cards usually having lower movement to balance things out.

But cats don’t care about your silly human rules. The grimalkin just instead move however many tiles they want every turn, regardless of what card they pick. Most of them can move similar to their chess namesakes. So the rook can move any number of tiles but only in horizontal/vertical lines, the bishop can move any number of tiles in diagonals, and so on.

They use a lot of low movement, high power cards. But, again, they ignore the movement value of cards. Their movements are bound to predictable rules though, so it’s not too hard to plan around that.

On another order of things, bestiary:

Just a boring old bestiary. Simple but useful.

I have also been working on certain quests and whatnot. But that takes quite a bit of time and I don’t really have much to show for it.

[JustACicada]

I progressed a fair amount, so I thought I may as well share a few tidbits.

First, minibosses. I’m occasionally adding filler boss enemies that have no plot relevance, and are only there to test out a specific game mechanic or something. Such as this guy:

A retroactive boss added to Mount Psylumo (because that place really needed a boss at the end), and also teaches the player a very basic gravity mechanic: Fling. This guy hurls rocks at you in straight or diagonal lines. Its attacks are very predictable, but also very hurtful.

There’s another similar miniboss that plays around with electromagnetism. This one summons obstacles that fire in all cardinal directions every turn.

Of course, you can use cards that do all of these things later on.

On a different order of things, the material display screen will now show in which dungeons materials can be found. It was a pretty useless screen before.

I also finished drawing/emoting a few more characters that I will be needing this chapter. I think I’m only missing one more dragon character for one scene and then I’m done drawing characters for this chapter. (Although I still need a few more card and battle graphics)

Other than that, a few QOL improvements (I really need to create an “options” menu somewhere), and I got most gimmicks for relevant boss enemies working. Healing every turn? Working. Only receiving damage if it’s the unit with the greatest health? Working. Still acting at 0 health? Working.

What’s next? I’ve got one small final dungeon to prepare, just a bit more of dialogue to write (dialogue is like 95% done), and I’ve got to code in a few weird gimmicks for enemies in that last dungeon. I’m still not even sure how the final boss for the chapter will play out.

[JustACicada]

Most everything is ready for chapter 2.

All dungeons, cards and enemies are in, including their graphics. I also filled out the in-game chronicle a little for story events related to the new chapter. Commissions are done too. Materials and FOS levels are also ready, although those might need some more time testing and rebalancing.

I implemented (optional) healthbars. I’ve been meaning to do this for a good while now. I might still need to tweak their colors a little bit, though.

The collection screen now displays quantum cards (the cards that result from fusion in-battle), including their effects at different levels and the card categories needed to fuse them. On the topic of the card collection screen, it should now load more smoothly over multiple frames, instead of freezing the game for a couple of seconds on load.

Not many things left to do. I’m right now finishing up the last few graphics, and that should be all content done. After that I will have to test this, playing through at least a couple times and rebalancing as needed.

I don’t like giving release estimates, but chapter 2 should probably be ready for next month.

[JustACicada]

The second chapter for Ubiquatopia is finished and ready to download.

The new chapter has what one may expect, new enemies, new cards, new traits. I also implemented the new "commission system" (read: quests) to streamline a little the way certain rewards are earned.

Available for Windows, Linux and Android, which are the platforms I can test on. It's funny because I spent quite a few weeks trying to get this to work under Linux in the past and I ended giving up. But I tried it again for chapter 2 and now it just works for no discernible reason. I'll take it.

As usual, feedback and bug reports and all that fun stuff is appreciated.