Progress Report

sss asked me about my thoughts on when a playable version would be out, and my response has turned detailed enough that I figured I’d make a post about it. But first, a brief announcement: My host is performing some maintenance this Friday, so my site will be down for about 30 minutes around 7 AM Pacific Standard Time.

As far as a playable version, I’m shooting for end of June. As a brief reminder, here are the three large tasks for writing my engine:

(1) Design and implement a GUI that the user sees and interacts with.

(2) Design a backend that contains all the game’s actual data

(3) Write a middle layer that takes user inputs from the GUI, and queries (and modifies) the backend appropriately, and then send the results back to the GUI to display.

I believe that (2) contains the bulk of actual lines of code.

For (1) I’m using IntelliJ’s GUI builder tool. It’s not the greatest ever, and the GUI will probably be more than a little rough at first, but it should be enough to create something playable. With that tool, creating a GUI consists of dragging and dropping some GUI elements onto a canvas, and registering a bunch of buttons.

The most complicated part of (1) is drawing the  dungeon. However, I came across an excellent tool called Grid Cartographer: http://www.davidwaltersdevelopment.com/tools/gridcart/

Essentially, this tool allows me to draw a dungeon, and save it as both an image file, and an XML document. So I can use the XML document to load the actual dungeon data into the backend, and for the frontend, rather than manually drawing lines and filling in squares like I did for Potion Wars, I can just render the dungeon image that I drew. Using that tool, I’ve managed to implement the dungeon view with a minimum of pain (so far).

I expect (3) to have the most complicated logic (particularly when it comes to combat), but the vast majority of it should be about as simple as the GUI code (take a command from the GUI, and invoke a couple of methods on the backend).

I think I have a reasonably good chance of having all the GUI code written by the end of February, and the controller code written by the end of April. I expect it’ll then take about a month to translate (and edit) the content of episode 1 day 1 from LaTeX to the mostly-JSON format that I’m using for Crimson Glow. Then, I expect it’ll take about two months to debug the engine from end to end, because you can only test so much with unit tests. GUI code in particularly is notoriously hard to test automatically.

6 thoughts on “Progress Report

  1. “As far as a playable version, I’m shooting for end of June.”

    That’s…a really long time! I feel like writing everything, including an engine, from scratch might be a bit too ambitious.

    1. Perhaps. But I passionately dislike RPGMaker’s engine, and with something like GameMaker or Verge, I’m going to be basically writing my engine from scratch anyway, since I want to do something relatively unusual.

      Plus, this will (hopefully) be a one-time cost. I’m trying very very hard to make the engine extensible and easy to modify, so that I can easily add and tweak features for this and future games.

      Plus, I won’t be writing everything. In fact, I have volunteers willing to help me write 4 out of the 5 daily activities. So at this point, I’m responsible for writing one daily event, and the main plot of each episode, as well as figuring out the larger story.

        1. My biggest gripe about is all the unnecessary delays that are embedded in the combat engine, from the time-wasting screen flash transition to the weird delays between attack animations and the actual damage done. That’s the only thing that I can really say I dislike, but I hate it with the fire of a thousand suns when games waste my time with pointless, slow, repetitive animations.

          Also, the engine really doesn’t meet my needs all that well. These aren’t deficiencies really, just examples of how the RPGMaker doesn’t really fit my needs. For example, that engine is geared towards primarily monster enemies. My games have primarily human enemies, so all the enemies would have ended up looking the same.

          Furthermore, the character portraits are anime style characters with crazy hair-dos, while I prefer more realistic coloring.

          I knew from the beginning that the game was going to be text-based, with a lot of text, so I wanted a GUI that is designed for a game that is primarily text-based. The RPGMaker’s engine is geared towards games with graphics, and relatively short text snippets.

          Finally, I wanted my game to have some sort of its own look-and-feel relative to other porn games, even if that look and feel is a hilariously basic dark screen with white text, ripped off from Wizardry: Proving Grounds of the Mad Overlord. I wanted people familiar with Crimson Glow to be able to glance at it and say “You know, I think I know that game…hey, it’s Crimson Glow!” You don’t really get that with RPGMaker games, unless you spend a lot of time developing your own graphical assets.

  2. You’re a workhouse dude. I don’t have much to say except words of encouragement. Love your work and your writing style, and can’t wait to see what you do next.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.