Sunbluck

Welcome to my devlog for the game Sunbluck. It was made for the Godot Wild Jam 72 in a few days, which is why this devlog will be rather brief. Nevertheless, I want to talk about the process, any interesting challenges or situations, and anything else that seems worth sharing.

What’s the idea?

The theme of the jam was Light and Dark.

The extra wildcards, which are completely optional, were

  • Dynamic Perspective (“Use more than one camera in your game.”)
  • Curses (“Difficulty increases with powerups”)
  • What the Duck (“Include at least one duck in your game.”)

I only entered the jam a few days late, because I was finishing another jam first and then I wanted to take a break for a day. This meant I had only a few days, while the actual jam lasts 9 days.

From the start, I had one idea that seemed promising. An idea that was different from what I’d made before and could fit all the requirements.

But the next day, when I woke up early to start working on this, it was the hottest day of the year (in the Netherlands). It was so hot that I couldn’t even stand behind my desk and do nothing, because I’d break out in sweat and feel light-headed.

As such, I ditched the idea for something that seemed smaller and more appropriate for the current time of year. What was that idea?

  • You run a beach, tourists arrive.
  • You have to keep them in the shade by constantly moving the parasols and positioning them correctly.
  • As the sun arcs across the sky (morning->evening), changing the shadows all the time.
  • Because if a tourist is exposed to sun for too long, they burn and you lose a life.

Simple enough, right? Wrong. Always wrong :p

My personal challenges

But first, let’s see which personal challenges I invented for myself.

First of all, I wanted to learn from my mistakes with previous game jam games.

I’d often have an idea that only worked once all 5 systems for the game were operational and connected. This meant I couldn’t really test/play the idea until the final day/hours before the deadline, which isn’t great. It also just meant a lot of coding and a constant fear that I might not finish in time and the game couldn’t even be submitted, because it couldn’t even be played.

Instead, in this game, I wanted every “main system” or “main mechanic” to be completely standalone. Each of them can be enabled or disabled, and the game will still run and still be a closed game loop (that is somewhat fun or challenging).

For example, if we turn off the Tourist system, it will just spawn X tourists straight into the level and do nothing else. If we enable it, tourists walk onto the beach from off screen, and they come in waves/timed events, and they actually do what the full game intended.

Similarly, if I turn off the Sun/Weather system, then the player itself will simply be the light source. And so you can still test and play the game.

I’m writing this from the future, of course, and I can confidently say that this was a great approach. I could test the core loop as soon as my shadow code was done. I could test a new system with everything else turned off, and the game still played (like a game). This made it easy to really focus on one system, iron out bugs, and only then turn on the next one. It also gave me new ideas for the game itself, because I was forced to consider “but how would this still work if we DON’T even have tourists!?”

Secondly, I would suppress the urge to make it local multiplayer or to push myself in all sorts of corners because I want to add too much content. Of course my brain immediately went for it: oh but what if we have different types of tourists? Tourist A could do X, and B could do Z, and then, and then—no, keep it simple and contained.

Similarly, I really hate creating or having UI elements in my games. I often work really hard to remove all of that, or to make the information a natural part of the game world. (For example, instead of displaying lives as a number or hearts in the top-left, I’d put a shader on the player that degrades over time to show their health degrading.) It’s better, in most cases. It’s also a lot more work than I can handle in such a short time period.

Let’s just keep this simple idea a singleplayer experience, and it’s fine to put some interface elements (such as health and money) on top of the game world.

Day 1: Getting a core game loop

How to detect if I’m in shadow?

This was the first thing I needed to test. If I couldn’t make this work, or it would be too expensive too calculate, then the whole idea would be moot.

There are many ways to try and solve this problem.

For example, to check if an object is in shadow, you could …

  • Enable physics in your game, giving everything somewhat fitting physics bodies.
  • Then shoot a raycast from your physics body ( = the tourist) to the light ( = the sun).
  • If it hits anything else in between, well, then your body must be in shadow!

Or you could let the game engine (in my case, Godot) fully simulate the light and shadows (with actual light sources and occluders), then do some shader magic—hoping you have access to the right things—to pull out the areas in shadow.

You could even test the literal pixels on the screen. If a tourist is surrounded by mostly really dark pixels, they are probably in shadow, right?

All of these might’ve worked, but I cast them aside rather quickly. I needed to both accurately display those shadows, as well as really cheaply check if tourists were within them or not. (Potentially for many parasols, of many different weird shapes, at the same time.)

I wanted to keep the game light and not resort to physics. (If possible, always do it without physics. Otherwise you add a lot of overhead and an entire class of extra possible bugs for … nothing. For example, teleporting bodies is a notorious problem that physics engines just can’t handle well. But without physics—such as in my game—I can have stuff teleport/move as I please!)

The game would have a day/night cycle, so testing for “dark pixels” on the screen would be incredibly imprecise at certain times.

No, I quickly decided I should just do the shadow casting myself, in the absolute simplest way possible.

  • Parasols are defined by a polygon. (I created a Resource for some basic shapes, such as triangle/rectangle/circle, and it just picks one of those.)
  • For every light source, the ShadowCaster …
    • Draws a line from the source to every point (or “corner”, or “vertex”) of its polygon. This is basically the “light direction at that point”
    • Then it extends the point in that direction, by as much as some max shadow distance I defined myself.
    • Now we have a second polygon that defines the shadow area. Make it transparent black, display it underneath the umbrella, and you’re good to go.

@TODO: IMAGE OF THIS??

Now, of course, there are some edge cases here. For example,

  • You must also include the original points of the polygon, otherwise the shadow will “peter pan” ( = it’s detached from its original shape, because you’re only drawing the extended points)
  • But now you have a mess of points that are in the wrong order, and some are unnecessary (such as edges facing away from the light)
  • As such, I use Godot’s Geometry2D.convex_hull to find the smallest polygon around this mess of points.
  • That actually creates a somewhat realistic shadow very cheaply, in most situations.

But despite those tweaks and extra realizations, the core algorithm is quite simple and fast to compute.

Moreover, now we have the literal polygon of each shadow. As such, testing if a tourist is inside it means nothing more than calling Geomtery2D.is_point_inside_polygon on it, supplying the tourist’s position and the shadow polygon we calculate each frame.

In practice, this means at most 50–100 loops through very small polygons (only a few vertices) every frame, no matter what else happens in the game. This is no problem and I also didn’t encounter any accuracy issues at this point.

After an hour or two, I had parasols, shadows, and a debug label telling me it could accurately detect if tourists were in shadow or not :p

Getting the systems up and running

This is always a bit messy, as there’s so much to do, and my hyperactive brain keeps jumping between places. But after a few hours, we get through this.

All the major systems were now operational, both standalone and together.

  • Tourists would arrive in waves, growing in difficulty over time.
  • Parasols would spawn, and you could pick them up and drop them. (Obviously, a player character can run around and do all this.)
  • The sun arcs across the sky and the game modulates colors (and sun intensity, for example) as the day progresses.
  • Tourists either walk away when done, or they get burned and you lose a life.
  • And when they day is over, it just waits for a second, then starts the next one.

The game loop is closed, it is playable, and it’s already quite a challenge.

At this moment, the game looked like a gray mess filled with the default Godot icon as the placeholder for everything. That’s how all Godot games start :p

I wanted to at least sketch the general graphics and map layout I’d need, but I suppressed the urge to start making things pretty now.

Instead, now I could test the game loop and really see what it needs. My observations were as follows.

  • The core idea is a strong one. Because the sun moves during the day, you can never just place a parasol and forget about someone. You always have to move and reposition stuff. This means the game, even in this simple form, has urgency, no down-time, and always a challenge.
  • Picking up the parasols and putting tourists in shadow is quite satisfying. The way the shadows cast is also very clear and intuitive.
  • It’s annoying if you move close to the edge or things spawn close to the edge. (You can’t see a tourist’s health or if your parasol is the right way. Same thing for the sun: I should add an indicator for where it is at all times.)
  • The idea easily scales to more tourists, more parasols, juggling more things at the same time.
  • But it’s also missing something.

The extra spice

The game was already a game. And if I tweaked the numbers, it was already a challenge. I really had to keep paying attention and stay focused, otherwise I’d fail quickly. And all that with just one rule: move around with a parasol and keep tourists in shade.

The problem is that the sun is a directional light. Every parasol will cast a shadow from the same direction, making the process quite uniform: “place your parasols, ten seconds later the sun is on the other side, now move all your parasols slightly to the other side of their tourist”.

There must be some things to shake it up. I needed one or two more clever ideas to really make the game tick.

  • The first idea was rotation. We have these nice random shapes for parasols. This also means that you can rotate them to catch more or less shadow.
    • This worked great and will stay in the game.
  • The second idea was luring. When tourists pick random locations, you’re unlikely to ever catch two or three of them with the same parasol. But if you could somehow lure them, or herd them, or change where they will sit … you can make that happen.
    • I initially coded “luring” as an alternative for when the entire parasol system was disabled, and you therefore couldn’t grab/move parasols. That’s how I got the idea for this solution in the first place.
    • As such, I already had the code for this and could test it immediately. This also worked great, though there had to be restrictions on it, such as luring costing a coin.
  • The third idea was simply messing with scale. Make the parasol bigger! Make tourists smaller!
    • This was part of the finetuning process.
    • But I also realized I could implement those powerups in this way: perhaps there was one that, if visited/used, would scale your parasol to be bigger.

All of these ideas were fine. I, however, want to stay minimal and relate everything back to the core unique idea of the game: the realistic shadow casting. I brainstormed about how I could make all these changes directly related to the lights and the shadows.

And that’s when I had my breakthrough:

  • These powerups are all scattered across the map, randomly spawned or generated. (Getting more parasols happens via that shop powerup, growing your current one would happen through visiting one, and so forth.)
  • To grab the powerup … you must keep it in shade for a while.

Now the same core mechanic was used for everything in the game. You really need those powerups to survive longer … but it means devoting at least one of your umbrellas to a powerup, which means it can’t be put on a tourist. (Conversely, there might be a powerup that’s bad and you don’t want it. But it’s right next to a tourist! Now how do you position the umbrella to not accidentally grab the powerup too?)

This was simply way more cohesive and streamlined than doing the typical “you get the powerup by visiting it/walking through it”.

Ending the day

At the end of that first day, I already made the map look like an actual beach. Just simple colors, dividing it into land and water, which also made it possible to keep the player on the screen. (I check if you’re about to leave the bounds of the playable area, and if so, you wrap around to the other side.)

It’s not much yet, but it already looks way more fun and professional now than the static gray background.

I also lost a lot of time here because I initially coded it in a weird way. And then I did so again. On my first try, I finally realized the simple solutions to my problems (such as how to get a wavy/somewhat random shore line) and it all came together.

I drew a few quick icons for the UI I’d build tomorrow, and also to settle on an art style. Then I wrote a part of this devlog and went to bed.

Day 2: Still Hot

Didn’t sleep too well because of the heat. But anyway, no time to lose, let’s get going again.

The necessary UI & Fixes

I made the UI, nothing special about that.

The game now actually has a game over screen, you can see the time of day and how many lives you have left, etcetera.

I also fixed some major things about the game that bugged me while testing it last night.

For example, now you can place parasols inside tourists. Which is often all a player will do, because, well, the closer they are, the easier it is to stay in shadow right? But it’s boring and it looks ugly. Even worse, I currently only checked if the center of the tourist was inside the shadow cast, while I should check if their entire rectangular/circular body overlaps.

These things aren’t much work, but they simply remove the most annoying or uninteresting aspects of the game (in its current state).

Powerups & Progression

It was finally time for that extra spice. And actually being able to buy more parasols and progress to later and later days :p

For the most part, this was nothing special.

  • The spawner simply checks how many powerups are on the field, and if it’s less than some minimum, it adds more.
  • I discovered I already had a perfect place to explain each powerup: the little area of green at the top (the “tree line” in my code). You can’t visit it, nothing else spawns there, yet it’s easily viewable. A great place to put little fences explaining what specific powerups do.
  • Every powerup is its own Resource, with only 5 lines of code on average. (The powerups all execute simple actions, so their unique code really only has to call the right function or connect the right two variables.)
  • For now, it simply adds an extra tourist for each day, and tourists yield a random number of coins (between a min/max I set myself).
  • I created some simple images/modals for when you go to the next day or when it’s game over. (I decided to not make it automatic: you have to press the button that you’re ready for the next day. I noticed players like this little breather—which my previous similar game didn’t have—and it’s a natural moment to do it.)
  • I quickly picked colors and drew recognizable icons for the powerups.

With that done, the game was “done” in the sense that it had a finished core loop that was bug-free and close to the original vision.

Time to let someone else test it!

First rough playtest

My little sister spent 15 minutes with the game. This, as usual, showed many areas of improvement. Fortunately, it also showed that the idea was working quite well. It was easy to grasp and play with.

The biggest issues were as follows.

  • The numbers weren’t balanced/finetuned. (Parasols too cheap, earning too much for each tourist, etcetera.)
    • Solution? This is just a matter of tweaking and playing a bit more myself.
  • While holding a parasol, you often couldn’t see yourself. This made it hard to know where you stood, and if you stood too close to a tourist (which forbids placement).
    • Solution? Make the handle longer, so the parasol shape is further away from you.
    • Also check if any entity is behind the parasol shape, and if so, fade it out a little bit. (We have all these polygons and point-in-polygon checks anyway, so it’s easy to reuse them like this.)
  • Similarly, it’s a bit … hard to tell if your parasol is actually doing what it should. Because there is no extra feedback/animation/whatever that tells you if a tourist is in shade or not!
    • Solution? I should prioritize clear feedback and signs to tell the player these crucial details: if something’s in shadow or not, if you’re in placement range, if a tourist is leaving or not, if you’re holding an umbrella.
    • Simply adding nice tweens and an outline to the parasol (on grab/drop) already does wonders.
  • I tried a few different levels of “input complexity”. For example, you can play the game while rotating/dropping parasols with an extra key (spacebar), or I could disable all that and you only need to learn the arrow keys.
    • This clearly showed that having the spacebar is better. Being able to freely rotate/drop parasols and lure tourists is far more interesting; without it, it almost feels as if the game imprisons you, restricting the player too much. As such, I’ll just have to be smarter with my tutorial so I can explain this extra control to a player without overwhelming them.
    • Solution? Spread the tutorial over the first few days. Write the instructions in the sand; don’t start time until they’ve all faded into view.
  • The game stagnates a bit over time. The things you’re doing are slightly too repetitive and same-y. For example, I got the feeling that you should lose a parasol once in a while for some reason, otherwise the beach just gets fuller and fuller until you have no clue what you’re doing anymore.
    • Solution? This was the hardest to solve, as it’s about core game design principles, instead of superficial mistakes or effects.

And when you feel something’s missing, or just a bit “off”, it’s usually a combination of several factors. In this case, I made the following changes.

  • The beach became bigger, tourists and player smaller. (Simply more space to move, less cramped, less tourists hiding underneath a bunch of parasols, less repetitive movement in a small space. At the same time, luring and rotating now becomes more interesting, because you can actually get multiple tourists in the same shadow.)
  • When you try to activate a powerup but it fails (usually because you lack the money), that’s when it becomes a CURSE. It executes itself, but inverted. (So, “Gain a life!” becomes “Lose a life!” and such.)
    • I’d been trying to find a good way to mix powerups and curses for two days now, but found everything convoluted or just not fun. This idea finally did the trick, because I saw (in the playtest) that my sister often accidentally activated powerups because she wasn’t paying attention to that portion of the beach.
  • The powerups system was broken in the playtest, though, and testing it again while it actually worked already helped a lot.
  • Every time you lose a life, you also lose a parasol. => This was the simplest rule I could come up with at the time to also lose something once in a while.
  • The weather system. At some point, I looked at my list of ideas and noticed half of them were themed around weather. So I renamed the Suns system to Weather and gave every day varying weather conditions.
    • Different peak heat.
    • Different number of clouds that will temporarily block the sun.

Or, rather, I planned to do most of these things tomorrow. So let’s skip to that moment.

Day 3: Things are coming together

Tutorial

I implemented that tutorial system. I always want to do that relatively early, because it

  • Always takes more time than you think …
  • Is more important than basically anything else, because if the player doesn’t understand your game (within 30 seconds), they won’t play …
  • And it is a good measure of how simple your game is, and/or where you should simplify further.

If I can’t get you playing within 1 or 2 simple images/instructions, then I want to reconsider what I’m doing.

I’d never done something like this before: placing the tutorial completely in the game world, and just stopping the current level/wave/day until it’s displayed fully. (But allowing the player to roam around and try the things explained already.) That’s also why I was quite motivated to work on this first.

It’s not that hard to make, while I still feel it is one of the more superior methods for tutorials. Very simple, very interactive, very natural.

@TODO: IMAGE OF THAT?

Weather System

For the most part, this just picks random numbers. (For example, the heat of the day is a number between 0.5 and 1.0, and that ratio just scales the burn factor for that day. There is no other logic of algorithm there.)

The clouds were the most interesting part. When I conceived the idea, I strongly felt that it would do the game a lot of good.

  • At this moment, the sun is always shining and anybody not in shadow is always burning.
  • But with clouds … there will be varied (but predictable!) moments when the sun is blocked for a few seconds.
  • This creates much-needed variety and possible strategies.

That’s why this was the second item on my list of priorities.

Because I still didn’t want to use physics (or overcomplicate the game), I used the following trick:

  • Clouds simply store a straight line from their left edge to their right edge.
  • The sun knows its vector between itself and the center of the screen. (It arcs around that point and rotates to face it already.)
  • So we ask Godot’s handy Geometry2D tools if those two lines intersect. If so, the sun is blocked, and everybody is considered to be “in shadow”.

The cloud itself simply spawns on one edge of the screen and travels to the other. When off-screen again, it destroys itself.

Fixes & Completions

By this point in the project I always have a lot of @TODO notes scattered across the project. Many tiny bugs to fix, many pieces of code that should be expanded or written in a cleaner way, many questions about whether to change some number/variable somewhere.

For example, the money you get from a tourist was just random at the start: 1 to 4 coins. That’s what you do when you’re just prototyping a game for the first time: cut corners, make everything random or “whatever” just to get it going. Now that the entire game had taken shape, though, I rewrote the code to change the reward based on how burned the tourist is. (And to keep it within certain bounds provided by my big config file, to prevent tourists rewarding negative numbers in weird cases :p)

So I went through all of them and fixed most of them. Yes, most. Some ideas I had two days ago were just bad or irrelevant now, so I removed the note an did nothing else. A few things were still uncertain, so I left the notes in.

I also added my final ideas for powerups to the full list, “completing” that part so to speak. (I usually add some powerups that end up being disabled anyway. But I just want to try everything and see what sticks. It’s easy to write a new powerup in 10 minutes, test it, see it’s rubbish, then disable it. It’s much harder to know what the “best powerups” are just by brainstorming or thinking about it.)

Of course, my brain instantly jumped to “but what if we also add 10 different types of tourists!?” and “but what if we have 5 different types of parasols with their own properties!?”

And yes, these would surely make the game more interesting. A tourist that constantly repositions/moves around requires a new strategy. A parasol that is “shadow locked” is also a nice break from all the others that rotate with the sun.

But it’s also a lot of work and an explosion of scope. I want to keep it small, I don’t want to work 24/7 on these game jam games. Thus, I wrote down these ideas, but didn’t actually do any of it.

For this jam, all tourists and parasols are just the same old regular thing. The only system with more content/variety are the powerups, because that was one of the optional requirements of the jam.

Day 4: Finishing

Polishing: Sound

This day started by adding sound effects, some background music, some more shaders or decorations to make the beach look more alive. The usual polishing that takes a few hours but simply makes the game feel so much more alive.

I decided to record an upbeat Spanish/tango song (with my Spanish guitar) as the background music. Because it fits the summer/beach vibe and it’s something I can actually do with my very limited means. (I just have a tiny old guitar and I record all this with the terrible speakers from my tablet.)

When I was done, I realized I could just record the sound effects too with the guitar, so I kept going and was done with all the sound in about an hour. As I always say: I am actually a musician first and foremost, so this is the easy and fun part :p I can come up with nice melodies on the spot, I know all the tricks to get weird sounds out of a guitar, and it sounds better than it should on such terrible hardware.

Polishing: The Rest

To make the game look a bit better, I used some more shader magic. For example, the shadows used to have extremely hard edges, because they were literally just a polygon drawn by the engine.

Using a shader, however, I can use a random noise texture to get wobbly and fuzzy edges. This looks far more realistic and less amateurish/harsh.

Similarly, a shader adds some gradient and movement to the water. All other details are just sprites randomly placed and oriented, after I drew a few rocks and other beach decorations.

Aaaargh

As usual, when you do things for the first time, you’re going to make mistakes.

I lost a lot of time doing some shaders and decoration work for the overall map … then doing it again … then doing it again. Every time I made a new mistake, or had a new oversight, which taught me I had to approach it completely differently. It’s obviously frustrating when that happens. You feel absolutely demotivated, unable to redo the thing you just did for an hour. At the same time, if you take a short break, you realize you’ve learned a lot from this challenge and can get back into making a better version.

Similarly, all sorts of issues cropped up with my “interactive tutorial”. For example, now that there were decorations (or powerups) on the beach … they could cover the tutorial image on the floor! This made it annoying (or simply impossible) to read. And so I had to add an entire new system to hide anything that might get in the way for as long as the tutorial was visible, then make all that reappear when the tutorial was done.

And then, when testing the game with everything mostly done, I realized we had some (potentially major) game design issues.

  • The first few days can have quite some “downtime”. You have a parasol for every tourist, nobody else is arriving, so you have nothing to do for 5–10 seconds.
  • At the same time, I often lost as early as the second day, because of the enormous variation in heat and burn speed and such from day to day.

I had to work a bit more on the progression of the game to fix both issues at once.

  • At the start, the heat of the day doesn’t fluctuate much, and days are much shorter.
  • Only as you progress (day 3, day 4, day 5, …) do the really hot and really cool days appear, and do they grow to their final duration.

This finally made the game quick and easy at the start, yet challenging as you went further.

I thought I’d be able to have quite some free hours this day to take a break and enjoy the sun, but I was wrong :p I lost a lot of time on all those mistakes, all those issues I’d never seen before because I did something I never did before. I even started to fear I’d run out of time at one point.

Polishing: The most important bit

I couldn’t delay any longer: I had to start drawing the actual ducks for the players and tourists. Those were the only sprites missing at this point.

I barely have any experience with animating animal characters, which is both why I dreaded this part … and why I wanted to go for it and learn from it.

In the end, I think they look fine, if a bit simplistic and wonky. It fits the general feel of the game. It would never pass the test in any more realistic or serious game :p

A few marketing assets, a few final tweaks to numbers or visuals, nothing interesting.

And then the game was done.

Just in time, because the GMTK Jam started that same evening. Being a far shorter (and perhaps more prestigious) jam, I knew I needed all my time for that.

Polishing: Game Rules & Playtest

As I worked on the game longer, some more opportunities for improved rules showed up. That’s typical and I always hope they come, because the day before the jam deadline I always feel like my game is “meh, not quite there yet”.

I realized I had a bug in the scaling of the “forbid radius” on tourists. Now that it scaled properly, the game was obviously less frustrating to play, because the forbid radius you saw actually matched the real one (and is smaller).

I made the lure distance bigger and I decided to make the action cost 1 coin. Luring is pretty essential if you want to go past the first few days. Making it cost a coin assures players don’t just spam the action and helps balance the money flow.

I made the reward for a tourist depend on how burned they are—but then I forgot that their burn timer keeps updating as they walk away from the beach. This means they might actually be 50% burned … but when they leave, that has already dropped, giving you more coins than you deserve!

After fixing all those tiny errors or miscalculations, I thought I ended up with the proper difficulty and money in/out flow.

Honestly though, for a game jam, I don’t think many people will play long enough to actually get to the point where most powerups and money management matters. People give your game 30 seconds and continue.

It’s a shame. I once saw a judge (from quite a big, prestigious jam) test my game on stream, literally not read the single line of instruction, complain about not understanding the game for 60 seconds, then turn it off and give 1 star because they “didn’t see the connection to the theme”—even though all other players gave the feedback that the theme was so well and creatively used. Yeah, not great.

So no, I don’t make all these improvements and keep the game interesting for longer for the jam. I do it for the game and to make it much easier to build it into something slightly bigger and more engaging in a future update.

Finally, I snuck in one final quick playtest.

  • There was one major bug that I’m glad I caught. (I coded that “whenever it’s cloudy, everything is considered in shadow”. But I completely forgot that this messes up the powerups, because now they auto-progress when it’s cloudy, which can often lead to curses/inverted powerups you don’t want!)
  • When a tourist stands on top of such a powerup, it’s way too hard to juggle. I should make them avoid those locations.
  • A little more breathing room at the edges of the screen, otherwise easy to miss a tourist.
  • A more violent explosion animation (in the sense of: easier to spot/draw attention) when a tourist burns, otherwise players miss it.

These are, as always, really tiny/quick tweaks and fixes. But they change the game from “pretty annoying to play” to “actually as intended”.

This is also perhaps one of my biggest gripes with video game development. One misplaced comma, one wrong number, and the whole game just crashes or becomes severely less playable. It’s so … fragile. You’re always worried you forgot something, or accidentally changed a number somewhere (especially with terrible hardware like mine that sometimes repeats keystrokes or hangs on mouse clicks), and that game you spent days crafting … is completely unplayable to most.

Boardgames are less fragile in that sense. If material is missing, or a rule doesn’t make sense, the player can just decide to do something else to make the game work. (In fact, people even do that when nothing is wrong with a game but they just want certain house rules for fun :p)

Conclusion

Another game jam, another game done from start to finish!

I’m proud of the things I’m making and how far I’m able to take those. I’m also still not sure if this is something I want to do full-time.

As stated, video games are fragile. And there’s always a pile of work, even on the simplest of ideas, and you never know it it’s going to be fun until you try … and then try something else … and iterate on the idea five times until you’re sick of playing your own game.

I think this game ended up quite good. It’s a shame that I’m not great at animation or visual effects, but at least I was able to learn a little bit thanks to this project. The core loop is simple and engaging, tense and challenging from the start. At the same time, it’s really hard to even make it past day 7, and perhaps the game became a little too challenging :p

But that’s fine. That’s already ~10 minutes of solid gameplay out of a product that took ~3.5 days to make.

I would’ve loved to create something more different than what I usually make. And I’d actually planned that! My original idea for the jam (which was something else entirely, until I pivoted because it was extremely hot in the Netherlands) was different. So it’s more or less an unfortunate accidental event that I didn’t end up making that idea. Hopefully, my next jam (the final one of this summer) provides this opportunity to do something radically different.

Even if not, simple ideas that you’ve partially done before still provide new challenges—always. I thought I’d be done a day earlier with this game; I ended up scrapping certain ideas and saying “enough is enough” just to get it done in time.

We finish the game, we send it in, we get a good ranking but never win, hopefully some people found some enjoyment in it, and we move on with life!

Keep playing,

Pandaqi