Oh right, this is still here.

I have a page on Itch.io I’ve been using, and while I was trying to remember where the spot to change which games are hidden, I noticed I still have this blog listed as my “website”.

I guess I should update it more regularly.

I have a lot more done one my “keg” engine now. I’ve also be trying to improve parts that didn’t turn out to work as well as I’d hoped. One thing that helped was the frequent participation in game jams I’ve been doing. There’s nothing better for finding bugs in your engine then trying to make a game with it and seeing what goes horribly wrong.

Most of what I’ve been doing, however, is just trying to figure out some way that I can make a decent full game out of any of my experimental stuff. The problem isn’t even the work of making a game. It’s the personal issues that keep coming up with my home environment. I don’t have a place to get away and work in peace, nor do I have a way to get one. Instead, I’ve been trying to find some theme or method of working that I can manage in spite of the problems. In addition, I’ve been trying to make sure whatever I work on will be somehow useful regardless of how things go.

Recently, a friend of mine took interesting in a tactical jrpg system I described, so I thought I’d make a version that other people could use. Maybe when I feel like it I can write about either how it works or why I really don’t like the language I’ve been making it with (c#, as opposed to c++ that I’m used to).

Update finished, now back to work.

Further Thoughts on the Abyss Staring Back

This is kind of embarrassing. I just realized it’s been over a year since I posted here. It doesn’t even look like the embedded text editor is the same anymore. I guess I’ll start with what’s happened since my last post:

[begin part to skip if you’re reading this without having read previous posts]

SpaceMerc flopped. I thought about how much work a point-and-click engine would take, then stopped because I decided to look into other ideas. Then I worked for a while on a potential modern update on Lemmings. That didn’t last long, due to growing concern as to whether I could make it in a way that anyone other than me would like. Finally I tried experimenting with detective scenarios in a friend’s custom made TTRPG (this one) to see how well I could entertain players that way. The fact that the first session was 12 hours long without complaint gave me hope. Since then I’ve been struggling to dish out a 1 case prototype, hoping to make a complete and mostly polished case so I can better demonstrate that it’s actually a good idea. More on that possibly in a different post, but the main distinction should it work out would be a non-menu-based solving gui that allows the full investigation to be in the hands of players. It’s also been slow due to making the game engine (currently under the name “KEG”) at the same time, which hasn’t been easy.

[end part to skip]

This brings me up to the current topic: I tested out what I’ve got so far of my half-finished “KEG” game engine in a game jam. The details of my engine and even my entry aside, I still have a post here from the last time I entered a game jam, and I thought I look at how the two jams compared with regard to that advice.

Here’s the things from last jam and how well this jam did on each:

Read the Rules — Fairly Well

The structure this time was 1 month with no special element or topic, but making a prototype instead of a finished game. The rules were simple. All assets specific to the game had to be made in the month (so general stuff sitting around or stuff gotten from public sources was fine). Credit for assets not created by the team had to be listed in an included txt file. If an entry wasn’t disqualified (more on that later), the judges would spend up to an hour on it (depending on if a game-ending bug popped up or if the game ended early). There were categories too, but I can’t even say how they were handled since the judging hasn’t finished at time of writing. The main rule that came up was the entries had to be submitted before the deadline and then the file left unchanged (this was hosted on itch.io).

While there was mention in the forums about obvious cheaters, but they were few. From what I saw, most of the rules-based issues occurred because people tried to edit their download after the deadline, resulting in not having a game up. This is a fairly innocent mistake, and some of the cases were due to entering their game in multiple jams at once (which was explicitly allowed), so I think the participants did a good job.

One last thing of note in this category: a large number of games didn’t include the credits.txt even despite obviously using other people’s work. In one case, the game including logos from famous metal bands. Sigh. There were also a lot that only had a credits.html file, which is not the same.

Consider How Your Player Will Quit Your Game — Mostly Fine

The vast majority of entries I’ve played (140 out of 335 so far) were made in rpgmaker (so already a framework in place to quit) and/or started in windowed mode. My own entry is in the latter category since I didn’t have time to make a menu, and I am ashamed. So far the main violations of this I’ve seen were one game that had blocking loading screens (so even alt-tab wouldn’t work) and one game in rpgmaker that blocked alt-enter from working.

Start With Something Playable and Keep It Playable — Not So Much

As mentioned, a large amount of entries were in rpgmaker. This means a large amount of them focused on setup or premise but did nothing to ensure balanced gameplay. This is very backwards. If you’re not going to balance your jrpg combat, don’t have jrpg combat. Your story will be ruined by it, no matter how good it is. Worse, your prototype won’t appear as much like a good idea. Combat can be added in later if needed, so focus on what works.

Similarly, there were a lot of unity and gamemaker studio entries that tried something original and ambitions, then failed miserably. I have more sympathy here though, since they were at least focusing on the right priorities, especially for a prototype.

The worst entries in this category were the ones that weren’t video games. I don’t mean that in the weird definition of “games” sense. I mean there were multiple entries that weren’t executable pieces of software. I found two that were series of images.

Don’t Make Unskippable Cutscenes — Not. Even. Considered.

Let me first get out of the way that I forgot to tell my players how to quickly skip my text. I used the visual novel standard, but there’s no reason to expect general players to know anything about that. That said, I still allowed completing the text instantly by pressing the button. Many of the rpgmaker entries I saw used slow text that couldn’t even be made quicker and even put mandatory pauses in the middle of a line of dialogue. Don’t do that. Whatever cadence you think your characters should use, it won’t be conveyed that way. You’re just punishing people with faster reading speeds. Also, if you care about your story, let your player get on with reading it. Don’t put long pauses between lines of dialogue if your characters aren’t doing anything. What’s more, the most polished entries I could find still had repeated text triggering for inane reasons.

Single-player Is ALWAYS Important — Not Really Relevant.

Since most of the entries were adventure games or rpg’s, this didn’t come up as much. The dev who made a chess variation and included a working AI opponent deserves some recognition though.

Don’t Assume People Will Actually Play Your Work — Extreme Minority

I saw very few entries where this would be a problem, and mostly they were just due to long text scralls and unskippable flashy graphics. There were a few extreme cases though. One entry was disqualified due to trying to make the judges pay money.

Make Your Game Fun Before Making It Fun to Look At — Hoo Boy…

I’ll admit. The week I spent animating my player character might have been a bit much. The half a week I spent making a thousand tiles for the backgrounds (in batched images that made it a fraction as many images) and 20 NPCs might not have been totally necessary. However, the main reason I did both of those was in favor of gameplay. A fun parkour system actually does need a minimum amount of animation to feel good.

In comparison, multiple full pixel art backgrounds while your player character can barely do anything is not justified. Extremely detailed and nice-looking point-and-click backgrounds in which the items don’t seem to belong and the walkable areas are unclear is certainly not justified. Straight-up explicit nude character bodies in a character creation tool that isn’t needed to show of gameplay isn’t even in the same set of dimensions as justified.

That said, many of the entries had separate people doing art from the people doing design, so there were entries that managed both.

Decide on the Size of the Art Before Making It — Not Relevant

I saw one entry fail that might have failed at this, but more likely it was an asset flip. All the rpgmaker entries didn’t need to consider this, and the other ones with problems had bigger problems.

Ensure Your Game Works On Other People’s Computers — Briefly Relevant

This was one of the things that entries could be disqualified for according to the rules. I saw one entry fail to include rpgmaker distributables and 3 that failed to include unity’s dll. The participates at least knew to test for this.

Don’t Assume Other People Have Large Screens — Mostly Fine

A couple entries failed at this, though at least one clarified having simply forgotten. I’m willing to believe that.

Don’t Expect Players Using a PC to Own a Controller — Didn’t Come Up

Consider Your Game’s Controls Carefully — A Few Issues

Aside from the point-and-click that used bizarre controls, most used either typical indie controls (z, x, and arrows) or rpgmaker defaults.

Other Issues and Further Thoughts

I think the fact that this jam was on itch.io likely helped, since most of the participants had enough experience to not do stupid things. That said, there’s a lot of things that stood out anyway that I think could use mentioning, even if not with bold titles.

— rpgmaker doesn’t have good defaults for combat. And you don’t have to use its combat. If your story is good enough, just the ability to talk to who the player wants and to pick up items is good enough.

— If people are playing a prototype, knowing it’s a prototype, they’re probably going to be forgiving about mandatory tutorials. It’s better to tell them how to play, even if as a quick list of controls, than to have them struggle to figure it out. Or at the very least, include the controls in your game’s description.

— Advertising your game is fine. Advertising your website is fine. Spreading advertisement all over your game raises questions about your priorities. Advertising where to get more current versions of your game during a contest in which your entry is still being judged especially raises questions.

 

Welcome to the Lonely Tech Blog.

That title is intended to be read in a flat, deadpan tone.  The following post is written non-linearly for the sake of putting the important part at the top.  If you want to get to the point immediately, ignore the order tags, and just read the first two paragraphs right here:

[End First Jump Here]

Anyway, now that this blog is the blog of someone who is technically a professional, I feel it should have a more clear and stated purpose.  It’s here so I can ramble on about whatever technical things I’m working on as well as whatever related things I’m not disallowed to talk about due to an NDA.  If you have any questions, feel free to ask and I may even show up here more often to answer, but primarily I’ll be talking about what I feel like talking about at the time.

I’ve noticed that most game companies and even individual creators tend to be very secretive and only say what might make their game or company sound good.  I think this is stupid.  Trade secrets make no sense in the game industry, and spoilers are things that’ll happen on launch day anyway.  The only effect I’ve seen from companies trying to careful is journalists rightfully calling them out on it resulting in players distrusting them and calling them names.

[Jump to Bottom]

[Post Begins Here]

On a day that I forgot a couple months ago, I took the step to change from a hobbyist (and honestly a rather pathetic one) to a professional creator of video games.  Or rather, Steam took the step for me.  I doubt anyone reading this knew, given the total lack of readers of my previous posts, but I submitted a game to Greenlight back in late December.  It didn’t do well.  Apparently by then the corruption was complete and nothing without a kickstarter or severe lack of moral compass could get through.  So, instead, my game sat there for 6 months until Steam purged.  In the purge, my game was finally greenlit.

Skip ahead two or three months, and we get to the reason anyone would even be reading this words.  My game is finished, and I’m pretty much just writing this post on the off-chance that someone sees the links I posted on my gamepage or on the Steam store and clicks on them.  If you somehow made it here in another way, my game is called SpaceMerc and you can find it here: https://www.humblebundle.com/g/spacemerc .  Yes, that does say “humblebundle” in the link.  Their hosting service is pretty nice.

At time of writing, the Steam version is under mandatory review (yes, they do actually have review processes, they’ve even shown the team that does them to journalists).  I don’t have a link to the store page to post, nor any guarantee that things won’t go horribly wrong.  I can only hope that you reading this means it all came out okay.  Meanwhile I’m a nervous wreck with no idea what to do with myself.

[Jump to Top of Article]

[Second Jump Comes here]

Now that that’s out of the way, here’s my thoughts on what I’ve actually been working on:

Mid-Post Post: Why Game Maker Studio 1.x Is A Good Program and Why I’ll Never Use It For a Game Again.

To answer the first half, the parts that Game Maker Studio 1.x makes the user do gets the user straight to what’s most core to designing game play.  It doesn’t encourage actually good presentation, proper campaign design, or anything particularly advanced.  This doesn’t hamper it from being a great start for people who either don’t know squat about game design or don’t yet have the skill to code their own engine.

To answer the second half, it does an absolutely wretched job of accommodating a large scale project of the type expecting by the current market, indie or otherwise.  By the time SpaceMerc was at the point where I could finally give it a proper campaign for players to play through, the compile times were an hour long when compiling texture pages and 10 minutes long when compiling lesser changes.  Because it didn’t save the texture pages and keep them until a change to the images were necessary, I had to re-compile the texture pages after each time I closed the program (such as for computer updates) as well as every time I tried building for a different version.  For context, SpaceMerc has 8 at time of writing.  They are Windows DRM-free, Windows Steam, Windows Demo DRM-free, Windows Steam Demo, Linux DRM-free, Linux Steam, Linux Demo DRM-free, and Linux Steam Demo.

I think YoYo games has released Game Maker Studio 2, but I tried the trial version and wasn’t interested.  It appeared to be emphasizing almost entirely things I don’t care about, including an emphasis on higher resolution monitors.  My only computer’s monitor is 1366×768, so that’s really annoying.

What will I do instead?  Well, for the last two days I’ve been planning out and coding a potential prototype for a point-and-click adventure game engine of the classic style.  I have a few ideas on what I can try to innovate on from the classic formula, and I’d like to take a shot at them.  I’m not very hopeful though, because when it comes down to it I’m not a very good programmer.  That was why I resorted to Game Maker Studio in the first place.  I really like the multimedia library I’m using, SDL2.  I’m just not sure if I’m good enough at using it.

I posted a game. … … .

It’s been over a year since I posted anything, and I only vaguely remember what any of my previous posts were about.  Apparently the last game project I posted about was the one with robots battling.  That one lost steam when I failed to get any additional content to work or be fun.

In the time since, I spent several months experimenting on how to make my own general game engine, and I learned a lot, but it wasn’t enough for me to produce anything useful. I’ll definitely go back to it though, since I really hate working in game maker (and game maker studio 2 doesn’t look like it’ll be any more enjoyable) and c++ headers really don’t agree with me.

In the meantime, I decided to do a remake of my very first “full” game (read: all original content and more than half an hour length, but definitely sucked).  It’s a bullet hell, but with more leeway given to the player in the form of a healthbar.  I’ve been going for gameplay and progression closer to a typical FPS rather than a conventional bullet hell.  It’s going better than could be expected, and I’d like to try selling it when it’s finished.

To that end, here’s some links:

The demo I made: https://www.dropbox.com/s/nzdfnj1np4mwhzo/SpaceMerc.exe?dl=1

Steam Greenlight page: http://steamcommunity.com/sharedfiles/filedetails/?id=829436500

Humble Bundle page: https://www.humblebundle.com/g/spacemerc

Itch.io page: https://kimiyoribaka.itch.io/spacemerc

The demo has 11 levels, but I plan to add in 19 more.  The greenlight page has the youtube trailer and screenshots (as required).  On a side note, making a video is hard.  It’s even harder if your computer doesn’t have the power to handle video recording.  I had to put in a temporary video recorder in the game to ensure it recorded at 60 fps even when the game wasn’t running at that speed.

Game Jams and the Abyss Staring Back

I recently sent in a bunch of entries for this year’s Indie Speedrun (which is a terrible name for a game jam).  The goal for that game jam is a game in 48 hours containing a “theme” and an “element” specified upon starting.  Since it allowed multiple entries, I participated 6 times during the month allocated for entries.  In my own opinion, only one of the games I helped make was actually good, while a few were merely okay, and 2 seemed like they would be among the worst entries.  I still hold the same opinion on the quality of each entry, just not how they compare to the rest of the curve.

Since the contest holders encourage participants to play the other entries and rank them (out of 5 stars), I’ve been playing as many of the other entries as I can.  The horrors I’ve seen were beyond what I’d thought possible.

In the hopes of sparing the sanity of future participants of similar game jams, I’d like to offer some advice on game development, both restricted and general:

Read the Rules

If you’re making a game for entry into a contest, whether it be formal or informal, actually looking at the restrictions is very important.  If there are any judges, they will be marking you down for not following the rules, and even if there isn’t any judging going on, you won’t get the full personal benefit of the game jam if you don’t limit yourself.

Consider How Your Player Will Quit Your Game

I’ll be frank.  If you are willing to submit a game to the world that defaults to fullscreen without telling the player how to quit, you shouldn’t be making software of any sort.  Not everyone knows or readily thinks about alt-tab and alt-F4.  If your user doesn’t know about those hotkeys and you didn’t give them an explicit way to quit, then you’ve just hijacked their computer you monster.

And don’t assume your player will finish your game before quitting.  If you thought anything of the sort, you need to go deflate your ego before submitting anything to world.

Start With Something Playable and Keep It Playable

Unless you’re making a visual novel (which is really more similar to making a book than a game anyway), your game needs gameplay.  If you don’t have gameplay, you’ve failed to even make a game.  It doesn’t matter if your gameplay is just moving around and having a rectangle look at stuff.  Make it fun to move the rectangle around and look at stuff.  Then if something goes wrong and you add stuff that makes it no longer fun, you can just take the new stuff out and still have something fun.

Don’t Make Unskippable Cutscenes

This doesn’t just apply to game jams.  All games are made within a limited time and played within a limited time.  We all die eventually.  If you think your fancy artwork gliding across the screen is so worth anyone’s time, you’re wrong.  If you have enough time to make that artwork, it’s fine, but your player might not have the time to watch it.  Worse, if you’ve got a deadline, that effort to make the fancy artwork could be spent on the section of your game busy players actually care about.

And if your cutscene is just slowly typing text, stop that.  It takes less effort to make your text skippable than it does to make it type slowly.  Just listen for a keypress and make whatever variable you’re using to keep the text partially written suddenly become equal to the length of the string containing the text.  It’s that simple.

Also, don’t make your player read/watch the cutscene again.  It’s even less worth their time when repeated.

Single-player Is ALWAYS Important

Even if it’s just a tutorial, all games need to have a part where the player can play alone.  If they aren’t sure they want to play your game, players shouldn’t be bothering others so they can experiment and see how your game works.  If you don’t have enough time to make that section in addition to your main game, then don’t make a multiplayer game in the first place.

Don’t Assume People Will Actually Play Your Work

That may sound mean, but among the horrors I saw was games requiring online multiplayer via a server.  I really hope I don’t have to say any more than that.

Make Your Game Fun Before Making It Fun to Look At

Art takes time.  If you spend all your time on the art without making sure your game is enjoyable to play, then you’ll end up with a pretty game that sucks and not enough time to fix it.

Decide on the Size of the Art Before Making It

Consider the following four words: “Upscaled Anti-aliased Pixel Graphics.”  If you didn’t just cringe, you don’t have the sensibilities needed to make art for video games.

A related problem that can come up is properly made art that ends up blurry due to the graphics engine/driver scaling the art with a method that’s not appropriate.  This is especially bad on laptops with LCD screens.  It’s not always possible to avoid blurry visuals, but if the artwork is generated at the size it’s supposed to appear on the screen, the blurriness can be minimized.

Ensure Your Game Works On Other People’s Computers

No, really, this needs to be said.  If your game requires searching for resources, make sure they’re included via relative paths.  A windows shortcut isn’t going to cut it (this actually did come up).  Make sure all the dependencies are included, especially compiler specific ones.  If you built it on Linux using GCC, for example, remember that your windows port needs GCC’s dependencies (this actually did come up).  On a related topic:

Don’t Assume Other People Have Large Screens

If you can’t figure out how to deal with resolution in the engine you’re using, assume the smallest size that may be needed on the target platform.  For laptop or desktop computers this means 800×600 if the game is intended for fullscreen or 640×480 if it’s intended to be in a window or a browser.  No, really, there are still people who use monitors that small.

The default resolution for a game that has resolution options should depend on whether you know how to check the monitor size (or “display size”).  If not, see above.  If so, default to whatever you designed the game for (see artwork size advice above) and automatically decrease the resolution when needed.  Remember that if a program tries to make a window that’s too big, OS’s usually just stop them “unexpectedly”.

Also, despite what players will often say, defaulting to windowed is more user-friendly.  They may get annoyed if they’re too lazy to switch themselves, but windowed makes it easier for players to close the game if they suddenly need to stop playing or to keep track of background stuff they may be doing.

Don’t Expect Players Using a PC to Own a Controller

Desktops and Laptops are only guaranteed to include a mouse and keyboard.  All other input devices are optional and expensive.

Consider Your Game’s Controls Carefully

Remember that sitting at your laptop or desktop is most comfortable when your arms are separated from each other at an even distance from your center.  This means both that your players’ hands should be on opposite sides of they keyboard and that any movement toward the center of their keyboard is irritating.  This is why only a few fps’s back when the genre was first started used the arrows for movement rather than wasd, as having both hands to the right of the keyboard just feels wrong.

Another aspect to keep in mind is what is intuitive.  Players will be more easily able to get interested in your game if they don’t have to concentrate on the controls for very long.  This means that when necessary using wasd and a mouse is helpful, but it also means that a game that doesn’t use the mouse should have movement mapped to the arrow keys.  Those keys say what they do right on the button, and will thus be the first buttons new and casual players will guess.

One last thing to consider, a lot of keyboards don’t like handling more than three buttons at once.  More specifically, two letter keys and a system key is the most that can be expected from a non-gaming keyboard.

The Way Things Turn

A week ago, I was trying to find time to work regularly on a bullet hell system.  Now I have a working local multiplayer mode for a potential platformer featuring robots with jetpacks.  I’ve been having some trouble coming up with more ideas for mechanics and content, but the platforming feels good.  I’ve been told the images work well too.  I guess I’ll just keep going with it.

Slowly progressing in whatever way

I’m still working on the bullet hell engine.  It already has all the features that were in the prototype, but adjusted to be a bit more sensible.  Right now, what it needs most is the background handler, which theoretically should be able to loop when needed and make the level progression clear with whatever is in the image cache.  Unfortunately, the engine that I’m building all this on isn’t efficient for things it wasn’t designed for (basically anything but cutscenes), so I don’t know how much complexity I’ll be able to include without slowing down gameplay.  I’m pretty sure I’ll need to keep the entirety of the current level in memory, since I personally have no idea how to deal with multiple threads.  I should get to learning that sometime…

I did a few tests to see whether a full level’s worth of background would be too problematic.  A bitmap image large enough to scroll 4 pixels per frame for 10 minutes in 1080p only requires 116 Mb of space.  Since I’m pretty sure even old computers have a good 256 Mb of memory available (I think that’s how much consoles used to have actually), I don’t think I’ll have trouble there.

I’ve also thought quite a bit about how to handle the interface.  I definitely want to make the interface both modular and easily defined, so it can be switched out separately from the levels (in case different characters need different things on screen).  I think I’ve gotten a good system for most of it, but showing dialogue during the level will be somewhat of a challenge since the dialogue should optimally be identical to that of the renpy engine that my engine is built on.

Most of my time since last posting has been spent on a different task, however.  As a way of testing the engine once it’s finished, I’d like to remake an old shooting game I made in game maker.  Towards that task, I updated many of the ship designs at a higher resolution.  I also made a few new ones and tested how everything looks together by pasting them onto the same background.

Having written a bunch of stuff that I guess equates to a post, I’ll get back to work now.  A bunch of ideas came to me while typing.

I know I can make this, I just need to make it.

I have a really bad habit of experimenting and trying to figure out what types of things I can do in various engines while thinking of all the things that can be done.  In general, that’s not bad, but I never find myself actually making anything.  My projects folder for Ren’py is especially large because there’s a lot of things that seem like a good idea in that engine.  It does buttons and menus and cutscenes and all those sticky things I really don’t like having to do myself.  Now if I could only bring myself to do the things I like…

So recently I decided to work on something that already works and make it into something.  I’ve had a working bullet hell style shooting game system lying around for years, but for reasons I no longer remember I never did anything with it.  It’s missing a few features that would be mandatory for an actual game: music, backgrounds and anything that could help tell a story.  I also remember the boss battles not working.  However, it’s still a lot closer to a working game than most of what I’ve done.  Besides, there’s a much bigger issue that came up once I started working on it again.

I recently reset my computer while keeping only the minimal needed on it with the rest on a couple external drives.  The stuff still on my laptop did not, as I found out, include a working version of the prototype.

Now, my current use of my available time is to essentially re-make the prototype but better.  And I’ll find out successful I am after I’ve been able to find enough hours in the day when the people nearby are not being incredibly annoying and when fire alarm isn’t malfunctioning.  No, seriously, the fire alarm has been very briefly going off at random times.  By briefly I mean anywhere from 1 to 6 beeps.  The manager said it’s the air conditioner but didn’t bother to do anything.

Through hardship one must toil on I guess.  In some ways this actually better than how it’s been.

They say one needs a website

I really despise social networking.

I know that’s not really the best way to start a post on a blog, which is by definition a form of social networking, but I feel as if that’s one of the most important influences on my life right now.  So much of society nowadays assumes people like socializing online.  I guess that could be called a “first world problem,” though I think “problem with the first world” is more accurate.   It wouldn’t quite so bad if it was just Gmail thinking I should reveal my real name to the world (anyone else remember when that was a violation of the rules of the internet?) or just something some of my friends mentioned periodically, but a lot of video game developers are starting to assume people want to be social in their games.  I read about a developer recently who claimed that games being social was spreading because that’s what good trends do.  Hear my inaudible groaning, developer who I didn’t manage to remember the name of!

While I’m complaining, this paragraphing feels weird.

If you’re still reading, you may be wondering why I have a blog then.  I’ve been trying to build up my skills as a game developer, so I can make a game worthy of presenting to the world and possibly making a decent income from (the former being the more important part).  Apparently, that requires reaching out to the world before I actually release a game.  Ideally, I would prefer to just release gameplay and testing videos on Youtube, but groups like Extra Credits always advise doing more.

On that note, DAMN YOU GOOGLE PLUS!

(If you don’t understand and wish to, read paragraph 1 again.)

I’ve had this blog for years, but I haven’t touched it in a long time.  When I did finally look at it, I realized it was full of depressing posts no one would want to read (more so than this one).  So I trashed them.  Hopefully I can keep this blog more cheerful by the time anyone actually reads it.

In conclusion, here is my mandatory website.  It will NEVER have my real name on it.