The Boy Who Stole The Sun Archives - Can't Stop the Movies
Can't Stop the Movies

The Boy Who Stole The Sun: Devlog #6

New features! Whenever I get a new piece of the game implemented with minimal fuss, I have to celebrate and thank the central processor. On this update: there is a functional health system! The flurry critters have the ability to dash at the player and take his health away on collision. And casual non-dashing bumps between the flurries and player result in freezing up the player's hearts. The flurry also now goes into its "hurt" animation whenever it collides with the player, regardless of whether it's from a dash or a casual bump.

A friend also recommended I put in a screen flash to indicate when a heart is totally frozen. So I whipped that up this morning and got it into a functional state. Most of these features are in a testing state, not the final version by any means. But sometimes you gotta load up on features just to make sure they work.

Flurries are meant to be a low-level, easy-to-avoid critter that will probably only freeze the player a bit, and not be able to damage health directly. It's actually totally confusing to have it be able to do different kinds of damage with the same general action. Screen flashes are currently set to cyan for regular hits, and white for when a heart gets completely frozen. I will probably take out the cyan flashes later, but it's helpful to have things happen often when testing. And when you're coding solo, nobody can tell you not to make temporary features.

Hearts currently take 4 hits to deplete them, and 4 freezes to freeze them completely. And the player starts with 4 hearts, which means there's 16 total health points, and 16 temperature points. Remains to be seen whether all those values will be appropriately balanced.

Coming up next: Gotta get some particle effects in there for taking health damage. I think I'll probably do general impact effect for general hits, and a blood effect for when a heart is totally depleted. I want to be able to toss flurries into the water and freeze that square into ice. The game already tracks the drop-position in front of the player to make sure you can't drop something out of bounds. I can use that position to check the tile beneath and see if it's marked as a water tile. If so, I can do a freezing animation on it and re-build some data. In theory, this will allow for delightful puzzle solving and navigation options. I just have to make sure to constrain the possibilities such that the player doesn't have enough resources to build an bridge right off the edge of the map. Not sure if this'll be in the next update, but I may need to introduce the first tool to this game, and the give the player more than just bare hands to pick things up and mess around.

In the mean time, enjoy a little gameplay-in-progress video! Thanks for reading (and watching).


The Boy Who Stole The Sun: Devlog #5

Continuing on the path of the Vertical Slice, I have the first object scripted up that was on my list from last time: Snow Piles! One of the big benefits of coding up all the basic objects of the game quickly is that poor assumptions get weeded out.

For instance, I imagined the snow piles as sneaky ninja-containers. I wanted critters to pop out when the player least expected it. This turned out to be laughable in practice. As soon as I had the objects in the world, it became apparently that a pile of snow is in no way stealthy. It would have to be surrounded lots of other deep snow, and perhaps just be a pronounced drift instead of a pile. Even then, to be fair to the player, there would have to be some small announcement that a critter is going to emerge, to give time to react. Something like the Leever from the Legend of Zelda franchise fills this role nicely. But there was a more interesting choice to make here.

I decided to make the snow piles immobile and place them to block the path of the player. I made them punchable, which decreases the amount of snow in the pile. If the snow was reduced to minimum level, collision shuts off and the player can pass over it. But if the pile stacks up to the max height... punching it will unleash a Flurry critter. So, I got all that coded up, but not without unleashing some bugs in the animation and script command-handling systems.

Punching Snow!

One of the first bugs was with punching the snow piles. At one point, the animations were triggering the wrong frames, which made the whole thing look broken. After that, punching only triggered when a snow pile had reached a new personal best height. Anything less was un-punchable. That had to do with poor logic flow in the script. I looked a ton of code in the engine before realizing I had just written the script poorly, not turning collision back on in the proper places. There was also a segment where punching the snow only triggered properly on every second punch. That was also a collision toggling bug. After I got all these things fixed, there was a brief time where everything was suddenly broken. Program crashes... player starting the map in the middle of the water instead of the spawn point. Madness! I had to take the rest of the day off in order to return with a clear head.

All that being said... the basics of the snow pile are complete enough to play with them.

Future considerations: Need to determine spawning frequency. Right now the snow piles build up pretty fast, which is convenient for testing. After unleashing a critter, the object resets and can therefore spawn infinite critters. Will need to possibly make snow piles aware of the numbers of critters on the map. Perhaps they'll refuse to spawn more if the map is crowded. Also need to verify that snow pile collision is off during the frame where the critters are spawned. Right now it looks they're being shoved to the side, sometimes into the water, which is bad.

I had hoped to code up more of the Flurry behavior, but since I didn't get that... I made a video for you. Enjoy!


The Boy Who Stole The Sun – Devlog #4

It's snowing!

Cleanup! Got the last of my terrain integrations done from last time. The new terrain package files are already making the process of creating new maps more streamlined. Just to test it out, I whipped together a string of five maps and linked them together, and now I have a little test map with several increasingly dark caverns beneath it. I added some little stairs decorations to mark those spots. It's amazing how a few little graphics updates can be a feature feel fresh. While checking all this stuff, I ripped out all the old code and fixed a handful of errors and annoying features along the way.

Moving on! Time to plunge forward again toward The Vertical Slice. On the (relatively) short list of features to implement and test... I have three basic outdoor entities to create for the snowy, blizzard overworld. And three for the caves.

Outdoor entities upcoming: Snow piles! Flurries! Ice Beasts!

Snow piles: These spots accumulate snow whenver snow is falling. And when they reach a certain mass, they lie in wait for the player to pass by. When the boy is near... a flurry pops out and the snow pile resets to empty. However, if the boy punches the pile before it's reached max size, it'll knock some snow off and get smaller. This entity is 90% complete. Everything except the particle effects and the flurry spawning is done.

Flurries: These are creepy little snow critters which wander around and bump into the player. Each bump will freeze one of the boy's health points (like this: ). They can also be picked up and tossed around. The intent of carrying them is to be able to toss them into water and freeze the water making a little bridge. This entity is 50% complete. Still have to make them bump and freeze the boy's health points. And I have to figure out the water-freezing, ice-bridge-making situation.

Ice Beasts: These dudes are meant to harm the player's health directly. They have stabby ice hands. Their arms can be shattered with the right tool, but the arms can be re-attached. (In early phase of design, I had dreamed of making these guys spawn by way of five flurries hopping on top of each other, but I'm not sure I have a good way to do that. Gotta simplify, so I'll probably just manually place in the world for testing and see where it goes from there.) 0% done.

Cave entities upcoming: Ghosts! Crystals! Ghost Fire!

The boy and some of the critters.

Ghosts: These wandering spirits are humanoid and collect around sources of heat or light. When the boy comes near, they will follow the boy and attempt to freeze his health points and take his heat for their own! 25% done. I have basic graphics for these guys, but no behavior has been implemented.

Crystals: These are permanent cave fixture which can absorb light when a light source is near, and will hold and emit a low level of light for some time. 50% done. I have graphics and had a working version of these in a earlier prototype. Will need to re-implement them in current script system.

Ghost Fire: Blue fire which emits a ghostly lit. Other flamable object can be burned here. 10% done. Have graphics for this. Requires secondary flamable object to test this feature. Early prototypes had a little lamp that could be lit on the fire. Need to decide whether to keep and provide lamps in these levels or have other flammable objects provided. So this entity is actually a series of related objects that will play in the dynamic light system.

Other systems needed for The Vertical Slice: Dialog system! Health system! Sleep Cycle!

Dialog system is the one I'm most eager for, but it has a lot of piece to it. It needs a string system which can retrieve named strings from any language (the game will support localization to different languagues). It need a data format for storing the conversational data. And I need to define the behavior for displaying word bubbles and response prompts to the player. So far, I have the first part done, which is the named string/language system. I have the ability to display word bubbles, but the major part... the data definition, loading, and gameplay part is all yet to be written. So I'll call this 20% done.

Health Sytems: This will be display of little hearts, not unlike Zelda games. These hearts can be depleted by being hit or frozen by VeryColdThings(tm) that bump into the boy. Heart depletion will kill the boy. Heart freeze will kill the boy. 0% done.

A dimly lit cave. Need to get some light sources in here!

Sleep Cycle! When the boy dies in the other world, he doesn't die in real life. He just wakes up (Despite the nightmarish qualities of the magic world, this is not Elm Street). In order to continue the game, the boy must fall asleep. In order to fall asleep, the boy has to sort out his thoughts in a little mini-game before he can return to action. 0% done.

This is a chunk of work to get the Vertical Slice, but I'm pleased that tools are in order. I spent about 6 hours last week thoroughly debugging my scripting system Feeling good about that code and ready to make some critters come to life!


The Boy Who Stole The Sun – Devlog #3

Guardian Concept © Seth Gorden

Whew! July was rough. The tools update from last time has had some consequences in the clean up phase. While the tool for assembling terrain data was relatively simple to put together, the update to the loading code for maps that use this terrain data breaking a bunch of assumptions from the previous revision. Or rather, it would have been simple except that map data for the game and the editor are slightly different, and I have some work to do to make sure the terrain file loading goes smoothly in all cases.

As a brief aside, I have a little episode from the home life to share. It's part of the journey that things go poorly sometimes, and it's not always code that causes trouble. The problems revolve around getting a new roof put on our house. The positive side is that insurance is covering most of it. The downside is that it took WAY too long to complete the job by any reasonable standard. There were reasons given, and some of them were understandable, but the cumulative effect is that our house was under siege for a whole month. We didn't have access to our driveway or garage due to a giant dumpster parked there. We had some rain leaks due to portions roof being left in unsuitable conditions prior to stormy evenings. The workers often showed up late in the morning, and departed around lunch time or early afternoon. Many days they didn't show up at all. The worker team itself had a lot of arguments, and I'm pretty sure two workers quit as a result of all the yelling. After some calls to the company's owner, they applied some discounts to the project. That was nice, but there were continued communication and reliability problems all the way to the end.

Guardian Concept © Seth Gorden

Suffice it to say, this whole ordeal ended up triggering my anxiety pretty hard in the last week of July. The wife and I had navigated most of the upsets pretty well together in the first couple weeks, but that week was so full of disappointments that I buckled under the pressure and it got the better of me. Work was affected. Doing well again this week, but the recovery time is at least in part due to having support and accountability in place. I'm a pretty high-functioning anxious person, and a lot of the mental game of the condition is under control. But one of the sneakier side-effects is a hesitation that sticks around after these incidents. Which leads to getting stuck on decision making points. However... despite the stress, several important gameplay decisions got made last month... excited to share, and also excited to have a clearer plan for the player progress through the game.

One of the "Aha!" moments was deciding on having a series of guardians for boss encounters. From the early design, I only had one guardian encounter in mind, a giant bear, altered by uncanny magics to guard the Sun Stone which is our MacGuffin for the game. The Guardian at the end. When explaining this creature, and asking about how to mark out major challenges in areas between... my brother (kindly acting as a sounding board for ideas) asked me about the Guardian's origin. I explained that one of our major NPCs had created it. And his response was "If they can create one, they can create several. Just have a bunch of guardians." Seem so obvious  now. But at the time it felt like an epiphany. Of course there could be several. Sometimes when I'm bogged down in tools code, and wrangling things on a micro scale, some of the obvious choices for the macro scale elements can be missed.

Once this was decided, we went to work on figuring out how to make sure guardian encounters would be significant for both gameplay and narrative. The basics are that each guardian will be placed at the entrance to some area of exploration, rather than at the end. The choice to void violence as the primary language of interaction make boss design tricky. I don't think we can avoid violence entirely, but aiming for problem solving as the primary experience. We won't need to teach the player tools and weapons (Zelda-style) to lead up the boss fight at the end. Guardian encounters are instead going to block access to explorable areas. Each one will introduce basic gameplay and navigation concepts needed in the areas ahead, and will include a narrative-affecting choice during or afterward.

Guardian Concept © Seth Gorden

Specifics: each guardian has a power stone that it protects. The stone is not placed in a room. It is rather strapped to the animal itself and feeds power to the animal, distorting it from its natural state. These stones are essentially lesser versions of the Sun Stone we're after. These lesser stones will be necessary to unlock the path up the final mountain. When the stone is removed from a guardian, they will shrivel and be left in a state of suffering. The player can choose to move on from there, running off with the power stone and leaving the animal in such a state. I plan to include some audio of suffering noises (wailing, mewling, etc) that can be heard some distance off to play on the emotions and cue the player that the guardian encounter may not be quite done. They'll be free to ignore it, but I'll set up as much encouragement as possible to get them to investigate further.

Players who remain and explore will discover they can, mercifully or otherwise, kill a defeated guardian. But I wanted to dig into that further to see if it was possible to create a gameplay experience that hinged on the manner or attitude of killing a creature over which the protagonist suddenly has power. It's hard to distill abstracts into gameplay like that. But the idea that surfaced from discussion was the potential of setting the creature at peace before killing it, and that doing so would alter the dialog and story in a few controlled ways. It essentially amounts to an optional side-quest for the completionists. There'll be some backstory and details available to those who figure it out. We talked through several mini-game ideas, including some Ocarina-like song or rhythm elements. But ultimately decided upon some light interactivity and narrative feedback.

The game revolves around the idea of making murky choices without enough information, and letting the player feel their way through the narrative feedback they receive. I'm planning for replay value and I hope each of the paths being offered will have enough ups and downs to be a rich experience no matter what personality the player brings to the game. Easier said than done, but taking it a step at a time. The main thing is that now I have a map of encounters and a layout for the how the player will mark progress.


The Boy Who Stole The Sun – Devlog #2

Whew... holidays are crazy. Had a week of slow progress after the 4th. However, when it was time to dive back in, a tools task that had lingered there too long got my attention. There's a dialog in the map editor for hooking up the map terrain textures, and setting some flags for in-game use.

The old, busted terrain dialog. Functional for basic interaction, but buggy. Possibly in part because any changes to this data participate in the editor's Undo/Redo system.

The existing dialog is potentially buggy, and I want to be able to save its data to a separate file for use in other maps. Rather than update this feature in-place, I realized that it would be cleaner and easier to rip it out and make another tool for this purpose.

Originally, I had written this dialog into the map editor because I thought the terrain layers would be something that I would play with a lot and I wanted it to flexible. But that didn't turn out to be a use case at all. Once I setup the terrain layers on a map, I never touch them again. And if I want to make a new map with the same settings, I have to manually enter them all again.

So I managed to get the terrain tool written last week. It currently appears to be free of bugs (fingers crossed) and it adds a visual preview window that the original tool didn't have. So I'm feeling pretty good about that choice. It generates human-readable files, so I could type one of these manually in a pinch. Quick texture changes could also be done manually, if needed, without ripping apart the data embedded in the map file format.

I haven't ripped out the old version from the map editor yet, or done the other integration tasks that will make these files part of the game. But, it'll improve my iteration time and be more flexible in the long run if there are any changes to the terrain format.

The new terrain tool with texture preview!

The other significant bit of progress made was on the game design itself. I watched a ton of GDC 2017 videos in the last two weeks. A couple of my favorites were the Deus Ex postmortem with Warren Specter, as well as the videos on OwlBoy and Slime Rancher, which are all now on my Steam wishlist, just to see some of the cool features discussed in these presentation (or to replay the classic FPS/RPG mashup in the case of Deus Ex, cause I played and beat that back during its original release).

But anyway... the game design. I didn't cover much of the story for The Boy Who Stole The Sun in the first devlog, but I'll give a basic rundown here. It's about a boy who catches a fever. And when he falls asleep, finds himself suddenly arrived (Narnia-style) in snowy world where he has no knowledge of the land or its people. It presents an NES-styled top-down view of an explorable world, looking quite Zelda-like. There are a few constraints on this game's direction, though. No prophecies (thus no chosen one), no swords, and an attempt to provide a language of interaction that doesn't use violence as its base unit. No limits on danger or violence against the player, just that this would not be a journey about wielding or gaining power. There'll be some action and some puzzle solving, but I'm attempting to create an adventure that explores dialog and relationships as gameplay rather than as consumable narrative interlude.

Survival came up as the first basis for environmental player motivation. The protagonist will have to stay warm in a cold world. On the technical side, I wanted to experiment with dynamic light in a true 8bit color software rendering path, so I've designated a lot of room for underground environments that will depend on light sources for navigation. For a narrative motivation, I want to aim the player as a reasonably clear goal from the beginning, and then complicate the means by which the player achieves that goal. The main complication there will be issues of trust in NPCs who attempt to help or enlist your services.

The working narrative premise is as follows:
A talking crow will approach the boy, offer to be his guide, and then ask him to retrieve a powerful object from atop a mountain in order to save the world. A bodiless shadow will lure the boy to a celestial temple and dissuade him from listening to the crow, and that instead the power must be kept away from meddlers. The boy must navigate this merciless, snowy world in his pajamas, finding ways to survive, and determining who to trust for himself.

Another goal was to present a harsh environment where the player cares about the consequences of failure, and yet... to be accessible enough that the bar to entry isn't as high as games with permanent death scenarios. The working solution is to establish a waking/sleeping cycle for our fever-dreaming protagonist. Freezing to death (or other such demise) in snow world will wake the boy up in his room, perhaps shivering, the covers having fallen to the floor. Perhaps having fallen on the floor himself. And he must fall back asleep in order to continue his quest.

I hadn't figured out yet how to make that cycle valuable as gameplay, except that some bit of interaction would be required in order to fall asleep. But last week, my wife did me a favor and played sounding board, listening to my ideas and asking several brilliant questions that helped me sort out what to do with the waking/sleeping cycle, and how to integrate issues of trust through the game mechanics.

Full of Dialog and Mental Clutter. These notes are already out of date. But this was the first shot at describing possible content/effect of mental clutter. More on this next time.

The resulting solution turned out to be an abbreviated model of anxiety, which wasn't what I set out to create, but in hindsight seems a natural thing to have emerged. Dialog and other key events will be setup as emotional triggers for the boy. Triggers will carry an emotional charge and be added to a collection of mental clutter (including references to the triggering line of dialog or event). This collection will build up during play, and when the boy "dies" in the magical world and wakes up in his bed again, he'll have all this mental clutter with him. And before he can fall asleep again, there'll be a mini-game where the player gets to see a stream of these leftover thoughts, and must make value judgements on as many of them as possible before he can sleep. This mini-game will contribute both to the boy's stress level, and will affect dialog and critter behaviors in the other world when he returns.

After I wrap up integrations for the terrain stuff mentioned above, I'll test out the mini-game idea to see if it feels right for the metaphor being presented. Progress on this game has been slow and gradual, but it's heading toward a polished vertical slice- where basic features of the game experience are all present. It already has the basics of exploration supported for running around the snowy-world, and this mini-game will be a significant step in establishing the rhythm of the game. Stopping to fix things like the terrain tool sometimes feel like a distraction since that work doesn't immediately contribute to the vertical slice, but good tools will pay their dividends on every future iteration of content.

Not sure what I'll have done for next time, but I'm starting to think about character concepts and visual design for the critters I haven't sketched out yet. And I think I'll do an in-depth look at the mini-game, explaining the bits and pieces of that as well. Drop a comment if you have questions or feedback- Otherwise, see you next time!