This week’s foray into game development focused solely around ramping up for Devember, which will commence in less than a week. I worked on some graphic assets for the Devember project itself, and I’ve gone back over the various projects to get fully re-acquainted with my engine code. This involved spending some time sorting through various branches that I had going to remind myself what they were for. That seems somewhat more painful than it should be.

I used to use Subversion as my VCS due to that being the system that we use at work but a couple of years ago I switched to using Git. I forget now what exactly pushed me over the edge into switching, to be honest. Nevertheless I took to it with wild abandon. My general motto is “Commit early, commit often”.

In start contrast to my code at work, where everything for a particular full change set is committed in a single commit, at home I tend to make many smaller commits with small integral parts. I can’t quite put my finger on why that seems more satisfying to me, but it does. From a coding perspective it means that tracking what you’re currently working on is as simple as seeing what changes have not been committed yet. Also as a data hoarder I like to keep all of my code protected along the way (code history is awesome).

Among the many work flow changes that come with using Git is the idea of creating branches; at work we don’t branch as we have a different work style, but that’s a story for a longer, more boring blog post. I found myself this week trying to determine what exactly I was trying to accomplish with some of the branches I had laying around.

In particular, even though the branch names were descriptive enough (except for a couple of temporary ones) I couldn’t remember if I had completely finished with the changes I was trying out, or if I had switched away before I was finished. This ends up being a whole lot of diffing and a whole big pain in the butt. I feel like I should have some sort of system to help me track that kind of thing if I’m going to have a bunch of branches laying around, but I’m not sure what the best way to do that might be.

Getting back to the actual Game Development part of this Game Development blog post, I started working on some of the simple graphic assets that will be needed for the Devember project. Last year for Rx I just used simple canvas drawing, as the assets needed were fairly simple. In the intervening months I implemented a sprite and animation class which I have yet to use in any real depth, so this seems like a good time to put that through its paces and see if it needs any improvements or additions.

I tend to work best with art in a vector format due it being more forgiving, so I spent some time researching and investigating rendering SVG to canvas, even just to convert to a sprite to be used. It seems like that might be a good overall goal at some point now that the engine code has the ability to scale up to full screen. Imagine if that was accompanied by rendering a new set of higher quality assets?

This doesn’t seem as easy as it could be, so I’m not sure if that’s a good idea or not though. I might just go the route of having multiple sets of assets and choosing the correct ones based on the canvas size. That however comes with its own complications to the code as currently I’m letting the browser do the scaling of the canvas for me. It seems like I would have to let the canvas dimensions change and abstract the coordinate system myself.

For a simple prototyping engine I don’t know if that’s really anything that needs to be done, but it does seem like an interesting topic to investigate. It’s unclear to me exactly how well supported SVG might be among my chosen browser support set.

I’m thinking that if I finish the Devember prototype to my satisfaction before Devember is up, that might be an area to cover for the rest of Devember.