Parade of Rain

I had planned to put up more of a tutorial post on rendering adaptive 2D grids for things like editors and such, since it was something I recently implemented. I got it working in my editor but then when I tried to conjure up a more “simplified” version in Blitzmax without any of the abstractions of a scenegraph, camera, and other numerous things I found I was tripping up over Blitzmax’s own graphics commands O_o. Being impatient I took the route of “at least it works in my system” and I’m just going to point you to a code listing that helped me generally implement it. Moving along now…

Since working on my weekend “Gunstyle 2″ project I’ve had to develop a map editor that allows a mapper to save map files and load them into the game. In the first iteration of the game we had written the map files as binary files with all the assets needed in a single map file. On the 2nd iteration for the XNA Dream.Build.Play competition we used TorqueX as our engine of choice and it used XML files to serialize assets. After developing in both and developing the “next” version of Gunstyle in Blitzmax, I’ve had to tackle the decision of which type of serializing the framework and game would use.

I opted for XML in the end. The reasons were:

• Portability - Something we wanted to do with the newest version of the game was pull over some of our levels from the original and the XNA/TorqueX version so we could quickly test gameplay on fully-developed maps. Massaging a binary file to be compatible with another binary format is a headache to say the least. The maps in the original Gunstyle were binary, so I took the route of exporting the maps to an XML format. the Binary-> XML conversion wasn’t easy either, but once in XML updating the schema as the framework evolved was A LOT less painful. Extracting the geometry of levels from our XNA version (which was actually a custom XML file outside of TorqueX) proved to be trivial also.
• Readability - This is a difficult one to prove that is useful. If a binary file is valid, why do you need to read it? During development of the file format, being able to read the file output helps with debugging.
• Flexibility - With XML, you can treat the map file almost like a database. Using XPath or some other way of querying the data, you aren’t restricted to the exact order things are in the file.
• Ease of editing – With XML I can now leverage text editors to do simple edits in a map file rather than writing some custom tool to do what amounts to a basic  ‘search/replace’ for a map if, for example, an asset name is changed.

While using XML did give me some benefits, there were some trade offs I had to deal with:

• Non-Encapsulation – Now a map file no longer was a single monolithic file. Which to me seems ‘cleaner’ and is much easier to distribute. Maps consisted of an XML file that essentially described the geometry, scenegraph layout, and where to find the textures and audio.
• More Verbose Code – Writing a binary file in Blitzmax is less lines of code than writing an XML file (I’m using a binding to libxml by the way).

On the topic of encapsulation, I really liked having maps be a single file you can send to someone and be able to play. This also greatly simplified the auto-download feature of our previous game where we simply looked for the missing map file. I suspect to get this type of simplicity for users I would have to implement a virtual file system for the game and have assets and XML files be wrapped up in zip files or something. I’m fine with dealing with more verbose code as the benefits outweigh the downsides in my opinion.

There’s definitely more down-sides to using XML over binary than I listed above, but I can’t think of any at the moment. I attribute this to my hunger. I am now going to proceed to feed my face, play some games, and start doing some networking work .  Just as a note, I will be traveling for the next week-ish, so don’t be surprised if I don’t get a new (hopefully more insightful/useful post than this one) post up next weekend. Happy Labor Day Holiday!

One thing I’ve learned from working on games along side a day job is it takes a very strong commitment otherwise it will grind to a halt shortly after starting. You have to plan for the long haul as any game worth playing, or better yet paying for, requires much more time than you think. Especially if it’s your first ‘commercial’ endeavor. Planning is paramount if you wish to have any chance in succeeding. I have more thoughts on planning that I want to explore in future posts, but for now I just wanted to share some data for anyone else also pondering how to best fit indie game development into their already busy schedules.

The 10 hour work day

So for the past couple of months I’ve been working 10-hour days for 4 days a week at my normal day job. This means I never work Fridays. My original thinking was that having a whole day off to just work on my game would prove to be very helpful as it could be treated as a whole uninterrupted 8-hour work day. The drawback was my Monday-Thursdays were extremely busy. I knew doing this schedule would require some serious discipline to pull off and still keep physically active as to not adversely affect my health. As a result, my daily routine was rather strict and had pretty close to zero room for any hiccups or delays. Got stuck in traffic? Just lost an hour of coding. Had to run to grocery store mid-week? Just lost another hour of coding. Parents/family/friends call to chit-chat? That night of coding is probably gone. It was a constant battle to try to keep on schedule.

Ultimately, I mitigated the delays, but at the expense of sleep. What’s interesting is it wasn’t a completely conscious decision. As I kept struggling to catch up on trying to fit a few hours of coding time a night I slipped a little later into the night as the weeks went by. Eventually I was down to 5.5-6 hours of sleep a night. Some people can function with that, while others (like me) can’t sustain that sleep schedule for long. In fact, I could only last til Wednesdays on that schedule before I started noticing it was affecting me during the day.

Regardless, I pressed on for another month on this routine. It wasn’t until I started noticing I had stopped losing weight and was actually beginning to pack on weight that I decided I needed to reevaluate my plan. I have a daily routine of jogging and working out after work and it’s something I try very hard to maintain so that the long hours I put in sitting at a desk at work and at home working on my games doesn’t ruin my health. This wasn’t the only red flag that told me to reevaluate though. There were others:

• Even with Friday off I still couldn’t achieve the ’8 hours’ of indie work on Fridays. With Monday-Thursday being so busy I had to put off an errands, shopping, routine weekly tasks to Friday if the services weren’t available on the weekends. This typically ate up half of my day.
• To further hurt my productivity on Fridays, I was so tired by that time that I typically could only muster anywhere from 2-4 hours of actual work on Fridays. This wasn’t much more than my typical nights on Monday-Thursday.
• With no wiggle room during the week my relationships with family/friends were extremely hard to maintain. Any time spent keeping in touch was directly any time I had ‘lost’ for the day to work on my game. Having general ‘social’ time throughout the week is important. But you knew that already .

Ok, so those were all reasons for leaving a 10 hour schedule behind. But what do my timelogs say?

8-hour vs 10-hour. Fight!

The above is just a small summary of timelog data I’ve kept track in Excel over the last 3 months working 10-hour work days for the most part. It’s far from perfect, but it serves its purpose. The interesting number there is ‘Totals’. At 14 hours and 44 minutes I was working a rather crazy schedule. And as mentioned earlier, my Fridays ended up being no different than any other day of the week. My Mondays interestingly had a consistently lower time (case of the Mondays perphaps?).

Data is wonderful. It allows you to make predictions based off realistic performances. I had this fantasy of working ’8 hours’ on Fridays, and it ultimately proved to be fictitious. So was my original thinking that 8-hour work days wouldn’t allow me a large enough chunk of hours during the week to get anything worthwhile done? After some number crunching I found two very compelling facts:

• Working 8-hours a day Mon-Friday at a day job and working on the game just Monday through Thursday would give me AT LEAST the same amount of hours I would get working 10′s, and in the best case scenario I could gain 3-4 more hours a week.
• I would be able to get 7-8 hours of sleep a night consistently.

Any experiment was in order. So I decided to work 8 hour days the last week and the results are in:

Hah, Success! So after coming home from “work” two hours earlier I was able to work on my game for only 4 of the days of the week and STILL get about the same amount of hours in with the 10-hour/day schedule. And you know what the best part is?

• I could have some semblance of a life now. I could hang out with friends, talk to family, any time inside the week and not fear that I was losing time
• I could get some decent amount of sleep
• Overall quality of life was higher

The End Is Nigh

Looking back on the data and my memories of the past couple of months, it seems obvious that an 8-hour work schedule for my day job would’ve been the better bet. But I seem to have been caught up on the idea of having a whole day to my game seeming like a great way to make progress on it in large chunks. In reality, I couldn’t ignore the other things that needed to be done that week and Friday became ‘catch up on errands’ day rather than ‘Tilt To Live Development’ day. Now, the 10-hour work week I still believe is completely workable if you wanted to work into the weekend and simply did not work on anything after work during the week. This approach is good I think for the ‘weekend warrior’, but I tend to want to reserve my weekends for relaxing, hanging with friends, and playing games .

So anyone who is in my position of deciding what type of work schedule to run at their day job while trying to finish their own indie game hopefully will find some of this data useful. I know some companies offer 9-hour work schedules with either half-day Fridays or every other Friday off, but I think I would still decide to go with the 8s. I’ve found that spreading the hours across the week helps me keep up a higher level of productivity and motivation than trying to cram it into the end of the week or weekend. You have to treat the development of your game like a jog, not a sprint. My major flaw was thinking that working for long concentrated hours (ie on Fridays) was better than short sustained sessions across the week. When it comes to coding it’s hard to start and stop constantly, but it’s something I have to get use to. I’ve noticed as time goes on I’ve become better at breaking up seemingly monolithic tasks into workable chunks.

In the end, the most important thing to find is balance. I believe I may have found mine for the time being…

I’m currently working on an editor for the next iteration of Gunstyle on the weekends. I find it’s a nice break from iPhone development and lets me start the week with renewed energy to work on Tilt To Live again. I’m using wxMax to develop the UI for the actual editor. It’s not much at the moment but it’s coming together slowly. The editor code architecture is taking a page from the Unreal engine mentality of having your engine and editor be pretty much one in the same. After a little re-jiggering the internals of my framework I can now run a blitzmax game using my framework in a normal graphics window or inside an editor. The code running the actual game logic doesn’t have to know which mode it is in unless it really wants to, so it’s pretty transparent from the viewpoint of game code.

As for the editor code, that’s another beast entirely and it really adds complexity to the code base. I haven’t decided yet how “integrated” I want the editor in the game framework I have. Currently, 99% of the editor code lies on the game code layer, above the framework, and the framework just has some functionality for handling the switching between OpenGL window and a wx Application. The reason it makes this difficult is there are a set of opposing goals I’m dealing with here:

• If I want to be able to re-use this framework for future projects, I don’t want to pigeon hole myself into a position where the editor is only good at making 2D side-scrolling physics-based maps. This mentality leads to where I am right now with the editor living largely outside the framework and just hooking into it.
• If I want my framework to have a fully functioning editor, this will undoubtedly turn into a “Gunstyle Engine”. As I will want to make tools to specifically aid in creating Gunstyle maps and objects. Is that a bad thing? From a time and goal perspective, no. From an idealistic point of view, I want the framework to be ‘general’.
• A potential compromise between the two opposing points above is to create a ‘generic’ editor that exposes a lot of hooks and ability to code in new tools. While a good way to approach this, I’m only doing this for fun and the end goal is to have a fun game to play. As someone with a limited time and constrained resources I cannot take on this approach as it’s a whole project unto itself.

So as a result, I’m left with either:

1. A one-off editor for Gunstyle. The code from this editor could potentially be re-used for future games but will be specifically designed to work with the Gunstyle game.
2. An integrated editor in the framework. In my mind, this would graduate the code from “framework” to “engine” code-base as it would introduce not only a set of API’s but a basic content-pipeline for creating content for this code base.

The main reason the one-off editor approach caused me to pause is there have been situations where I want to include functionality in the core of the editor (in the framework layer) but it would require me to pull in a lot of game specific functionality into the core as well. So I’m sure this is leading to several less than optimal code design decisions because I’m trying to tackle a game specific editor while simultaneously trying to develop a bare-bones editor.

An example of this is I’ve added a line tool to the editor this weekend. The line tool creates a physics based line object into the map for Gunstyle. Now, I feel a basic line and box editing tool is something that could be added to the core of the framework. The problem? The framework has no physics functionality. Physics is all on the game-layer. Currently, the 2D rigid body physics engine is home-grown, but physics is one of those things where I would like to switch out from project to project (using Box2D, Chipmunk, or Farseer). As a result, I’ve yet to roll any physics engine into the core of the framework.

After getting all of that written out in front of me, I think I’ll be sticking to the one-off editor route for this project. If anything comes of Gunstyle and it’s editor I’ll probably be more willing to roll more of the game editor into the core and just go the ‘engine’ route in the future. But for now, I’m trying to focus on Getting This Thing Done. And coding a generic solution to a specific problem is not the best way to Get It Done.

I try to avoid music with lyrics while working as it ends up being distracting for me when trying to work through some problem or bug. For the last several years I’ve been listening to chillout/lounge/ambient music. A couple of the sites I tune in to in case you wish to expand your listening playlist:

Digitally Imported – Chillout Channel
SomaFM – Groove Salad