Ok, it’s game-making week! I am not sure where to start, so I’m starting by writing stream-of-consciousness in Scrivener in my “Blog Posts 2015” folder.

Starting has always been hard for me, particularly when I’m not sure where to start. Making a game is a pretty daunting task, too, because there are so many parts to it. To make it more doable, I’m setting some limits now, knowing that I can lift them later once I have a better feel for how the process is working. The posts in this series (which you can find under tag 1401) are going to be fairly technical, but I’ll try to make them as general audience as I can.

STARTING THE WORK

First of all, I’m setting a daily minimum time limit of 15 minutes, and at most 2 hours. 15 minutes a day to think about a project, though it doesn’t seem like much, is plenty of time to splash around and orient one’s self productively. Also, since it’s only 15 minutes, it doesn’t seem like a big deal. At yet, because it’s only 15 minutes, one feels a bit of pressure to actually make use of it. I’m about 5 minutes into my 15 minute session at this point.

Second, I’m setting a single goal at a time, and make them very specific and immediate. Today’s goal is to look at the existing code base for project 1401 and see where I left off. For me, goals that come in the form of questions seem to work better, particularly in the early stages of a project when I’m not sure what I’m doing yet.

So let me pop over to my repo and see what’s there. It’s basically the development skeleton for developing more code:

• A Durandal-based web application skeleton with Mimosa build tools installed.
• A skeleton game framework, based on an old version of the UCLA Step engine

When I run the program, I see a grid pop-up with a hint to look at the Javascript console. It’s basically at the state where I could start defining and drawing objects through the ThreeJS graphics library, which is quite capable!

At this point, my 15 minutes are up, but I feel like going on. A couple of thoughts.

• I commited this version of the code 5 months ago. Since then, I’ve made several architectural improvements to the UCLA Step engine, and I’d like to make those improvements.
• I’ve also been thinking about better ways to define modules that use Javascript classes and data structures, in the context with the overall system. I’d like to make those adjustments too.
• I’d like to write “code tests” for common interactive tasks, which would test the simplicity and expressiveness of module APIs.
• As a concrete goal, I’d like to have a spaceship moving around in a star field under keyboard control.

That’s a lot to think about, so applying my “single goal at a time”, My first thought is that I should start with reorganizing the system startup and interaction loop with an eye toward defining “system level services” separately from “activity level services”. However, that’s still a nebulous goal, so let me whittle it down thought-by-thought:

1. System level services are ones that are always available and running. Activity Loading/Running, Settings Management, Data Storage and Management, Timers, Events, and Triggers all fall into this.
2. Activity level services are optional, and are loaded by the activity (the game) itself as needed. The main ones are the Renderer, the Piece Manager, the Sound Manager, and the Visual Manager. The activity needs to load and initialize these managers explicitly before they can be used, unlike the system-level services. Possibly they should all be system-level managers, since they are common….I’m not sure.
3. Activity submodules also need to tap-into the main game loop. These are reusable code modules that implement useful game-specific features, and work with the well-defined system loop.
4. Javascript classes can be used by any code module, are are usually defined with them. But for better code organization, it would be nice to have a convention for storing pure classes somewhere they can be reused.
5. There probably are kinds of modules that are not exactly part of system level, but are useful middleware. For example, a joystick module would be nice to have, usable by any game activity defined without having to re-include it.
6. Asset management (images, sounds) also have system, activity, and sharable components. I would like to avoid copying these assets around. Perhaps the node server can be written to serve these assets in a cascading fashion. That would be cool!
7. Activities should be as self-contained as possible, with every bit of code that is not part of middleware or system in the same subfolder. This includes media assets.

It’s been about 30 minutes since I started writing, and from the above list I now have a set of criterion around which I can organize my next actions. Let me present the goal in two parts:

• HIGH LEVEL GOAL: Reorganize System Services and Module Definition/Invocation
• ACTION PLAN: Reorganize directory structure to reflect system, middleware, and code modules. Also designate places for independent classes and media for each system level.

So that’s today’s goal. I’ll get to work on it when I get home.

UPDATE

When I got home, I opened up the files and started looking through the changes I needed to make. I quickly got a headache and physically felt very tired. I sat on the couch, and slept for perhaps an hour with the cats. When I woke up, I thought perhaps that my sleepiness was a mental reaction to the sheer amount of change I had to do; I could not easily visualize what all that change would look like, or even if it would work. This was depressing, and my brain might have shut down.

So I thought perhaps I should just make one simple change that I knew would be a step in the right direction, and didn’t think of all the ramifications that decision would make. I didn’t worry about having to redo the work, or breaking the system. I tried not to worry. I tried just to do and react.

The advice to “do and react” over “plan carefully and foresee problems” seems to go against common wisdom. Personally, I hate being reactionary. However, in this specific case of rewriting and reorganizing code, it seemed to work. Over a couple of hours, I strove to refine what I had so it made more sense and continued to run. I think what mattered was that I could trust myself to make and assess decisions, and correct myself as necessary. If my code had been a “live” system that others depended on, I wouldn’t have had the luxury of changing the entire directory structure, but right now this isn’t a problem. JUST PLAY is perfectly fine, right now.

The net result is that I think I’ve made some improvements to the overall directory structure:

• Rather than have all the files in javascripts/app, they are now spread into app, 1401, and 1401-games, which corresponds to the Durandal Framework, the 1401 system itself, and games that use the 1401 components. This makes it much easier to find a specific piece of code within a particular context, whereas before it was lots of drilling-down into folders.
• The 1401 directory is further divided into js-extend, objects, system directories, with the master.js and settings.js files remaining in the top level.

A few code improvements that I’ve made is to start shifting initialization and per-frame update of system modules into master.js itself, so the game itself doesn’t have to call them.

I’ve worked on this from around 8:15PM to 11:00PM, and I am feeling a little fried. I may push a little more and clean up the “game loop management” objects because this is an older version of the concept. I’m feeling a little blocked on this, because I don’t really want do it, but perhaps I can apply the same “do and react” approach again.

FINAL TIMELINE

I’m always curious how long something actually takes me:

I think that’s enough for today. While nothing looks different on the surface, the underlying work is a big step forward in cleaning up the event architecture. There is much less folder nesting than before, and it feels very clean. Tomorrow, I will be looking at the rendering system’s camera setup. I’ve been wanting to refactor this for some time in our other project, so this is a good time to clean it up. After that, cleaning up the sprite and piece system is next. I expect this will take me through Wednesday.