Fixed a bug in the logging code that resulted in infinite recursion. See previous post for details on changes in 2.09.

Spankers and Spankees,

I’ve released a new update to Potion Wars (get it at the Downloads page).

Changelog:

1. The game now writes to errors.log all actions performed in combat, and the associated state. This should make it a lot easier for me to track down corner bugs that only arise when actions A B C D E E E E A F are performed in combat. So please, when you see a crash or other bug in combat please tell me about the bug and SEND ME THE ERRORS.LOG file. Furthermore, please, as soon as you see the error,  kill the game and send me the error.log. That way, the last action in the log will be the action at the point the error happened. If the bug crashes the game, just send me the errors.log (along with a description of the error). Note that the errors.log file gets wiped every time you restart the program, HOWEVER the game also automatically saves the errors.log file from the previous 5 play sessions (named errors_1.log, errors_2.log, …errors_5.log). So if you see a crash, but accidentally restart the game before you send me the log, just send me the log file that corresponds to that playthrough.

2. I’ve added a scene with Airell (the pompous mage) written by Bonemouth and edited by me. You should see this scene if you pissed off Airell in episode 1, and he threatened you with a spanking. He’ll show up in the Adventurer’s Guild, just talk to him to start the scene.

3.  Fixed a bug in one of Maria’s conversation nodes in episode 1, that would have caused a crash as soon as someone tried to access that quip. It was the node at the end of episode 1 that only triggered if the player managed to stay out of trouble with the guards (i.e. didn’t get into a fight with Maria, and didn’t lie to the guards). Apparently not a particular popular path among people who file bug reports, since I only saw it after I fixed a bug in my unit tests that meant my tests weren’t invoking the conversation nodes in episode 1.

4.  Skyblaster the Sardine has joined the team as a beta tester, and support writer. He’ll be working primarily on in-combat spanking scenes for now. I’ve added his name to the in-game Acknowledgments page. Flash the Flamingo has also joined, he’ll be working as a Beta Tester, and number cruncher (basically he’ll help me analyze my growth and damage formulas, and make sure they scale like I want them to). I forgot to add Flash to the in-game page, and I’m too lazy to back and add it, but he’ll be there in the next release!

5. Implemented some code that should make it easier for me to maintain consistent state when transitioning scenes. Basically, any time a scene begins, I clear out all adjacent rooms, and remove all NPCs from their respective rooms, and then manually reinstate those rooms, and NPCs that actually show up in the scene (I do have some helper functions for rooms, and characters, like Avaricum Square or the girl at the Tailors, that don’t change between scenes). This will make a little bit more work for me, but it should make errors more obvious (a character who should be there is missing!), and gives me much better control over the configuration of each scene. So it’ll end up saving me time in the long run.

6. Characters now gain 2 points in Strength for every round they stay grappled. Otherwise, grappling would go up too slow for characters who initialize and actually want to stay grappled (i.e. the characters who should have high grapples!)

7.  Characters gain 120% mana each time they gain talent, rather than 150%.

8. Removed ambushes. They were rare, buggy, and in my opinion don’t really contribute anything.

9. Miscellaneous bug fixes. Added some infrastructure for incorporating LaTeX written dungeon scenes into the game.

10. Removed Deidre from the Adventurer’s Guild. Originally she was going to provide the job on behalf of someone else. I decided I didn’t want that, so I’ve introduced a small retcon.

Also, although you can’t reach the dungeon in episode 2 yet, I have added it to the code. Here’s a screenshot of the corner you start in:

Floor 1 of Episode 2 dungeon

It’s not the prettiest thing ever, but that’s another side-effect of the rigidity of my current GUI code. Hopefully when I overhaul the GUI after episode 2, I’ll be able to rewrite the map code so that it looks nicer, and we don’t necessarily after to show the entire map at once (clearly 20 x 20 is about as large as we can without inducing eye strain). But who knows. I sure don’t. Honestly, I’m surprised it works as well as it does.

I haven’t implemented any of the events yet, but we’re getting there.

Also, don’t forget I released a new episode of Etrian Odyssey yesterday. Get it at the Etrian Odyssey tab.

Spankers and Spankees,

The latest update includes fixes for bugs pointed out by an anonymous fan in e-mail:

1. Saving immediately after the episode 1 dungeon dropped you back in the dungeon.

2. Carrie’s conversation at the end of episode 1 crashed on the male path.

3. If you’re fighting N opponents, pressing the N+1 number key crashed the game.

4. If you went down to the bottom floor of the guild, fought the pair of Vengadores at the beginning, then went back upstairs to fight the pair bullying Paloma, then lost, then tried to start the battle over, the game crashed.

Also, I’ve added a new option when you start the game: Now, you have the option of turning off enemy spankings. Basically, you can choose to make it so that enemies never try to spank you, nor will they ever reverse your spanking. I’d been planning to add this option after episode 2, when I overhaul the GUI, however the person who pointed out the above bugs really really doesn’t want to be spanked in combat (they are an exclusive top). So as a thank you, I implemented a simple choice at the beginning. Unfortunately, you cannot change this option during the game. After I overhaul the GUI, you will have the ability to change that (and other options, like difficulty) during the game instead of only at the beginning. The reason you can’t do it now is because I would need to design a whole new screen, and I don’t really want to do that much GUI work when I’ll be ripping it out and rewriting it in a few months anyway.

Something I want to emphasize: If you send me bug reports, or constructive criticism I will be happy. If you make me happy, then I am even more receptive to your suggestions. What this means is that:

1. If you’d like to see something that I was planning on implementing anyway, I may implement it sooner (like I did for Anonymous).

2. If it’s something that I can tolerate, but I’m not a big fan of, and it doesn’t clash too badly with the rest of the game, I may implement it. For example, I’m not a big fan of tentacle monsters. However, Bonemouth would like to see a spanking scene involving tentacle monsters, so I am carefully considering including a tentacle monster scene in episode 3 (which will take place in the forest surrounding Avaricum). Similarly, I’m not into age regression. However, Emily likes age regression so I included a few light AR scenes (it’s just shoving the PC into childish clothing, but it’s something) as a thank you for her help in editing.

So if you want to see something in my game, be it a gameplay feature, or a spanking scene, or what, send me bug reports. It will significantly increase the chances that I will include it.

Spankers and Spankees,

Latest update fixes (hopefully…) all of the bugs pointed out by SSM in the previous post except for the problem with sold items not increasing your money. Life is pretty insane right now, and so I only have time to look at game breaking bugs.  Since your money pile doesn’t matter right now, I’m holding off on fixing that problem.

So, don’t sell anything yet. Sorry about all of these problems, and thank you for your patience. A combination of being overwhelmed in school, having really really bad legacy code, and a non-existent testing framework means that the early releases are going to be unstable. I’m trying to improve on that testing framework, but some things are harder than others, and again I don’t have much time right now.

So thank you to those of you who are playing the game and reporting all the bugs (SSM, KingKruul, and cmfunk, to say nothing of Bonemouth and Ken). I really, really appreciate it. And I’m sure those who download the later versions will appreciate it as well.

Spankers and Spankees,

First, a new release has been uploaded. Get it at Downloads. It fixes a few crashes that I found, as well as some typos and the like pointed out by some of my beta testers.

As I’m sure you’ve all noticed (much to your annoyance), releases tend to be crashy and buggy as hell.  Naturally, this is unacceptable. So lately I’ve started incorporating unit tests. I know, any of you with programming experience are exclaiming “You’re writing something as complicated as a game and you don’t have unit tests? What is wrong with you? Test driven development dumbass!”  In my defense (sort of), this is the first program that I’ve ever written which is complicated enough to require unit tests. In school you’ll have one class that might briefly touch on unit tests, you do them for that one homework that requires them, and then you never touch them again because all your assignments are only a few hundred lines in one or two files. When programs are that small, it’s just as easy to throw in a bunch of print statements (I’m also forcing myself to use a proper debugger).

So far, I have tests that test attacking, grappling, breaking a grapple, and throwing. These tests make sure that my damage formulas are correct. I also have tests that run through and execute each enemy’s in-combat spanking text, and a test that iterates through each conversation node and builds the text that is meant to be displayed. While these two tests don’t try to make sure the displayed text is correct (that would essentially require me to write my text in Python, which ruins the point of LaTeX->Python!), it does minimize the chances of stupid crashes from undefined functions, trying to add a string and an integer, etc. Admittedly, a crash might still slip through if there’s an error in the branch of an if-statement that isn’t followed. However, I try to keep inline if-statements small and simple. Anything complex gets pushed into another node, so these tests should catch upwards of 90% of all the dialogue-related crashes.

Over the next few months, I plan on introducing some tests for the other combat actions, and tests for any new code I add, or code that I modify. These should make the code a lot more stable. However, these tests are by no means exhaustive. So if you come across a bug or a crash, I almost certainly don’t know about it. So please let me know. To paraphrase alt cor, bugs feed my soul.

Another thing I want to talk about is my plan for future releases. I’d rather not go 9 months between the release of new content. But at the same time, I also don’t want the game to gradually become more and more railroaded because I skip branches in a desire to release faster. I also want to release enough content for people to get meaningful enjoyment out of it. So I’d like to release enough content to provide a coherent part of the story (this was the original intent of the episode structure incidentally). To balance these, my plan is the following:

1. Write, edit and release the “spine” of a particular act. These are the scenes that drive the plot forward.

2. Write and release the scenes that aren’t strictly necessary for the plot, but provide some useful insight into it, or that aren’t immediately important, but lay the groundwork for future events.

3. Write and release the scenes that contribute nothing but fap material.

4. On to the next act.

Note that scenes in the second and third category are the ones that will typically be written by the writers who are helping me.

Alternatively we could do:

1. Write and edit the spine of act 1, then act 2, then act 3.

2. Write and release scenes that aren’t strictly necessary to the plot, but enhance it for act 1, then act 2, then act 3.

3. Write and release miscellaneous scenes for act 1, then act 2, then act 3.

So for example…

———————-EPISODE 1 SPOILERS!!——————————————

If I were to have followed the first approach in episode 1, then the scenes would have been released as follows:

Act 1:

1. Conversation with the guard -> conersation with Maria -> conversation with Adrian

2. Conversation with Elise, conversation with Peter, conversation with Carol (employee of the taylors).

Act 2:

1. Conflict with the Young Vengador -> Encounter with Cosima -> Encounter with Mai -> Boss fight

2. Paloma, Dining Room

2. Ildri, Morey, Airell

Act 3:

1. Scene with guards -> bar scene -> conversation with Catalin.

2. Pre-bar scene with Elise and Carrie, conversation with Peter

If I took the alternative approach, the scenes would have been released as follows:

1. Conversation with the guard -> conersation with Maria -> conversation with Adrian

2. Conflict with the Young Vengador -> Encounter with Cosima -> Encounter with Mai -> Boss fight

3. Scene with guards -> bar scene -> conversation with Catalin.

And then fill in the extra scenes starting from Act 1 on.

If you have a preference, let me know. Keep in mind that this only controls the order in which I write scenes. Obviously I’ll add scenes as others write them, so even if I write the basics of the entire episode first, I may add additional scenes before I’ve finished the spine, as others finish them up.

So if I’d bothered to wait another 24 hours, one of my beta testers (thanks Ken!) would have unleashed a slew of bug finds at me before I released the previous version and embarrassed myself. Anyway, this fix has all of those bugs fixed (hopefully…) including some that were downright game breaking.

Get it at the download section.

Spankers and Spankees,

At long last (9 months! Holy hell. I really need to pick things up!) we have new content for Potion Wars. The first act of Episode 2 : Back Alleys. We’re just going to ignore the fact that my dream is to produce multiple episodes per year. Ah well, I’m still doing a lot of coding, and almost all of this was written by yours truly. Hopefully I’ll eventually hit a point where I’m just maintaining the code, rather than actively modifying it and I’ll have more people helping me write. You can find it under the Download tab as always.

There are a lot of changes in this version, as is to be expected since four months have passed since the last version.  However, before we get to that, some updates on the project. First, welcome Bonemouth the Boxfish and Ken the Kookaburra (I don’t know what that is, but I’ll bet it makes a mean burrito) to the team. Both will be helping me with writing scenes. For now, Bonemouth is working on in-combat spanking text, and spanking scenes that don’t really contribute to the plot. Ken is working on in-combat spankings. Both have also joined the beta testing team, and Bonemouth in particular has been a major champ. Guy’s a bug-finding machine. So hopefully this version won’t crash on too many of you. Don’t get me wrong, it will crash. It’s software. Crashes are inevitable. But hopefully it’s more stable than the first release last summer. I’d also like to thank Emily. She’s been invaluable in helping me figure out the layout for the first act. Hopefully with Bonemouth’s and Ken’s help I’ll be able to increase my throughput.

Now, on to the game itself.

First a few known bugs/unpleasantness:

1. I’ve removed the ability to skip multiple pages of text. I know that sucks, but that feature was pretty flaky to begin with, and it was giving my beta testers lots of problems. The code for displaying text is a tower of hacks and I do not understand it at all. So, since I’ll be completely rewriting the GUI code using a proper toolkit between episodes 2 and 3, for now I figured it’d be easier to just remove that feature.

2.  Some scenes will have a blank page before the text. This will happen whenever the music changes. Just hit enter and you’ll get the text you’re supposed to, and the music will change. Again, this is a side-effect of gross limitations in how music is displayed and how I ensure that music plays when it’s supposed to. This problem will vanish when I overhaul the GUI (to be replaced by a hundred other problems, but such is software).

3. I’m going to shelve indefinitely my plans to make the combat top-down. That would require a tremendous amount of work, both initially and throughout the game. If I do topdown combat, movement will become complex enough that I’ll need to write custom AI for each enemy because each enemy would have a different movement style based on their strengths. While this would be awesome to play if done well, it would drastically increase development time. And I imagine most of you would rather play a decent spanking game, then read endless posts about how hard I’m working on an amazingtastic spanking game that you’ll totally get to play sometime in the next century.

Changes:

1. Content for Act 1 of Episode 2. There’s no dungeon crawling. Just running around talking to people, and getting your butt smacked. I’m sure you’ll blaze through it in like an hour. 7 months of work for an hour of enjoyment -_- This is why we can’t have nice things.

2. Although I didn’t go the topdown route, I did overhaul the combat mechanics to eliminate some of the randomness. Highlights:

a. Everything hits successfully (attacks, status spells, grapple attempts, etc.). The only thing that’s random is spanking. Every time you try to spank an opponent there’s a 20% chance that you’ll get reversed.

b. The multi-turn spanking content has been implemented, mostly as I wrote a few months back. I’ve deviated a few times from my proposal, but not in any significant way.

c. New Initiative. The combat order is: grappled characters > spells > spear attacks > sword attacks > dagger attacks > grapple attempts > other. It doesn’t matter how much faster Alice is than Bob. If Bob is casting a spell and Alice is attacking with her spear, Bob will always go first. However, if both are casting spells, then Alice will go first. If Alice and Bob are grappled, and Bob is casting a spell while Alice is attacking, then whoever goes first will depend on their initiative.

d. Weapons no longer have damage associated with them. Instead, damage is calculated solely based on warfare (the formula of which has also been changed). However, weapons do provide bonuses or penalties depending on whether you’re grappling or at armslength.

e. Grappling now lasts a certain number of turns based on your grapple skill. Attempting to break a grapple reduces the grapple duration by your grapple divided by 2. You cannot throw an enemy until grapple duration is less than half of your grapple (in other words, you can’t throw until you’re one break grapple away from ending the grapple).

f. Grappled characters cannot be targeted by armslength combatants with attacks that do damage. So if Alice and Claire are grappling, Bob can’t attack Claire, nor can he cast firebolt on Claire. He can however cast Heal on Alice, or Weaken on Claire. He can also attempt to break Alice’s and Claire’s grapple. This applies to spankings as well. The basic idea is that the chances of friendly fire is too high, so characters won’t even try.

g. The rate of health increase has been drastically reduced. Before, after a single health increase your character was pretty much set. Now fights will hopefully remain a bit more tense.

h. The Spectral Spanking spells have the same multi-turn mechanic as physical spankings, with a few differences. First, characters who are involved in a spectral spanking are NOT immune to attack if the spell was cast at armslength. Second, each round of spanking costs the caster 1 mana. Third, the initial casting cost is helluva expensive. This is to counteract the fact that you a) don’t need to be grappling to initiate a spectral spanking and b) since it’s a spell, you’re going to go before your enemy the vast majority of the time. Furthermore, at the end of the spell you do damage in addition to keeping one of your opponents locked up for a few turns and humiliating them, and they can be attacked with impunity by your allies while being spanked (granted this last one won’t affect you in episode 1 because you don’t have any allies, but it sure as hell will in future episodes when you do). It’s a powerful spell if used well, and its cost reflects that.

Hopefully this will make combat more of a puzzle, and less of a SPAM ATTACK AND HOPE YOU GET LUCKY! Yes, you can win every battle without grinding (I’ve done it). Just gotta figure out the right combination of attacks and spells to use. 😉

3. When you load from an old save, you’ll be given a few messages about changes. If you had the leather breastplate, then it will be replaced with 20 coins (renamed to matrons), which is enough to buy a new outfit of your choice at the Tailors. You’re also given a tunic and trousers so you’re not naked. If you had the quality dagger that will be removed, and if you sold the family weapon, you’ll be given the option of choosing a new family weapon. You’ll also be given an enhancement gem, which provide the means of improving your equipment. This will ONLY happen with old saves. The code for enhancing your equipment hasn’t been implemented yet, but Peter will be providing that service once it is. You can ask him about it, and he’ll tell you he needs to do some research to refresh his memory.

4. If you defeat the episode 1 boss, you’ll get your first enhancement gem, an attack gem. This will improve your warfare when attacking by 1 if you put it on your weapon, and your warfare by between 1 and 3 (haven’t decided yet. A single point of warfare tends to give you a bigger damage boost than it does a defense boost, so I may need to give you a bigger defense boost to make the defense choice worthwhile) when being attacked if you put it on your clothing.

5. I’ve tweaked some of the text in the first episode. Not much, but some. Also, casting Distort Magic and Spectral Spanking in the mage room of episode 1 will give you a point in the respective spell counters.

Finally, I’ve also released the transcript for all the content currently in episode 2 (you can find a link to the PDF and LaTeX at the bottom of the Downloads page). The transcripts are licensed under a Creative Commons Attribution-NonCommercial 4.0 International (CC BY-NC 4.0). Basically, this means you are free to take my transcripts,  the content in them (and the ideas they represent) do whatever you want with them, then release your modifications/new content/whatever you did. Just so long as you don’t try to make money off of it, and you give me proper credit for my work. See the link for more details.

I think that’s everything. Enjoy!

Spankers and Spankees,

First, some good news. I’ve implemented the auto-map. I haven’t quite implemented the (G)o command yet, but that should be very straightforward. The most complicated part will be (as always) designing the interface. That being said, I’ve decided to make the game top down. I know some of you liked the first-person viewpoint (I’m rather partial to it myself), but I’m not doing this lightly. There are three reasons:

1. Topdown was a lot simpler to implement. Seriously, it’s almost absurd how much easier it was to implement. The most complicated part was implementing a notion of “dirty rectangles” that allow me to update only the part of the screen that changes. So now, when you’re exploring the dungeon you don’t get that annoying flicker every time you move. However, implementing dirty rects was much much easier than doing the same would have been for first person, because there’s a simple and obvious mapping from what’s on the screen to what needs to be updated. The first person view, with its weird angled viewpoint would have been much trickier. I even have a working sight radius (it’s still limited, the player can only see squares in the cardinal directions, but that’s good enough for now).

2. It looks better. I’ll be posting a screenshot shortly, but I think it looks better than the first person, and it should scale better to different sized monitors. I recently got a second monitor, and I was amazed how bad the first person view looked on that other monitor. I’m amazed I have any fans at all, considering how horrible it looked on anything but my original screen!

3. Most importantly: It opens up a lot of tactical possibilities. Imagine we make combat topdown as well. Then we can include positioning as a part of combat. I have a lot of thoughts about this, and most of them are only half-formed, but here’s an example of what I’m thinking about: Threatening Zones. Suppose Juliana is wielding a spear. Then she has the following Threatening Zones:

 X
X
X X J X X
X
X

Sword:

  X
X J X
X

Dagger:

 J

Now a key feature of these zones would be the following: For every zone that is not blocked (i.e. for every zone that the character can safely move onto, whatever “safely” means with respect to the rest of combat), the character gets a +1 bonus  to damage (swords gain a +4 bonus to damage while grappling, and daggers gain a +8 bonus to damage when grappling. Spears gain a +0 bonus to damage when grappling regardless of the status of the zones). So in an open field, a spearman has a +8 bonus to damage, while a swordsman only has  a +4, and a dagger wielder has +0 (when not grappling).

In other words, in an open field, the spear wielder is going to have a huge advantage over a swordsman or dagger wielder (which incidentally  reflects reality. Also, scholagladiatoria is an awesome resource if you’re at all interested in Renaissance era and older dueling and warfare. I’ve learned a lot  by watching their videos). However, consider something like this:

Spear in  a hallway:

————
X X J X X
———–

vs.

Sword in a hallway:

———
X J X
——–

So now, instead of the spearwielder having a +4 damage advantage over a swordsman, she only has a +2 advantage. Or even:

——-
XX J|
——

In which case, while the spear wielder has a +2 damage bonus while in the corner, an enemy swordsman (who presumably is not pressed against a corner) has a +2 bonus as well, so they’re (mostly) on even footing. The spearwielder does have the advantage of extra reach, but even so things are looking much better for the swordsman.

Even something this simple opens up a huge world of possibilities, because now a good chunk of combat is in trying to force your enemies into an favourable situation. Battle isn’t just about spamming your most powerful spells and attacks and hoping you kill them first, it’s about controlling the battle field. Suddenly, spells and teamwork gain a whole new dimension. You could have characters marching in formation, so enemies can’t block Threatening Zones. You could have the fireball spell scatter people, allowing you to break up formations. Spectral Push and Spectral Pull could be used to put people on different parts of the battlefield. Buff spells could speed your character up, or make it harder to move them. If you watched the video I linked to, you’d note that whoever is on the offensive is usually charging forward, while the defender is backpedaling. So you may be able to do something where attacking drives your opponent backwards and you forward, so repeated attacking could be used to drive an opponent into the corner. Throwing would also become much more useful, because you can use that to control your enemy’s position.

In fact, I would argue that something as simple as positioning provides enough depth that we can eliminate (almost) all of the randomness. In other words, attacks always hit, grapples are always successful, and spells always succeed. The only thing that would be random would be whether you successfully spank your opponent or get reversed. However, spanking itself could gain additional elements (neither the ally nor enemy can move while the spanking is going on, so a spanking could be used to disrupt formation, or as a delaying tactic until a friend can reach you). This is good, because the more I think about it, the more I think randomness is something to be avoided. It encourages save scumming rather than tactics, and it can generate all sorts of frustration (nothing like losing a close and tense combat because you missed twice in a row, while your opponent landed a pair of criticals). With randomness, things tend to boil down to spamming your most reliable attacks and hoping you get lucky.

Instead, if you eliminate randomness and instead give heavy bonuses and/or penalties based on your position on the battlefield, things become much more about controlling the battlefield, and trying to manipulate things to your advantage. However, none of that is possible with my current system, and trying to incorporate that into a first person view would be tremendously frustrating, and clunky.

So basically once I came up with the idea of Threatening Zones, I understood that making things topdown was the best choice. That being said, I won’t be implementing the new battle system until after I’ve made much more progress into Episode 2. After all, it does no good to be constantly improving things, and never releasing anything! So I’d like to at the minimum, release Act II before I start ripping out the battle system, and I’ll probably release all of Episode 2 before I change the battle system. I can fold the new battle system into the GUI overhaul I have planned between Episodes 2 and 3, so that once 3 goes live we have a brand spanking (heh) new combat system.

I’ll make a post with more information about my plans for the new battle system sometime later, maybe in April. I want my Game Design post for March to focus on something else.

Anyway, here is a screenshot of the fancy new topdown view of the dungeon:

This is the first floor of the guild in episode 1. The dark grey/black squares are squares you’ve seen, but haven’t visited, the dark blue are squares you’ve visited, and the orange squares are special squares. The character in each square indicates what it is. ! indicates an enemy fountain. * is an event square. “s” is the dungeon entrance. “0” is a zero, and indicates that that square has a stairwell down to the next floor. “J” is the first letter of the PC’s name (Juliana) and indicates the player’s position. (M)ap is a relic, and will be replaced with (G)o.

Now the bad news. I’ve been doing the math, and it looks like I’m going to have to basically vanish for the month of March. I have something like two months to finish my thesis, and I have a lot still to do, and I’d rather my nose-to-the-grindstone month is not April (since it’s due at the end of April, and I don’t like waiting until the last minute. Too stressful). So I don’t know how much time I’ll have to work on this or my Etrian Odyssey Let’s Spank.

Now, I know this is probably making many of you nervous, because that’s usually how Internet projects start to die. “I’m a little bit busy now, but I’ll get back to this stuff I promise!” and then the person never gets back to it. However, let me assure you, that ugly ass blue and orange maze up there is the reason I get out of bed in the morning. I know, that sounds weird, and obsessive and maybe kind of sad, but that’s how it is. I’ll have a few weeks in May after I graduate before I start my job, and I intend to spend at least one of those weeks (the other will be spent visiting family) working on this game and my Let’s Spank the way I want to: all day, every day. With the occasional break to play Lords of Xulima, of course. Got to know the field if you’re going to contribute. So trust me, as much as it’ll suck for you guys that I won’t be doing hardly anything with this in March, it’ll suck just as bad for me, and nothing short of death is going to stop me from continuing to work on my game. Hell, the reason why I’m getting the hell out of academia in the first place is because it’s a horrible, soul sucking wretch of a place that demands far too much of my time. In other words, I wouldn’t have enough time to spend working on my game! So progress may slow to a crawl, but I won’t be stopping. Even if my work in March consists of a little bit of thought about the game mechanics and nothing more, it won’t stop.