It’s been a pretty okay week. I fixed a bunch of bugs in the entity system, particularly in saving/loading data, and I decided after much deliberation that ‘EntityPrototype’ wasn’t actually a very accurate class name so I refactored everything to rename that to ‘EntityTemplate’, which is a much more apt analogy I think. I made it so entity animations can be manipulated in terms of coloration, size, and rotation, I made it so player attack entities properly sync up to the player’s movement, cleaned up animation files for easier reading and editing – some changes and improvements, but largely a lot of housekeeping.

One big open question I’m still kind of sitting on is how I want to handle enemy death animations and other things that happen after they are reduced to 0 health. Do I want them to create another entity which plays the animation? Do I want them to go into a state of hibernation while the animation plays? What about for the player’s reaction to damage/failure? I’ll need to figure all this stuff out before I can make enemies suitable for the release version of the game, which is still obviously a long ways off but which I definitely need to start thinking about seriously when working on the code base.

Anyway, I decided to set all of that aside to work on a controller input system. This is one feature I definitely want to have working, and it will make it feel a lot more like a game just having this system up and running. The main issue is that there’s just no unified input system, and it’s barely worth it to get it running for just the controllers I happen to have, so I’ve been putting a lot of work in the last few days trying to devise some sort of way to unify all of my game inputs. Towards this end, I’ve created a VirtualController system: These are abstracted virtual inputs, which may have an actual physical controller behind them but can also be used for keyboard or mouse inputs. They should be able to handle any controller layout, with the caveat that that layout will need to be hand-coded into a file beforehand. I may make a small tool to do this for different controllers and send that out as a survey if necessary, since I don’t know of any kind of centralized database of different controller layouts and how they map to the logical inputs. Regardless, I should have it up and running for at least my own personal use within the next day or two, and I can expand it from there.

This last point doesn’t have anything to do with EverEnding’s progress exactly, but over the last few days I’ve started watching Handmade Hero and it’s done wonders for my motivation. Handmade Hero is an ongoing livestream and series of videos where a veteran game programmer builds a complete video game, running from low level C code, and streams its development. Though I’m familiar with a lot of the principles, I still feel like I’m learning a lot about where the metal meets the rubber, and it helps me get my energy and focus up to work on my own project. I highly recommend checking it out if you have any interest in games programming, though I’d recommend at least an entry-level programming background.

I’m hoping to have controller support and attack registration completed by next week, and a good handle on the aforementioned problem of entity death/animation/respawning/et cetera. Not sure what I’ll tackle after that, but I have a few days to figure it out.

There are probably some spoilers here if you care about such things.


It’s incredible the symbolic weight we can lay upon the simplest of stories. Each such story extends beyond itself like tree roots and tangles into matted carpets of narrative and meta-narrative, confused ideas about what it means to exist and to be a person, Each story is not only its own story, but also part of this grand tangle that comprises our symbolic understanding of the universe, and the simplest stories we hear the earliest grow the deepest roots, come to underlie all other stories, come to bind and be bound into an intractable metaphorical labyrinth.

When we encounter stories like this as children it’s finding what looks like a little mushroom, but is actually one nodule of a mass of fungus that comprises the ground on which we stand. It is the forest masquerading as a tree. it is the tip of the iceberg, the horn of the bull, the grit of the planet of the star of the galaxy, and we are not prepared to comprehend. Our parents’ lives seem otherworldly – it doesn’t even occur to us that they have lives beyond us – and everything past our tiny fingertips seems so vast that we touch only fragments at a time.

Instead of being a story that ties into a world-view, parable and art merges into our reality. When you’re not that far past figuring out that objects don’t actually go away when you stop seeing them, metaphor is a big ask.

The Binding of Isaac is a confused overlay of heavy Abrahamic symbolism laid onto a procedural pastiche of the Legend of Zelda. I don’t mean ‘confused’ in a pejorative sense: It evokes the feeling I was just discussing, that of being a child, surrounded by parables and adult interactions that both exceed our understanding of the world and thereby begin to fuse with one another.

It’s easy to forget that feeling of not really knowing what’s real and what isn’t. That isn’t to say that we necessarily ever really learn what is real, but we at least become more certain of our divisions. We at least become more confident that there is, that there must be some objective reality underlying all of the interpretations.

The fact is, the history of objective reality is as distant from our perception as it is from explicit fiction. The truth is something that only existed in the moment, and for us can only be inferred partially from available evidence, a tiny light in the distance sinking inexorably into the black.


There are a lot of different ways to create art, by way of impulse and instinct, by way of calculated engineering and symbolic interweaving, through characters or through places, through eras or circumstances. Games generally tend to favor deeply analytical and structured processes because these kinds of structures line up most readily with the technical work required to make a game manifest. Making a fully-featured game with its own unique gameplay tropes in a stream-of-consciousness, impulsive and expressive fashion is quite difficult, and the rare realization of this approach to creation is what gives The Binding of Isaac such a distinct and unique aesthetic.

Because ideas are siphoned directly from the most surface-level impulses, they carry all of the biases and preconceptions of the artist, often unfiltered. This kind of stream-of-consciousness and improvisational creation is common methodology in standup comedy, which lends itself readily to intuitive  and off-the-cuff approaches. The process of a lot of comedians seemingly involves scraping their psyche for the grossest, weirdest thoughts, throwing them out there and, with a wry grin, saying “isn’t that some fucked up shit?” And it works, because all of us have some of that shit in our brains, and acknowledging that it’s there and it’s gross but it’s still ours makes us feel human, feel worthwhile even at our most flawed.

There are drawbacks to this approach. No mind can exist in our world without picking up some really toxic concepts, and sometimes that toxicity is so potent that even within the context of saying “aren’t I hilariously fucked up?” it’s hard to allow these ideas space in discourse. Between portraying toxic ideas that have burrowed into our minds, and encouraging and normalizing those ideas, there’s a line so razor thin that it can be difficult to see, and bitter and ongoing disagreements vie over where that line lies. This is a frequent point of contention between social justice activists and stand-up comics, whether a joke is mocking oppression or normalizing it, whether a joke deconstructs racism and sexism by showing how the stereotypes they are built on are absurd or whether it merely parrots those stereotypes without meaningful commentary. In cases where a comedian has a strong social consciousness it can be a troubling and conflicting open question, leading comedians like Dave Chappelle into painful crises of conscience.

I don’t think there’s really a ‘solution’ to this conflict between normalization and description. This is one of many conflicts that we must resign ourselves to in our art, and navigate in the only way true ethical conflicts can be navigated: Day by day, case by case, rough-hewn principles abandoned far back on the road as too heavy and onerous to be borne out into the real world.



The Binding of Isaac is uniquely structured in games, and even though it’s kicked off a wave of imitators it still remains distinct from them in several ways. Isaac is designed to be played through multiple times: Each time the game is completed, some new facet will be revealed. New areas will open up, new enemies will appear, new upgrades will be added to the pool of items that can be found. Though at first the game appears simple, there’s more and more to discover as you go.

While many games have been released since Isaac using a similar multiple-playthrough incentive, in all cases the new aspects unlocked are about rewarding the player by making them stronger or giving them more options. In Isaac, each playthrough expands the scope and difficulty of the game while the player character remains more or less consistently powerful: conversely, with most other games using a similar structure, the game stays more or less the same while the player gets more powerful, something much closer to the traditional RPG leveling system.

Though these games are overtly inspired by the structure of The Binding of Isaac, when it comes to the intent behind the structure Isaac is far more similar to something like Frog Fractions, an experience of discovery, than it is to Rogue Legacy, an experience of empowerment.


The Binding of Isaac: Rebirth is a remake of the original, undertaken primarily because that original game grew too large to be a manageable project in the confines of the antiquated version of Flash it was built in. it was built quickly, in a matter of months, and architected in ways which were more expedient than they were expandable: This, more than any limitation of design or vision, is the flaw that Rebirth was released to rectify.

For all that Rebirth adds, there’s something missing. For all the technical woes born from creating the original game quickly and haphazardly, it captured a spontaneity and energy that’s distinctly different from that of a long-term project. For a game like Isaac, that is so inspired by the muted and confused impressions of childhood, so shaped by intuition and free association and reckless expression, taking a large team and long time to express it in its most refined form gives the whole experience a different impression than when it was expressed as quickly and intuitively as possible. Not only does this make the vulgarity of the game appear more calculated, and therefore less justifiable than before, it makes the entire experience less coherent. It is the difference between the quick sketch and the painstaking portrait: The latter may take more time and technical execution, but the former sometimes captures a spirit, a moment of movement, that’s lost if you try to polish it, to ‘fix’ it.

This slight conflict is echoed and amplified throughout Rebirth: The game employs a ’16-bit aesthetic’, presumably intended to hearken back to the Zelda games which inspired it – but, as with most modern games employing ‘retro’ styles, it doesn’t really commit. The resolution is higher and wide-screen, the frame-rate is targeted at 60 frames per second, the color range is essentially unlimited and operates via RGB tinting rather than palette manipulation, objects are translated and rotated and scaled with sub-pixel accuracy… It’s an inversion of the kind of up-res filters that are popular in emulators for old games, which draw interpolated pixels between the jagged edges created by the limited resolution: Rebirth appears to use high-res pixel images, perform operations on them, and then filter them down to lower resolution to hide the ugly artifacts that result from these kinds of operations. This is a peculiar choice in particular because the vector art the original game uses was resolution independent, and it was designed to take advantage of that capability, freely scaling and tinting objects. Translating a design made with these decisions in mind directly into a technical situation where it’s much more expensive, challenging, and aesthetically inconsistent to perform these operations seems a bizarre choice. The end result of these decisions isn’t ugly or unappealing – the underlying art is well-executed and it runs well – but it does seem somewhat inconsistent and ill-considered.

The music carries the action well, and layers fade in and out based on gameplay situations which adds an element of excitement and discovery that wasn’t there in the original, but it feels less consistent in tone and intent. The original soundtrack had a balance between excitement and melancholy which evoked the difference between the game’s action gameplay and its dark and strange story framework, and though the new soundtrack never detracts from the experience it trades away this complexity of emotion for a colder and more technical complexity. It’s a worthy soundtrack, but along with the new graphical style seems slightly at odds with the intuitive and personal stream-of-consciousness of the game’s expression.

Where these technical improvements don’t conflict with the fundamental soul of the game, they shine. Almost every item in the game has been carefully developed such that it interacts with other items in an appropriate and interesting way, in many cases obviously requiring custom code to handle a specific interaction. It would be hard to argue that this isn’t an improvement over the original, where many items didn’t work with each other at all, in some extreme cases making it impossible to progress. The game runs stably and reliably on most systems, and enemies and items have been added which add so many projectiles the old version would have slowed to a crawl. Room layouts are more varied and interesting compared to overwhelmingly symmetrical layouts of the original, and native controller support and game-saving make enjoying the experience much easier than the occasionally convoluted issues of control and time-investment required to play the original.

Nevertheless, some aspect of the joy and horror of the original Binding of Isaac has been lost. As someone who tends to overthink and overwork every creative endeavor, I have to wonder: Is this my fate as well? Am I destined to have my creativity confined by a box of my own craftsmanship? Or is there a light shining through, a way to capture that spirit and spontaneity, a way to express myself through the meticulous constraints of game technology, supported without being constrained?


One of the most interesting and nuanced changes from the original game involves the health system. In the original, there were two kinds of health: Hearts and Blue Hearts. Hearts are what you would consider your standard health: You start with 3 of them and can upgrade your maximum with a number of different health upgrade items which allow you to collect more. Blue hearts completely ignore your maximum health capacity and just get added to the end of your health meter with no limit: They can keep on going beyond what the health meter can display. They are more useful in every way than standard health pickups, but generally less useful than health upgrades, and collecting a huge number of them is frequently a certain path to victory. Rebirth completely changes this dynamic by making it so that your maximum health and blue hearts together cannot exceed the maximum displayable health value, making blue hearts useless once you’ve accumulated enough maximum health.

This results in a very strange dynamic: If you have a high maximum health but are running low on current health, you can end up dying surrounded by blue hearts you can’t pick up because you have no room for them. Health upgrades are no longer objectively positive: Some of the most powerful runs have no health upgrades at all and run entirely on blue hearts. In practical terms, the optimal strategy is usually to choose either health upgrades or blue hearts and structure your approach around that choice: Items which provide blue hearts get more powerful the lower your max health is, and items which restore health get more powerful the higher it is, so depending on which you have you may want to collect or avoid health upgrades. Though it’s sometimes difficult to find health upgrades, depending on how you’re playing it can be nearly impossible to get rid of them, so the choice of whether or not to take them is far more loaded than it may, at first, appear.

While this system is likely not intended to convey anything in particular, or even necessarily intended to be an interesting gameplay decision so much as to hem in overpowered blue heart maximization strategies, it does have a weird kind of symbolic meaning. Generally, in Isaac, hearts symbolize life and vitality, with red heart upgrades being provided by items like food and drink, where blue hearts symbolize faith, the supernatural, and the life of the mind, being provided by religious symbols like the rosary or the miter. Being asked to choose between one or the other in order to maximize a run conveys a message about temperance and faith and the difficult decisions that go into how a life should be best lead.

This is particularly interesting in light of the running theme through Edmund McMillen’s games of balancing, or failing to balance, between the creative life of the mind and the real world. This suggests that the ideal balance isn’t some simplistic 50/50 time split, but a situational equilibrium that changes with each moment – sometimes, to survive, you must dedicate yourself to your spirit, towards improving and healing your mind through focus and faith – sometimes, to survive, you must rest and replenish, eat and drink and become physically whole. Trying to do both at once just makes you less capable of pursuing either.

Is this implication intentional? Probably not. We ascribe meaning to the patterns of stars in the sky, though, even though the lights above neither know nor care about our petty problems. Some messages are important not because of why they were sent, but because of why they were received.


The intro and the first ending are the only segments shown in Isaac’s hand-drawn style, and also are together the only instances of spoken dialogue within the game. This suggests some striking divide between the narratives provided in those segments versus those provided in the brief ending cutscenes, which are rendered in a more traditional animated style. In many stories, these shifts would suggest a divide between the ‘real world’ of the fiction and something just happening in the character’s mind, but given the contradictory and fragmented nature of the rest of the narrative I doubt that there’s any such underlying ‘reality’ in The Binding of Isaac. Rather, I would suggest that these strike the divide between the conscious world, the world that Isaac constructs out of drawings and stories to make sense of what he’s feeling and cannot understand, and the unconscious world, his world of dreams and symbols which feed into his thoughts but is wild and incomprehensible.

This evokes to my mind the first Silent Hill game – two worlds, one seemingly ‘real’ but cut off from the reality we know, grey and muted, the other a purely nightmarish world of decay and rust, a purgatory where sinners and lost souls wander. There’s also a parallel between Isaac’s last ending, showing Isaac hyperventilating, locked in a chest, in his presumably final moments, flickering back and forth between a scared child and a vicious demon, and the ‘bad’ ending of Silent Hill, showing Harry dead in the wreck of his car, the preceding story perhaps just a dying hallucination.


The D6 is an item you get once you defeat Isaac playing as ??? – who is essentially Isaac’s corpse. The D6 allows you to change any item you find into a random different item. There’s a couple of interesting points to note here: First, a notable effect of ‘random’ items like this that they essentially end up decreasing the overall randomness of a game’s outcome through means of increased, rather than decreased, randomization. There’s a certain naive approach to randomness in game mechanics that intuits that the more randomly selected numbers there are, the more random and unpredictable the experience is. In fact, the practical result is frequently the opposite: If just a few numbers are left to chance, the outcome of those numbers gives a huge impact to a single individual random chance – but, if the game is built on large amounts of randomly selected numbers, then over the mass of them they’re almost certain to balance out. This principle is neatly illustrated by the D6, which allows you to introduce more randomization in order to increase your average odds of success.

The D6 is also interesting because it provides your only means of escaping bad luck. This, along with the item’s description, ‘reroll your fate’, suggests gaming in general as an escape from the punishing vagaries of real life – though, in the end, it won’t help Isaac escape the doom ascribed to him by the confines of the game, it will give him a moment of ease, a moment of escape, a tiny bright spot shining through a keyhole


Isaac suggests a number of interpretations through its several endings, none of them pleasant and few of them suggesting the actual gameplay moments are anything more than a hallucination or creative construct of Isaac’s mind. However, no matter what happens in this crazy scenario with hundreds of interacting elements, no matter what comes before, at the end, every single time, he has to climb into the chest. Each play of the game is just one of a million feverish escape fantasies, each suggestion of an escape from death an attractive lie. The only prize that can be won, the only ending that doesn’t require you to climb back into the chest, is when you collect the key to the lock, fight the greatest of all imaginable evils – and find yourself already in the chest anyway, in a brief moment of lucidity, a shining light through a keyhole.

Then you play again, as a different Isaac with different adventures, but the chest is always waiting. The chest contains the game, contains every experience you might have within it, the fate you constructed for yourself by playing.


Next time: The Swapper


Syncing turned out to be fairly easy to implement once I decided how to approach it. I had a bit of trouble getting the character to move with the platform she was standing on, but that was mostly just because my approach was flawed, and once I changed everything to just use velocity values instead of some of the weird direct modifications I’d been trying it all worked just fine.

After that, I wanted to come up with a system for moving these kinds of special platforms, so I made two: One is a very simple behavior for moving smoothly in a sine-wave shaped motion on either or both axes over a period of time, suitable for any kind of repeating smooth up-and-down, side-to-side, circular, or figure-eight movement pattern. The other is based on providing a set of movement vectors and the amount of time to move each distance in (rather than a rate of movement), along with easing values between 0 and 1 to handle how much acceleration/deceleration each step should have.

Now that those behaviors are complete, I’m working on getting attacks working using the collision and interaction methods I’ve established over the last couple weeks. The attack part should be fairly easy, though probably a bit tedious since I’ll need to create a separate entity prototype for each style of attack, but before I can test it I’ll have to construct a test enemy to work with, which may take a bit of effort. Maybe I can temporarily steal some sprites from another game to get that up and running.

Oh, the other major thing that will need to be figured out is how to handle entity destruction. That is, right now an entity can be deleted, but they just blink out of existence, which is pretty unsatisfying. I need to figure out how I’ll be handling dying animations and other such effects.

It’s a bit discouraging to think that this time last year I was releasing the very first rough footage of the game and how little it’s changed visually since then, but I think a lot has changed under the hood. For the next update I’ll probably go back and look over what I’ve accomplished during the past year, which will either make me really depressed or slightly mollified. We’ll see!

Also, I know I’ve been super bad about updating with non-devblog content for the past month or so. I’m hoping to get back in the habit soon. It’s just really easy to get sidetracked. Sorry!


Things have been a bit chaotic with the holidays, but I have the inter-entity collisions basically working. I say basically because they detect each other properly and they block each other properly, but some issues have come to light regarding how they interact which I’m still figuring out.

When I designed the entity update system, I made one big dumb assumption, which was that entities would not change except by their own code during their update loop. Obviously, any kind of entity interaction breaks this assumption badly. If I’d realized that I was making this assumption in the first place I probably would have seen that coming, but it didn’t occur to me. We can probably chalk that one up to a lack of experience. Anyway, as a consequence of this misplaced assumption, the player entity’s info, after being modified in the inter-entity collisions, isn’t visible to the player until she goes through another complete update loop, by which time a lot of that info has been reinitialized. Thus, even if I tell her she’s standing on a floating platform, she can’t hear me because by the time she checks to see whether she’s on a platform another behavior has written over that with info telling her that no, actually, she’s still falling, because no platform has been found yet.

Today’s work time was spent half figuring out that this was what was going on and half trying to ponder some kind of a solution that didn’t break anything else, and I think I’ve arrived at one. Basically, I’m going to flag each behavior as either unsynced or synced − unsynced behaviors work exactly as behaviors do now, where I iterate through each entity and iterate through each behavior of that entity through until I reach the last behavior of the last entity. Synced behaviors, however, will stop after updating, then iterate through all of the other entities that possess the same behavior until they reach that behavior and update it before proceeding as normal.

This may cause some issues and may be a bit tricky, particularly in instances where a synced behavior is encountered while updating to sync with another behavior, but it seems like the most logical solution and shouldn’t require me to tear up a lot of existing code, just get this one bit of logic working. Once I get this working, I can then settle in on the more specific applications of this work, such as moving platforms, destructable walls, and melee attacks.


Not a bad week. Created an inter-entity collision behavior and a system whereby entities can interact with each other, both of which will be necessary to get attacks working. I actually ended up using the same kind of stacked enum faux-assembler that I had been playing with for my Color class, so that time may not have been entirely wasted — though, in point of fact, I looked up a haxe real-time script parser that I could also potentially use today, which probably would be a more flexible solution, so who knows? That’s not important at this point anyway: What’s important for now is that the entity collision behavior is in place.

The question is, does it actually work? And, uh, for various reasons the answer to that is a little bit slow in coming. There were bugs in the entity editor I had to fix. Then there were bugs in the level save code I had to fix. Then there were bugs in the game initialization code I had to fix… And so forth.  It was an experience rather like building a working airplane in your garage and then opening the door to find that you’d absentmindedly left a pile of rocks in your driveway. Well, I think most of the obstacles have been taken care of now, and there’s just one problem left before I can give this behavior code a proper test run: Getting the level to actually recognize when it’s fully loaded and place all of its entities.

It’s a rather tedious problem, just a sequencing error. Right now the initial level is made active as soon as the file is loaded but before all of its secondary data (details, entities, background) is fully loaded. The challenge is making sure it knows when it’s finished loading, which is actually surprisingly tricky since there are so many little moving parts. I suppose an easy solution would be for it to just check periodically, but that would be messy and inelegant — and, moreover, doing this the right way from the bottom up will make any future changes and improvements that much easier to manage.

Well, it shouldn’t be that much trouble, but it’s somewhere in between amusing and exasperating that I keep getting blocked trying to do the simplest things by hiccups in the code. Still, each time I fix something like this it feels deeply rewarding, like sanding a wooden surface until it’s perfectly, pristinely smooth.


Since I’ve been kind of in-between major components of the game, I’ve been spending time just looking through my code, figuring out things that need doing, pursuing components which are, perhaps, not particularly vital to the project but are personally interesting, and just generally dicking about. Somewhere in between procrastination and vital work, smooshing bugs where I find them, noting down things to pursue when I get a chance, and thinking probably way more than is actually practical about fancy expansions to my color class.

I’m about ready to settle down to my task list, though.

By far the most pressing thing on the list is getting melee attack registration working. It’s a bit odd that I’ve put it off for this long, but I kept being unsure exactly how I wanted to proceed and tabling it for later. Given the experience I’ve had over the past week looking through the byzantine horror show that is some of my old code, I suspect I may in fact be better off for this delay. The two big questions that have stalled me are a) how do I make a system for precise collisions that aren’t tedious pixel-by-pixel affairs that bog down the code, and b) how do these collisions interact with entities?

Today I think I’ve arrived at some satisfactory answers.

To the first, It occurs to me that rather than going through pixel-by-pixel, I can easily skip through and, in the case of any objects that aren’t weird lattices or anything, have detection that’s still pretty accurate while expending 1/16th or less the processing time. Since only a few of these are likely to be processed per frame, that should be entirely satisfactory. To the second, I think it makes sense for each attack to be its own entity, even if it only exists for one frame, and to then apply its damage to any enemy entities that it can detect collision against. This is a particularly appealing approach because it means that projectile attacks should be able to be implemented in a fundamentally similar way, just replacing an instantly-disappearing attack entity that collides with everything in its range with a fast-moving attack entity that destroys itself after the first object it collides with.

I’ll be working on these behaviors over the next week, as well as keeping an eye on what modifications will need to be done for other kinds of entity collisions such as for moving platforms and destructable walls. Once I have that stuff working, I can see about building a test level with enemies and tuning up the basic gameplay, as well as adding any additional animations that will need to be created for the new interactions. I’ll probably be bouncing back and forth between that stuff and adding the remaining features to the code base for at least the rest of the the year, but once I hit that point I should have a rock-solid base to expand upon.




The first thing I did this week was throw together a rough list of the programming tasks remaining to be done:

  • Game-state changes (recording defeated enemies, found items, triggered events, etc)
  • Attack registration and collision with entities
  • Dialogue management
    • Text captions
  • Animation registration points and derived effects
  • Improvements to Tile Editor:
    • Option to automatically link tile appearance to tile shape
    • Fix alignment issues w/ menus and dropper
    • Add ability to invert collision mesh within selected area
  • Manage loading levels better (consistent & simple) – currently is inconsistent and unreliable
  • Manage loaded level assets (particles etc) better – figure out when the best time to pre-load is
  • Main menu
    • Load game
    • Multiple profiles
  • Improvements to Particle System
    • Can be spawned by entity events
    • Can play sound
    • Collision with defined shapes (must be efficient)
    • Spawn masking
  • Dynamic zoom?
  • Graphics post-processing? (offload to C++ sub-program?)
  • Special effects
    • Reflective floors
    • Water reflections/rippling
    • Screen shake
    • Basic lighting
      • Lighting editor?

The second thing I did this week was tenuously start working on one of these and get completely sidetracked onto something else that I thought was interesting. I ended up spending several days in a row developing a class for working with colors, one which I kept coming up with ideas for, new features and optimizations and improved interface tweaks and so forth. I actually still have several ideas for additions which I may revisit at some point, but for now I’m moving on.

So, first up I’m going to be tidying up and adding a couple of features to my tile editor, then I’m probably going to start figuring out attack registration since that’s the only missing component of the core gameplay. Maybe it’s kind of weird to get sidetracked for a week on making a fancy color class, and it may be a long time before that work ends up paying dividends if ever, but I’m still happy I spent that time on it. It was good practice, and it added another tool to my growing toolbox – one I will probably find many uses for in the future.


Get every new post delivered to your Inbox.

Join 4,918 other followers