#nullawesome

I have decided to start work on implementing enemies. Enemies are entities representing characters who actively try to harm the player or hinder their progress. I made the decision to devise enemies with relatively complex behavior with a finite state machine wherein each possible enemy behavior is represented with a state. States -- defined in EnemyState.java -- include the following:

INERT -- enemy should not move

IDLE -- enemy should remain stationary or patrol an area

ATTACKING -- enemy detects the player and should attack, either close in or at range

SEARCHING -- enemy has lost the player after detecting them, but it knows the player is around, and should actively search by moving toward the player's last known location, giving up after a certain amount of time is spent in this state

HOMING -- enemy has lost the player, and its search timer has expired. It must attempt to return to wherever its "home base" is and, once home, return to the IDLE state. However, if it sees the player while in this state it may go back to ATTACKING.

HACKED -- electronic enemies such as robots can be hacked in this game, just like everything else with a CPU. Hacking enemies triggers a certain behavior, which can vary but of course invariably results in helping the player. The HACKED state may or may not be indefinite, and may or may not trigger a special control mode to allow further control of the enemy (depending on type of enemy).

This opens up a ginormous problem space. Even simple enemies with a single behavior -- say, Goombas and Koopas from Mario, who only know how to walk left and fall off ledges, or walk left and turn around when they reach a ledge -- must track a lot of state. There are frame counters and timers for their respective animations, variables for whether they detect an obstacle, optionally variables for whether they detect a ledge, etc. Each enemy behavior is backed by its own state machine. So what I'm proposing is actually a hierarchical state machine -- a top-level state machine which controls which of several second-level state machines are active. Yeesh!

Thankfully, it's tricky but not impossible. And implementing the core bits has proven far more pleasant than I'd feared. Again, I am quite surprised at how lucky I get by making good decisions at the beginning -- things like choosing appropriate data structures. The EnemyInfo entity component has a field called script which basically holds an enemy's state graph: the possible states, the possible transitions between those states, and the conditions under which a state transition would be triggered (implemented as Criterions). This forms an entire "script" for how an enemy's behavior evolves throughout its lifetime -- hence the name. The individual behaviors for each state are in the EnemyInfo's stateActions field.

Ever since Mario exploded into a media phenomenon in the late 1980s to early 1990s, game companies have been trying to capitalize on that success by introducing their own mascots starring in their own video games, starting with Sega's Sonic the Hedgehog from 1991. Well, it didn't start with that game, but that was the game that really kicked the mascot craze into high gear and produced a character which could (at the time) challenge the dominance Nintendo and Mario enjoyed.

But the thing is, a mascot really only works if it stands for something. Mario not only represented Nintendo as a company, his games stood for the values Nintendo was widely considered to stand for: fun for the whole family, games for all ages and skill levels. Even Sonic, despite mainly being a big ball of attitude, represented the marketing angle that Sega was taking to compete with Nintendo, producing more complex and more importantly, edgier games that appealed to a late-tween to teen demographic. But really, at the end of the day what does Mr. Nutz represent, besides shameless me-too-ism?

Okay, I'm getting off track. The point is, after Mario and Sonic blew up among the public, every game company felt the need to develop a mascot platformer of some sort. Usually the mascot was a Sonic ripoff -- some sort of cartoon animal with "attitude". These ranged from the interesting (Rocket Knight Adventures), to the merely bland (the aforementioned Mr. Nutz), to the downright awful such as today's subject: Bubsy the freaking Bobcat.

The truly flabbergasting thing about Bubsy is how bad his games are. Every single one of them -- and they just get worse and worse, culminating in the God-awful, franchise-ending cascade of fail that is Bubsy 3D. But they're competently coded; they don't glitch out like, say, Cheetahmen. They're just -- nearly any time the designers had an opportunity to make a game design decision, they made a bad one. Strangely enough, that makes Bubsy a useful learning tool for aspirant game designers like me.

Everybody should play Bubsy to get a sense of what these games do that's so fundamentally wrong. We take good game design principles so for granted that sometimes it takes a bad game -- like Bubsy -- to get us to notice them because they're missing. Just go ahead and track down the SNES version or -- I hear the first couple of games are out on Steam now, so I dunno, you can go get 'em from there. Just play through the first few levels of the first game, Bubsy in Claws Encounters of the Furred Kind. It won't take you long to find the fail.

For one thing, the game messes with your ability to anticipate danger. It just seems like everything in this game is designed to pop out of nowhere and kill you. Other platform games -- such as Mario and Sonic -- have level layouts that let you spot and react to an enemy or obstacle before it poses a real threat. Not Bubsy. For one thing, the first Goomba in Super Mario Bros. is two full screens away, giving you plenty of time to anticipate his arrival. The same goes with the first Motobug in Sonic. Note also how it takes a while for Sonic to build up to his full speed over level ground, so even if you remain at ground level, you still have plenty of time to anticipate the Motobug and jump on or over him. And the game distracts you with a 10-ring item box up on a ledge, so if you go get that, the first Motobug will miss you entirely (but you will still see him so you have some idea of the peril that lies ahead).

Bubsy? The first enemies (plural!) are in the very next screen over from your starting point. Notice how Bubsy is poised when the level starts, like a runner on his mark, ready to book it. The game encourages you to go fast, in a manner like Sonic. Bubsy himself has a steep acceleration curve. He goes from zero to booking it in like two seconds. With the huge sprites in this game, that means he's probably going to run smack into those enemies before you have time to react to them. The game encourages you to go fast and then immediately punishes you for doing so, pointing and going "Ha ha!" like Nelson Muntz. You simply cannot go full speed in this game without paying a heavy cost. You don't even need to touch enemies in order for them to kill you. One very common enemy can literally kill you by sneezing on you. Another problem is that the camera waits for Bubsy to reach the top before scrolling up, or the bottom before scrolling down. This makes it hard for you to see what you will land on when jumping, bouncing, or falling -- and you could land on an enemy (insta-death) or water (also insta-death) without realizing it. If there's a ledge above you, you may not know what's on there until you land on it. Could be nothing. Could be an enemy, or a crate full of thumbtacks. Normally these games are designed to encourage exploration, so that if there's a platform up high somewhere, the player will want to climb up there. But in Bubsy, the levels are laid out in such a way that any route the player may wish to take is fraught with nasty surprises -- and the player won't know what's there until it's too late to respond. That's bad design.

It gets worse. There are secret tunnels throughout the level, and some of them go straight into water without you having any way of knowing -- or doing anything about it once you've committed to taking that route. You just gotta memorize which ones go where -- which is hard because all the entrances look alike -- except the ones that have manhole covers which can kill you.

Another way this game fools with your ability to anticipate danger is there are innocuous-looking things which are actually quite dangerous. For example the manhole covers I just mentioned, which flip around to periodically open and close certain pipeways, but can also kill you if they hit you. There are also the famous gumball machines which shoot tiny, barely visible gumball projectiles that kill you in one hit. They look a fair bit like the halfway marker in Sonic, or at least like nothing that will kill you. But they will. So you have to watch yourself when you encounter anything that looks unfamiliar in this game. In one part of the game, all of a sudden and for no reason, there are yellow cars which endlessly respawn. They're large and they move pretty fast, so of course you have to have Jedi reflexes to anticipate them but they can be killed. Then there are the red convertibles that look almost exactly like the yellow cars -- except when you follow your instincts and jump on them the way you did the yellow cars, you become trapped inside and die.

Did I mention you die in one hit? Because -- yeah, you die in one hit. Touching, or even sufficiently approaching, an enemy kills you (unless you land on top of it with sufficient accuracy), a gumball from a killer gumball machine kills you, water kills you. Seriously, water kills you. Why? Because cats don't like water, HURR HURR. Never mind that some breeds of housecat love water; and bobcats are excellent swimmers. Nope, they just decided to make water deadly for an easy cartoon gag. Not even Sonic did this; Sonic sinks like a stone because of a false belief that hedgehogs can't swim, but water isn't immediately deadly to him and the underwater parts of Sonic stages have interesting (if challenging and frustrating!) mechanics. But in Bubsy water is deadly. Except when it isn't. Falling from a sufficiently great height kills you. Seriously? Falling damage in a platformer? I swear I've died for reasons I couldn't guess, like falling off a rollercoaster in the fourth level. After restarting on a fresh life, I was unable to replicate this death. Strange. The controls are some of the worst.

The controls are simply awful. Basically, there's no implementation of momentum that maps to anything in the physical world. Bubsy accelerates to full speed from a standing stop before he travels one screenful; and he screeches to an immediate halt once you let go of the control pad. Oh, except if he's on a grade in which case he will walk, automatically, at a pretty good clip, down towards the bottom of the hill. Sometimes, when running up a grade, instead of slowing down the way Mario or Sonic might, he will speed up. When he jumps, it's even worse because of the wonky mechanics around what I call jump aftertouch. Jump aftertouch is the ability -- pioneered in Super Mario Bros. -- to steer the character's trajectory after they jump. Bubsy has very unresponsive jump aftertouch -- even worse than Sonic. Unless you jump from a standstill, you are pretty much unable to steer your midair trajectory. And even you think you are jumping from a standstill, you may not be because of the rule about automatically running down slopes. If your takeoff point has the slightest grade to it, you may drastically overshoot -- or undershoot -- your jump, sending you careening into an enemy, or water, or a red convertible, or whatever other hazard lurks just beyond the screen.

All of this is invalidated, of course, if you use the glide. Why does Bubsy have a glide move? It doesn't even appreciably slow his descent. If used it prevents fall damage, it allows much better control over Bubsy's jump arc, and it increases the size of his hitbox for collision detection purposes when he's killing an enemy. (His hitbox is always huge when it comes time to determine if Bubsy is killed...) It's more of a "fix what's broken about jumping in this game" button. Why not make jumping not broken to begin with and give Bubsy some other move? Maybe a dashing scratch on the ground and a homing pounce from the air? Super Mario 3D World with its Cat Mario power-up gives you better cartoony cat-themed gameplay than does any Bubsy game.

And all of these flaws -- poor level layout, the inability to make sense of just what is a hazard in Bubsy's world, the wonky camera, the janky controls, the fact that everything freakin' kills you in one hit -- would be bad enough on their own. Separately they would have made the Bubsy series a mildly annoying, but forgettable artifact of 90s mascot mania. The seething hate for Bubsy comes from the fact that they all occur together and reinforce each other, creating a stacking effect of frustration.

I won't even get into Bubsy 3D. Not only because it brings terrible to new heights that I don't wish to contemplate, but because NullAwesome is a 2D platformer and I want to focus on aspects of 2D gaming that Bubsy is a negative example of. This isn't really a rant about how terrible a game is -- angrily nerding out about video games is plentiful elsewhere -- it's a dissection of why that game is terrible, so that lessons can be learned about how to make my own game good. Or at least not sucky.

Lesson 1: The player should be able to see well ahead of them. Turns out, I really don't know that much about how cameras work. Careful study of Bubsy's terrible camera -- and the really good camera dynamics from Super Mario Bros. -- convinced me that I should not let Lorn get further than halfway across the screen -- in either direction depending on which way he's headed. The way the camera works in Mario is really quite interesting. The screen starts scrolling when Mario is about 1/3 away from the left edge -- but at a slower pace than Mario's walking speed, allowing Mario to continue advancing across the screen until he reaches the halfway mark, at which point the scrolling matches his speed and he remains horizontally in the middle of the screen.

So a good camera system that doesn't let the camera lag behind the player character and prevent the player from seeing what's ahead is paramount.

Lesson 2: Hazardous things should look hazardous. Why does water kill you? They had lots of options: lava, spikes, poison, bottomless pits, nuclear waste, electricty -- and they chose water?! This lesson is a reminder to myself to carefully choose tiles for environmental hazards that really communicate the sense of "hey, you really shouldn't touch that" to the player. They should stand out and be sharp and pointy, or glow menacingly, or sizzle, or crackle with electricity. The same goes for the enemies: I want to avoid putting in any innocuous-looking, but quite deadly, gumball machines. In Mario, anything with mean eyes that's coming at you is probably bad. In Sonic, all of the enemies are robots, so if it's mechanical you probably don't want to mess with it.

I have two main enemy types planned for NullAwesome: Altean guards and robotic drones, with a few subvariants of each. I think I actually want to go one step further and make all of the enemies conform to a specific color scheme, one which contrasts with Lorn himself and matches the ZetaCorp logo -- just so that when the player sees those colors, they think "enemy".

Lesson 3: Put enemies and hazards in the player's way, but not in their immediate path.

So which seems more fair to you? This:

L = Lorn E = Enemy # = Ground = = Elevator ==== L E E ##############################################

Or this:

L = Lorn E = Enemy # = Ground ==== = = Elevator ==== E E ######################## ######################## L ######################## ##############################################

In both scenarios, once you're at eye level with the enemies, they can spot and shoot you. In both scenarios, the player can see that the enemies are in their way and they must defeat or evade them in order to pass. However, in the first scenario, the player will encounter the enemies simply by walking right. The second scenario puts the enemies up on a ledge, so that the player can't easily stumble onto them. They can stay on the lower level and have a good think about what to do. They still have the same need to overcome the enemies in order to continue, but this time they can choose to engage the enemy on their own terms. Messing with the player's ability to think, plan, and choose is death for your video game.

The same goes for hazards. Again, which seems more fair? This:

L = Lorn # = Ground ! = Lava ## ## L ##############!!!!!!!!!!!!!!!!!!########## ##############!!!!!!!!!!!!!!!!!!##########

Or this:

L = Lorn # = Ground ! = Lava ## ## # # L # # ############## ########## ############## ########## ##############!!!!!!!!!!!!!!!!!!##########

Maybe the player can stumble into enemies and hazards in the later levels, when they've mastered the controls a bit more. But in the early stages at least, it's better to keep the player out of danger until they've decided to engage the danger by moving forward.

Lesson 4: Surprises in the game should be pleasant. Unpleasant surprises should give the player at least 1 to 2 seconds to react.

"Pleasant surprises" are things like the invisible block that yields a 1-up in Mario. "Unpleasant surprises" are things like being transported to a room full of enemies with the door locked, and you have to defeat them all to get back out. If the player comes across an unpleasant surprise, the player should be given a) a way out, and b) time enough to assess what's going on and react accordingly. Unpleasant surprises that kill the player instantly are to be avoided altogether.

This isn't really a hard and fast rule. An unpleasant surprise that kills the player can be fun in a troll game like Portal, old-school text or graphical adventures, or "kaizo" platformers. But in order for it to be fun, death has to be cheap or otherwise not frustrating. In kaizo platformers, the extreme difficulty and high risk of death is supposedly part of the fun. But in Bubsy, the game goes along relatively consistently (by Bubsy standards anyway) then WHAM! You're killed by a... gumball machine? Or go into a pipe that leads directly into deadly water or something. That's just bad design.

Since NullAwesome is not a kaizo platformer, cheap deaths should be avoided and deliberate tight spots should be carefully designed to give the player time to think and react. If the player is taken by surprise, it should be with rewards and not punishments.

Hi folks. Sorry I've been gone this long while.

You know Yandere Simulator? That idiot game where you play a Japanese schoolgirl and have to sabotage and/or end the lives of other Japanese schoolgirls so you can be with your "senpai"? Fun fact: the YouTube video series made by that game's creator inspired this very blog about the development of my stupid game. I mean, I don't want to hold him up as a hero or anything because he's kind of a jerk, his game is poorly coded and he doesn't seem able to commit to a plan or even a scope for his project, instead spending all his time messing around with what interests him at any given moment.

But look, I'm not really here today to rant about that guy or his game. I'm bringing them up by way of analogy. See, in Yandere Simulator, you're supposed to dispose of your rivals to get the boyfriend, right? Well, the developer of that game has been putting off implementing the first rival, Osana -- because while faffing about with Unity and premade assets is easy, actually implementing a set of real game mechanics is hard. I know, from experience. In developing NullAwesome, my "Osana" has been the modal UI. The plan is to have a player tap a button to enter "hack mode", and then tap an on-screen target to initiate a hack. Hack targets would be determined by entities with a HackTarget component. But in order to do that I would have to implement each mode in terms of UI display, and of response to touch events, as well as a way to transition between modes.

Without the hacking mechanic, there is no game. Hacking, like Jar Jar, is the key to all this. And hence getting this modal UI correct, in a maintainable way, is also key. By putting this off I've essentially held up development of the entire game. I really have no excuses for this other than that this was always a spare-time project for me.

The approach I've chosen is to have a state machine which is globally accessible through a slot in the player entity's PlayerInfo component. There are four states: TITLE, MOVEMENT, HACKING, and PAUSED; these are specified in the InputState enum. The ButtonRenderAgent will draw different UIs depending on the current state, and the NAView will respond differently as well. This is necessary because no actual UI controls are used in-game. Buttons are just bitmaps drawn to the screen, like any other sprite; input events come in the form of touch events to different areas of the screen. All determination of whether a button is pressed, held down, etc. comes from determining whether the input event falls within that button's bounding box.

I suppose I could go the route of implementing what amounts to a UI framework in game, creating button objects and objects which represent different active UIs. But for the small number of states, and small number of buttons, what I have so far appears to work fine.

I'm proud to say that after months of delay (I make no excuse for this), I've started to move the needle on getting this implemented. A transition from the MOVEMENT state to the HACKING state is possible by tapping the hack button; by tapping the (currently invisible) back button in the upper left corner, you can return to the MOVEMENT state.

Things have gotten complicated. I have enough of a game there to stop faffing about with adding elements higgledy-piggledy to a test level and actually start doing some level design. I want to get this game in front of test players as soon as I can so I can get feedback on, you know, if it's any good, how I can make it better, and so forth; and for that I need real levels even if they're in an early, rough form. The problem I'm confronting now is just how much I suck at level design.

Part of the problem is, that lovely JSON format I devised for level layout makes it difficult to visualize a level. So that brings me to the first new dev tool I'm using.

NA-Builder

NA-Builder is an ongoing effort for a level viewer/editor for NullAwesome. It is written largely in Gambit Scheme, with some bits in C; and structured so that I can start with the simplest bit, a JSON parser, and gradually add components on top of that until I have a full-fledged graphical editor.

But alas, I'm nowhere near building the editor. So instead, I settled for an image generator that uses the JSON parser to read a level file and spits out a map of the level in XPM format. Then I have some Emacs Lisp which allows me to send the current buffer to the map generator and opens the resulting image in a separate buffer -- so at the stroke of a key, I can view the results right within Emacs. This considerably quickens the feedback loop when I'm editing a level by tweaking the JSON directly. It works well enough for now.

NA-Builder is not yet ready for wide release. Maybe someday.

Waydroid

The other dev tool I've been making use of is not of my own authorship, but I got it working well enough for normal use.

See, the problem is, the Android emulators that ship with Android Studio suck. I have added keyboard support to the game so that it is easily playable on PCs, Chromebooks, and other devices. But the Android Studio emulator's keyboard support is... spotty. When you hold down a key, it appears to send key-press/key-release events to the app very rapidly, resulting in herky-jerky character movements and an inability to jump with any precision. But when I tried a commercial PC Android emulator like BlueStacks, everything was hunky-dory.

A lot of time has passed, and a fair bit of work has been done. Here are the highlights:

Enemy behaviors are more sophisticated, and more closely resemble what will be in the final game. The enemy now patrols an area when in the IDLE state, and gives chase when ATTACKING.

Line-of-sight detection has been implemented for enemies, allowing them to see you. Whether you are seen by an enemy is established by two criteria: direct line of sight (with no solid tiles intervening), and whether you fall within the frustum of the enemy's vision -- that is, are less than a certain distance away and fall within a certain angle above or below horizontally aligned with the enemy. The frustum may be changed on a per-enemy basis. This adds an element of stealth to the game; since you have no weapons and cannot attack directly, engaging enemies is generally A Bad Idea. You'll have to outwit them and use your expert-level hacking maneuvers to deal with them.

The same line-of-sight code above is used to permit Lorn to hack only targets he has a direct line of sight to. This means that hacking enemies will be fraught with more risk; and you may have to e.g., solve a puzzle before you hack a terminal behind a closed door.

Oh yeah! There are doors in this game. They can be opened and closed by linking them to a HackTarget. When closed, they actually put solid tiles on the map (so that movement and line-of-sight code treats them as solid); when they open, they turn those solid tiles into blank spaces. For obvious reasons, they can only be placed to align with tile boundaries.

There is also a new type of entity called a collectible. Collectibles are things you pick up, like coins in Mario. There are lots of ways you can do this, you can offer rewards for getting a certain amount of them (like 100 coins/rings give you an extra life in Mario/Sonic). You can make them power-ups that either act right away or charge a power meter for some sort of special move or something. The way I chose was inspired by Dangerous Dave. (I will stan for John Romero until I die.) Dangerous Dave had two major kinds of pickups: trivial pickups, in the form of gems, that only increased your score; and essential pickups, in the form of a chalice. There was one per level and it was a prerequisite for clearing the level. Collecting the chalice would open the door leading to the next level. There were also a couple of power-ups.

So the way collectibles work in NullAwesome is there are three kinds: I call them Trinkets, pieces of Intel, and Keys. Trinkets are like the gems in Dangerous Dave, or the strawberries in Celeste. They serve as proof that you were there, so that you can impress your friends and intimidate your rivals with your l33tness. They don't have any impact on gameplay except how you are scored, but you can't 100% the game without collecting all of them. They are shaped like things such as floppy disks (probably filled with garbage files), Nemesis controllers, cassette tapes, etc. I always thought it was funny that there were so many early DOS games that had you collect floppy disks instead of coins or whatever.

Intel is much more central to the game. It represents secret information about ZetaCorp that could incriminate them, so it tends to be put in secure locations. You can find it either lying around on CD-like discs or by hacking and logging onto certain, special terminals. You can exit the level without collecting Intel, but you should look for and collect every piece that you can, because it could affect how things turn out in the end... Intel also gets added to a database you can browse where you can read the pieces you collected.

Finally, Keys are small cards that contain cryptographic information. There could be up to three per level, and a few HackTargets cannot be hacked unless you are holding a Key of the proper color.

I'm not gonna do power-ups because this game is complicated enough and I'm trying to stick to one gimmick at a time.

Oh, and one thing I removed:

I took out a logging statement that was running each and every frame. I was wondering why the game didn't seem to run at top speed. I'm an idiot, and I forgot about that logging statement and let it sit around in the tightest part of the game loop for months.

So I got Super Mario Maker 2 recently, and that means it's a perfect time to start talking about one of the linchpins of this whole game development effort -- one which I mentioned before, but said I'd only really work on once the basics are in place.

That's right, folks. It's finally happened. I've finally started implementing greeblization. This is basically the jewel in the NullAwesome crown. It's a big part of why the game exists in the first place. In every game I write, I try to incorporate a central idea or algorithm that does something cool while still serving the purpose of the game -- and for NullAwesome I wanted to build a simple platformer that could take levels that were described in a very simple, succinct format and build them out into something that looked cool and ripe for exploration. The hacking mechanic came later -- basically I thought, I always wanted to make a game about "Hollywood hacking", so I combined it with the platforming idea, loosely following the template established by Watch_Dogs, and I had a starting point.

But greeblization is not a new concept. The word is just a private coinage of mine for something that has existed for quite some time within the gaming world -- much like "jump aftertouch", my term for being able to bend the trajectory of a jump in midair. Games have probably had procedurally generated scenery from simple descriptors -- or even from random numbers -- ever since I was a kid. What really crystallized the greeblizer concept for me, though, was seeing it at work in Super Mario Maker.

Super Mario Maker is basically an editor that lets you create your own Mario levels, as well as a game where you can download and play levels you or others have created. You're given a grid in which to work and can add ground, blocks, pipes, coins, enemies, etc. to your heart's content. Different level elements interact in different ways, and this has opened the door for clever designers to build machines, gadgets, and traps with an almost Minecraft-like sense of endless possibilities. But even in something as simple as placing the ground, the brilliance of Super Mario Maker shows through -- because you can paint with the ground brush all over the place and the game chooses specific ground tiles to make sure that the ground looks consistent with its setting (taken from one of several Mario games). It will even add embellishments to make the scenery more convincing -- for example, adding portholes, pillars, and masts if you paint appropriately-shaped ground in an airship level. Also, the algorithm for choosing ground tiles (in a word: greeblizing) appears to be deterministic, always producing the same painting of ground tiles. In this way, Mario Maker lets even a beginner create levels that look as if they came from Nintendo themselves, without having to know about each individual tile in the tileset.

So this concept -- and the fact that I'm a lazy git who doesn't want to hand-place tiles on a map -- inspired the greeblization engine for NullAwesome. Basically the mechanism consists of an interface, Greeblizer, which contains a single method fillRect, as well as an array of such Greeblizer objects, one for each tile type. A tile type is conceptual: ground, lava, etc., and each type maps to a set of individual tiles all having the same properties but a different appearance. Whenever it paints a rectangle from the JSON level description onto the tile map, the TileMap class selects the currently installed greeblizer corresponding to that particular tile type, which in turn will place the tiles on the map according to some criteria. Currently I have a couple of very basic greeblizers in place, as well as a sexy new tile set -- and I'm glad to say that the results look very promising so far. I mean, look at this radness:

Don't tell me you don't want to totally play this game that much more now.

Another nice thing about this game that makes developing it really fun is the fact that I made some design choices early on which makes changing things -- even ripping out, rearranging, and putting back together entire chunks of the engine -- relatively easy. I think the decision to go with an entity-component system was a good one, as I can simply add an update agent to do something new with the already-existing entities and components if I want some new piece of functionality. And if I change one agent's behavior, it really doesn't affect all the others. In this case, I had intended to put greeblization in from the very beginning, and I had a fillRect method inside the TileMap itself as basically the stupidest thing that could possibly work. It wasn't hard to extract that functionality into greeblizers, expand upon what each greeblizer did, and then have TileMap dispatch to the appropriate greeblizer in its fillRect method rather than having a complete implementation of that method itself.

The latest code check-in adds a much-needed feature: parallax scrolling backgrounds. These get specified with a new directive backgroundImageName in the JSON file describing the level, which specifies the name of an image in the ContentRepository. This is now a required field.

I'm quite happy with the parallax feature, as it does not seem to cause appreciable slowdown, even on my ancient Samsung Epic (based on the OG Galaxy S).

But what I really want to talk about is what I'll be implementing next. Here things will be taking a dark turn. Lorn has, till now, been pretty happy-go-lucky in his little world, jumping on things and hacking things without a care in the world. Even if he jumps off the edges of the level, he will simply fall forever and you can even still steer him left and right. Well, things are about to change as Lorn gets a new ability: the ability to die. Death in video games is a symbol representing failure, and is in a way essential: is a video game really a video game if there's no way to fail? We're getting into semantics and philosophy here, but it suffices to say that we're most likely to think of an activity as a game if there are victory conditions -- in short, a way to win. And if there's a way to win there is, ipso facto, a way to lose.

Maybe I shouldn't have said death is essential. There are games -- like Tetris -- and even platforming games -- like later entries of the Wario Land series -- that do not implement failure in terms of the death of the main character. But death is the default way to represent failure, and is a time-honored trope of the medium. So it is what I choose here to simplify the design process. Here, then, is a (non-exhaustive) list of things deadly to Lorn:

Bottomless pits

Certain tiles (spikes, lava, etc.)

Traps (that haven't been hacked)

Enemy characters

Enemy robots (that haven't been hacked and turned into allies)

Projectiles from enemy weapons

My plan is to implement a one-hit-kill system. Lorn has but a single life point, and if he takes one hit he dies on the spot. Once he does, the stage will be reinitialized and he will be placed back at the beginning immediately. There is no "life" system, meaning the player can retry the current "exploit" as many times as they need to.

As of January 28, 2019, NullAwesome now requires JDK version 1.8 or later to compile. OpenJDK should be fine; if you have the latest version of Android Studio, you should be okay.

The reason for this is because it turns out that the Android development tool suite does support Java lambdas. So I endeavored to replace use of anonymous inner classes with lambdas wherever possible. I really like how lambdas are implemented in Java. Not because they're ideal -- far from it! "Ideal" would resemble Scheme, Haskell, ML, etc. (Can you tell I'm a total Schemehead?) Rather, they were designed in a way that "plays nice" with Java's existing type system and ecosystem. In Java, a lambda is type-equivalent to any interface with a single method that accepts parameters of the same types the lambda accepts, and returns the same type the lambda returns. These are called "functional interfaces" in Java. Which means that lambda expressions are effectively equivalent to anonymous inner classes, but far more convenient to use. It's a nice feature -- one that should have been in the language since version 1.0 or so, but it's here now so may as well make use of it.

So that's one refactor. The other refactor... it concerns how agents work. See, whenever an UpdateAgent or RenderAgent would run during the game loop, usually it would loop over the entire list of active entities, looking for entities with a particular component type, and updating or rendering those. This was a suboptimal implementation but it was easy to devise and quick to write -- but it may have been a source of barely perceptible slowdown.

So now agents maintain an internal list of entities they're interested in updating. This list is implemented in the class RelevantEntitiesHolder. But REH is more than a list; it also registers callbacks within EntityRepository, notifying the REH whenever a component gets added to an entity, or an entity gets deleted, and allowing the REH to add the entity to its list or not. This removes the need to loop over the entire list of entities for each agent, and also removes the check during the agent's update loop for whether the entity has the proper component type: all entities with the proper component type are automatically added to the REH when they are constructed, and removed from the REH when they are deleted. The main drawback is an unstated requirement that the add callback registered with the EntityRepository must be idempotent, that is, the results must be the same no matter how many consecutive times you call the callback. This is because the add callback may be called more than once for each entity; in fact it will be called each time a new component is added. For REH, this is not a problem.