Ghost Code (Wildebyte Arcades Diary)

Welcome to the article in which I explain/track my process for writing book 3 in the Wildebyte Arcades (Ghost Code).

As mentioned before, I wrote the many parts of the Wildebyte series before actually publishing the first book. I wanted to flesh out the world and see if the idea is actually sustainable first. (Also, it just helps marketing to release multiple books in a series in a short time frame.)

As such, I tried to make the first ~5 books very different from each other. Explore a different way to play a game, a different part of the computer, a different (crucial) game design lesson. This way, once I’d written these books, I would have at least thought about all the different parts of my world.

Keep that in mind as you read my ideas and decisions below. Also, SPOILERS, duh.

What’s the idea?

The first book was all about MEMORY. The second all about GRAPHICS. This one is all about CODE/LOGIC.

In the initial first draft of Wildebyte Arcades (which only lasted around five chapters), I mentioned the idea of “Ghost Code” somewhere. It just sounded cool and something I wanted to put in the first book.

What is Ghost Code? It’s when you …

• Write code for your game/program
• But disable it later (instead of properly removing it)
• Which means that, by accident, somebody else might enable it again …
• Which means the ghost code has come ALIVE!

This is more common than you think, hence the actual term for it. As programs get more complicated, lots of old code is being left behind and can accidentally be triggered again. (And lead to wasting days searching for why on earth your game suddenly started crashing. The answer is often the Ghost Code coming alive!)

So, great name, great concept to explore, how to make it work?

I wanted to ramp up the difficulty of the games as the series goes on. So I needed a really simple game for book 3, one of the simplest out there.

In fact, the game design lesson I wanted to add was basically “simpler is better”. Keep things simple. One of the biggest pitfalls for new game designers is that they overcomplicate their game, thinking it’s needed to create fun (or that it’s too boring otherwise).

This lesson is important. It also works well with the Ghost Code idea: what if I had a game that kept getting all these new features and updates all the time, because the developers were scared it was boring? Over time, this would lead to Ghost Code, which could come alive in the second half of the book to get a nice climax.

At the end of the book, they’d realize that the very first thing they coded—some silly little game—was all they needed.

Looking at my games list, I found the perfect candidate: Lumberjack. (Or, as I call it in the book, Lumbrjax.)

Many people know about this (very, very) casual game:

• A tree in the center.
• You can either stand to the left or right of it.
• Every time you tap the screen, you chop the next block, so a part of the tree comes down.
• You need to quickly switch sides to prevent tree branches from hitting you in the face (which means game over).

As always, I wasn’t certain if this idea would be interesting enough, but it seemed “good enough” to at least start with it.

While developing this, though, I remembered perhaps an even simpler game: Cookie Clicker. Now, I have no clue how to make a full story centered around Cookie Clicker. It’s just … you click on a cookie and a counter goes up. Pretty hard to dramatize.

So I turned Cookie Clicker into a recurring character and explored the idea that way. The character already surfaces in the book before this one, and in this one he gets his own storyline besides the main one.

The first scene

I like to think for a while about the best possible first scene. I am an improviser, which means that once I have my first scene, I just … go from there. Every day I write several chapters trying to create the best possible story on the spot.

But as they say: the first blow is half the battle. (Or a good start is half the work. Or with whatever variation on that saying you’re familiar.)

If I’m not satisfied with my first chapter, I often rewrite it until I am. Because I need that strong beginning to be able to improvise the rest of the story. (The other downside is that, after improvising, I usually have a long list of notes and plot holes I need to fix when I do my revisions. But it’s just how my brain works: if I already know how the story ends, I don’t want to write it anymore.)

What is a good first chapter?

• It introduces a clear goal + an obstacle (why they can’t get it).
• The goal is urgent: they must act now, because if they don’t, they’ll lose something precious.
• It promises what the rest of the story will be. (In terms of setting, ideas, mysteries, tone.)
• (If possible, it starts with a banger first line and intriguing ideas. But that’s no hard requirement.)

Ideally, you’d want some really high stakes. Something the main character truly, deeply cares about is being threatened.

I have learned, however, that this doesn’t really work in an episodic series where the main character is stuck inside a video game world :p You know they will not die. They jump to a different game each time, so it’s hard to keep a sidekick who might be threatened. They don’t plan on staying here, so they don’t have many other goals than escaping.

As I wrote down my issues with this, though, I realized I just found the key thing to explore: Wildebyte doesn’t plan on staying … but they’re staying for a while. Maybe that can be explored in this book? They’re pushing everyone away to get their memories and go home, but in doing so they turn all of Ludra more hostile towards them.

The plan

This resulted in a plan for the first chapter.

• Wildebyte lands in this forest area.
• They find many characters climbing trees, playing, etcetera.
• Until suddenly the new update comes—the rules of the game changed, many of them are stuck high in the air with no way to come down.
• Wildebyte is asked to help, but they just want to move to a different game that might have a Lost Memory.
• Until they hear “oh, and they say there’s some purple glowing object up there”—a memory!
  • Later, though, they reveal they said that on purpose to get Wildebyte to help, underlining their selfishness. Everybody in this game hates Wildebyte more and more. They start to feel lonely and, for the first time, get a thought like “maybe I need to accept I’ll be here for a while and treat this as my new home”
  • Finally, we can tie this idea back to the main theme of “simpler is better”, by creating this character flaw from Wildebyte who “wants too much”. They want to go to quickly, collect their memories too quickly, use their powers on everything (even when it’s not needed).

This is a fine start.

But it misses the urgency. Why would it matter that the characters come down from the trees? They don’t need food like in the real world, so what’s pushing them to rescue these characters now?

A better plan

Here’s a solution.

• In the center of this game world (which has no buildings, it’s just dense nature) is the Tree of Life.
• To prove their worth to Dev, their God, they must touch this tree and bring a sacrifice once in a while.
• With the characters stuck up high, they cannot do this, so now time is ticking.

To “explain” this, I can just start the first scene at this moment of sacrifice. Wildebyte witnesses this ritual, and then the update happens.

I also wanted to introduce the “Ghost Code” right from the start. It feels like a waste if it only appears in the end. So right from chapter 1, I want to show something odd. Something that’s not supposed to happen, but it does. Over time, this turns out to be such an instance of “ghost code”.

Finally, we need a way to continue from this first chapter. A pretty logical first plan would be to cut down the trees. Well, guess what, the update broke their axe. Now they need to make/find a new one.

The only real question is now: why on earth would you program a game in which characters need to prove their worth? And I think we can link that back to the developers putting way too much stuff into the game. They thought: “we can get the player to come back if we threaten to remove characters they haven’t used in a long time!” (This presents some opportunities to write a storyline about the dark side of mobile games, with in-app purchases and stuff. Maybe I can add that.)

The unpredictable updates that might ruin everything (coming from the developers) could be a tension that runs throughout the whole story.

Well, that sounds like a plan, let’s do that.

Chapters 1–5

Okay, so, I got sick for about a week. I try to stay productive anyway, just at a slower pace, because being sick has this weird effect: I tend to work even harder, but my head is all woozy and makes stupid decisions :p

So I wrote the first few chapters in what felt like one or two hours.

A quick revision

The next day, as I was recovering, I realized I made a lot of mistakes.

• The first “update” to the game adds “breaking mechanics”. From now on, characters can break, tools can break, etcetera. But … the previous novel was literally about a NINJA that kept BREAKING stuff. I don’t want to repeat the same conflict again!
  • This was my “explanation” for why the characters got stuck. They couldn’t jump to the ground anymore, as now there was “fall damage”. Yeah, pretty convoluted, not great.
• Similarly, the general trajectory was to find a way to climb the trees and rescue those stuck above. But for the NEXT book, I’d literally picked the genre of “endless jumper” games (Jelly Jump, Happy Jump, Rise Up, …). The general trajectory of the next book, therefore, would already be about “slowly climbing higher and higher”. Again, I want diversity, not the same general idea two books in a row.
• I didn’t actually show the general idea of the game. (We jumped straight into the conflict and the mission, which is fine. But it feels like a waste, not stressing the importance of being inside a video game.)

As such, when my sickness was (mostly) gone, I did a quick rewrite.

• A much simpler update: somebody added a sky to the game, but it was added between the floor and the characters, hence keeping them stuck.
• The “breaking mechanics” update comes the next chapter, but is much more limited: it only breaks tools. (So the main character has a broken axe and can’t just cut down the tree.)
• The first chapter quickly shows a character doing the core loop of the game.
• The general trajectory is about exploring the terrain (a dark, endless forest—or so it seems) and the different stuff the developers keep adding to the game.
• As I considered this, I realized a fun way to make that forest more interesting: turn it into a “fairy tale forest”. Throughout the book, there are loads of references to popular fairy tales (such as the big bad wolf, or perhaps a beanstalk is part of the solution at the end)

More realizations about Wildebyte Arcades

These are SPOILERS for upcoming books as well, so only read this section if you really want to!

As I stated before, I wrote the first ~5 books in one go to discover the best way to actually approach this project and this idea/world.

After working on this book for a bit, I had another “breakthrough”.

No, I will not have the Wildebyte think something like “maybe I need to accept that I’ll be here for a while and stop being selfish”. The idea of every “disk” is that it’s another game loop: Wildebyte tries to escape again, from the start, but can now try a different approach.

This means that, within each disk, their approach will stay the same.

Others might tell Wildebyte to stop being selfish. Or to accept they’ll be in this world for a while. But Wildebyte will ignore all that and tell them to shut it.

The more I use this approach, the more everything falls into place. The different disks and books get a clear purpose and (unique) structure. It becomes easier to “excuse” the fact that Wildebyte does not learn from mistakes and just jumps into a new game each time with the same purpose. Because they do not (or can not) change their tactic until the game loop restarts (when they enter a new “disk”).

Remember that this should be an episodic series! If I actually have Wildebyte learn lessons and change their personality/approach after a book … then order starts to matter and things get complicated.

So, for the Handheld Disk, Wildebyte will never (really) become less selfish/reckless or act in a way that’s more long-term (as they prepare to stay in Ludra for a while). Though there might be many storylines that ought to teach them :p

About Brumhilda

At first, I wrote Brumhilda’s fairy tale in one go, as “The Ghost of Brumhilda”. (They killed a character, then become a ghost themselves, and decided to grant wishes to whoever visited them.)

This, however, felt like I played my cards too quickly. I ramped up the tension/intrigue to 110% in chapter 2, which made it hard to continue, and also a bit weird why Jack would quickly trust a stranger called Brumhilda that suddenly appears.

So, instead, I broke it into two.

• Brumhilda used some sort of spell/wand for her attack, which is what they’re looking for. => This adds a clear goal and progression, without spilling all the beans.
• Later on, another character gives the other half of the story, explaining the ghost and the wish granting. => This ups the stakes considerably at a point in the story that makes more sense.

This also gave me the idea to generally explore the idea of “enchanted wood” (of which a “wand” is a prime example) in a story all about a forest and lumberjacks. Not sure how yet, but that’s the idea.

Implementing Ghost Code

As I … struggled my way through the first few chapters, I slowly figured out the shape of the story. (If you read my devlogs, you know this always happens.)

Firstly, I kept writing a new UPDATE in every chapter (adding something new). But that’s not actually what I need, and it cannot explain the mysterious disappearance of Apunza at the start. Instead, I need to also add updates (to the game) that DISABLE some previous mechanic. That’s where Ghost Code actually comes from.

I needed to find something I could “disable” in chapter 1 that, when accidentally turned on again (as a “ghost”), would cause the mysterious disappearances. Some simple, logical rule or line of code that I can reveal at some point. (Also, I decided to give these disabled systems a physical representation as … ghosts wandering around the forest.)

I settled (at least for now) for an explanation like this.

• The developers just keep throwing ideas at this game. So at one point, they added an “evil” section to random trees. When chopped, your character is turned into a ghost. (By paying a lot of money, you can get them back.)
• But players complained, so they disabled it again.
• When it accidentally got turned on again, the implementation was broken, so there was no visual indicator that a tree was evil. (Apunza chopped such a tree and disappeared.)

This would be WAY too much/in-depth to explain in chapter 1, of course. So I merely added a line saying “Read the full history of updates HERE”, so this is something we can discover in a later chapter.

Simple story, Convoluted game

To make my “game design lesson” work, the game in this story needs to grow incredibly convoluted over time. But … how do you do that without making the story itself also convoluted and hard to follow?

After writing a few chapters that just didn’t work, I settled on the following.

• Most new updates are directly attached to one of those fairy tales. (So once every 2 chapters, a new fairy tale is referenced, linked to rules of te game.) Because most readers will be familiar with the fairy tales, I hope this helps anchor the information in their brain.
• Wildebyte receives a mission/goal from each of them. He repeats his list of missions every time he gets a new one.
• We have a sort of “mini-climax” halfway the story (at which point Wildebyte will already have ~6 missions) in which it becomes too much. Wildebyte makes his story (the legend of Brumhilda) come true, Ghost Code is activated, we enter the second half of the story.

The repeating structure should help deliver information in a predictable way. By adding a big “midpoint reversal” halfway the story, I don’t have to continue adding updates/rules/fairy tales for too long. (If we continued doing so until the actual climax, roughly chapter 20, it would be waaaay too much.)

At this point, I’ve shown several times how characters in this game have no emotions. I’m planning to make that an update around chapter 10, to provide a catalyst for Wildebyte to go insane and trigger the second half of the story.

Finally, can we write?

This might have been the hardest idea I’ve ever had to whip into shape. Usually, I write a book 4 or 5 chapters a day, rapidly moving through the first version (and leaving any fixes or improvements for the revision later). This time? I wrote a chapter … had to revise it … had to write it again … had to revise the ideas … until I finally saw a clear through line for the story.

I did something I’ve never done before: after writing chapters 1-4, I didn’t add chapter 5, no, I inserted a new chapter halfway (and pushed chapter 3 and 4 one further, to 4 and 5). That’s the chapter where Wildebyte meets the collection of Ghosts in the forest. This felt like a tense/mysterious scene, but also something I wanted to show early on. (As the story is called Ghost Code and it constantly has metaphors relating to ghosts and stuff.)

I am learning a lot about writing with this project :p

I do hope later books are a little easier, when the game in which it takes place has a clearer (and bigger) structure. Anyway, with the insertion of that new chapter, we finally wrote the story until chapter 5 in a way that feels like a solid start.

Chapter 6–10

I executed the plan I just talked about. These chapters weren’t “easy”, but at least easier than the first five. I knew the structure.

• Keep adding updates (more and more convoluted) + disabling old ones
• Keep introducing a new fairy tale (related to what’s happening)
• While regularly adding some action scenes or continuing overarching storylines (such as Wildebyte’s memory or that Legend of Brumhilda)

I initially planned to have the “turning point” at chapter 10, exactly halfway the story. (So from then on, all the ghost code would come alive and we’d have a sort of prolonged fight until it’s resolved near chapter 20.)

Slowly, however, I realized this just wouldn’t work. 10 whole chapters of “climax” isn’t great. Similarly, I needed more time to set up some concepts and introduce some more fairy tales.

So the moment of the flip was pushed to chapter 12/13, and gradually weakened to a different type of “flip”.

Chapter 10–15

What different type of flip? Wildebyte realizes he actually is Brumhilda and he’s forced to fulfill his legend.

In other words, during these chapters Brumhilda actually turns into the villain of its own story. I don’t know if this is the best approach, but it …

• Naturally occurred
• Fits the setup I’ve done so far (about Brumhilda’s legend, for which I didn’t actually have an answer yet …)
• And felt like a fresh and interesting idea.

We follow Wildebyte as he is forced to destroy character after character, bringing their fairy tale to a negative conclusion (as the evil queen/godmother of all of them). We also follow him lie about this to his one and only real connection or friend in this game (Jack), who is very clear about not trusting WB at all.

(I also discovered one of my favorite funny characters: Empero. From the fairy tale of the Emperor’s New Clothes, who believes he’s holding a weapon because everybody tells him he holds the most beautiful weapon in the world :p)

This continues until a few betrayals happen (shortly after each other), which leads to Wildebyte … losing? He’s killed and turned into a ghost.

This, again, felt like a more interesting and unexpected series of events. The original idea was simply that Wildebyte finds a way around Brumhilda’s legend and saves the day in the end, but that felt cliché and repetitive. I also didn’t see how I could resolve all other mysteries that way.

Instead, Wildebyte turns into a ghost, which (to me) seemed the perfect situation for activating the ghost code idea. WB tries to save the game (and themselves), activates all the other ghosts, and in doing so activates all the disabled systems in the game at once.

This actually incites the climax: fighting against all those messy systems coming alive, while trying to save the game.

Chapter 15–20

The actual “solution” was already set up early in the story. It’s one of the few things I actually knew beforehand:

• Wildebyte crashes the game
• Which sends an Error Log/Crash Report to the developers
• In which he writes a message telling them to remove all the updates and messy code.

I just had no clue how to get there. No idea. There were so many open mysteries, characters, storylines, possibilities.

In the end, I kind of muddled my way through. I wrote a few chapters every day—all the while telling myself “this is shit, this won’t work, this surely needs an edit”—until I got through this.

A few key realizations were as follows.

• I needed all the characters to die and turn into ghosts. As long as many of them were still alive, the story was too messy, and it also felt like the stakes were too low. Sure, Wildebyte is now a ghost, but there are 10 other princes and princesses that can fix the game right?
• I’d made several jokes about Players having to pay to get back characters or access certain functionality. So let’s reuse that: they can revive a character by paying a high cost (1000 Wood). This gives a clear goal: chop as much as we can and start reviving people we need. (Clear goals are really necessary, especially when you’re at this point in the story.)
• The whole story keeps repeating that characters don’t trust Wildebyte. So let’s explore that topic further. Let’s see what happens when people do trust him, let’s fail one of WB’s plans, etcetera.

And so we got at a point where the story only needed 3 or 4 chapters, and then it should be done. But I had no idea how to write that ending. I merely wrote on my to-do list that I should write that ending tomorrow.

Standing in the shower that evening, I saw the solution. I decided to write that and write down tons of notes about how the rest of book should be changed to lead into that ending.

The ending

In the end, this book is about …

• Trust (and Wildebyte’s bigger relationship with the rest of the device)
• A simple game that got blown up (the design lesson is to keep things simple and focused on one clear game loop)
• Which is about lumberjacks cutting trees (while avoiding branches)

So let’s end with that!

• Once the new update comes through (and the developers listened), the whole forest is gone, and there’s just one tree left.
• Wildebyte’s Lost Memory is at the top of that tree.
• So Jack needs to actually play the original game to cut the tree and get the Memory down.

To me, this might even be a more tense climax. If they make one mistake, if Jack gets hit by even one branch, it’s game over and you need to try again. So, hopefully, the reader is at the edge of their seat to see if they manage to succeed and deliver the Lost Memory.

I played with the idea of failing here. But that would not be satisfying: the point of the story is that Wildebyte chooses himself over everyone else. So yes, he will have his Lost Memory, whatever it takes. He’d rather get his memory than save the game.

So … he plays one last trick. He uses the forced trust Jack has in him to cut down the tree and deliver his memory, while promising that the tree will regrow and it’s fine. But the tree does not regrow.

Wildebyte has their memory—but the game is literally empty and done for.

Furious, they kick Wildebyte out and threaten to erase them.

If it ended there, of course, it still wouldn’t be satisfying. Fortunately, during the story, I already set up that Jack … was from the fairy tale of Jack and the Beanstalk. So he has these seeds, and when he plants them, an infinite beanstalk grows that allows the game to continue.

So yes, the game ends well.

But Wildebyte is kicked out again and hated even more across the device.

I saw that as a solid mix between “satisfying conclusion + something to lead into the next book”.

About the cover

As usual, just a quick note about the cover. I keep running into the issues that games are usually landscape, and book covers are portrait. And the issue that games usually have simplified graphics and indicators (to make gameplay less vague and the screen easier to parse), which doesn’t always translate well to a still image.

This time, I pulled even more tricks out of the bag to make the cover work out.

I combined multiple images of trees, shrubs, roots, etcetera to get a sort of forest landscape in portrait. (I even sinned and stretched one of those images to be much longer, otherwise there was a gap. Distorting image dimensions usually looks ugly, but this time it somehow looked fine.)

I added all the characters, including shadows and recoloring to make them fit the scene better. Only major characters get an outline—giving them to all felt like overkill, especially those characters hiding behind leaves. (Another cool trick: clip your image so that a part of the terrain is in front of them. This instantly increases immersion and believability that they are truly inside that scene.)

I played around with adding clouds until I had something that looked nice enough. (I considered adding actual ghosts, or adding the characters stuck in the sky, but it just felt like too much.) This is achieved by …

• Drawing random blobs.
• Then adding blur to that entire layer
• And clipping them so sometimes they’re in front of the tree, sometimes not. (This looks way better and more realistic than, well, not doing it.)

Rinse and repeat for several such layers, all positioned differently (rotated, scaled, different transparency, etcetera).

Then I realized I’d forgotten to actually illustrate the game and/or story.

• I added some particle effects to illustrate hitting the tree and stuff flying.
• I littered the floor with tree trunks.
• I placed a heart symbol and score on the tree. (I’m going to keep adding the same number for each score—048—as I might be able to do something with that …)
• I gave some people axes.

I really don’t want to make these covers too busy or too childish. But I do need them to be colorful, and rich. (The Wildebyte series hopefully stretches to 20+ books. I don’t want all their covers to look roughly the same :p I need to set a precedent with these early covers! In fact, I might be too safe now and need to experiment more with wacky covers.)

And I want them to illustrate the game somewhat well, without being too obvious or too “gamified”. I’m trusting my gut on these things and adding elements that seem to fit until I feel it’s “done”.

Conclusion

This book was hard. The start was rewritten several times. Then I had to slog through the middle and the climax, all the while finding no inspiration for how it’s supposed to flow or end.

But I always tell myself: just keep writing. Keep getting those ~2,000 words each day until you have a finished first draft. You can improve all those mistakes and cliché scenes in later drafts.

As such, I finished the first draft in roughly 10 days, but was left with multiple pages of in-depth notes and major changes to make.

• I think there’s room for more fairy tales and expanding some of the tales I already have.
• Some tiny mysteries I setup … never actually got resolved. Some of them should be removed, others slightly altered so they fit within another storyline.
• I loved the ending … but the first 10 chapters of the book don’t really set it up.
• The prose is a bit bland in some places. (That’s what you get when you don’t know where to go and aren’t in the zone.) Let’s write a bit more creative, imaginative, “fairy tale like” sentences.
• And more like that

The difficulty when writing this novel is revealed when you look at my “routes”. I always write with the idea of “routes”: 4 or 5 storylines that are constantly pushed forward in every chapter. (One such route, for example, can be “ghost-code”: pieces of information given to the reader about how this works, once every few chapters.)

With this book? I stopped tracking routes altogether halfway through, because I just didn’t know what I was actually working towards.

When doing the second draft, I rewrote the set of routes and actually tracked them for each chapter. This revealed that the first draft was a huge mess, but the second draft much cleaner and more focused.

This is, again, a very different novel from the first two. I’m still trying new ideas, approaches, writing techniques—all to slowly build the Wildebyte world into something that can prosper. This will probably continue for the next handful of books.

Is it good? I never know. I’m a perfectionist and never satisfied. Is it good enough to publish? Yes, after a second and third draft, I think it is. (Also, my goal was just to write fun adventures, so I’m fine with lacking a strong dramatic arc or deep meaning—as long as the action, characters and interactions are regularly funny.)

Until the next diary!