The addition this week was of a bit of animation to bring life to the character, this isn’t intended to be the end movement – just amusing animation. I might split this off as a separate game itself because I was in stitches.
The perhaps less noticeable part is that there’s now audio for the rain which there wasn’t before. This isn’t even a recording of rain, it’s the sound of oil/water boiling/bubbling away with a bit of added effects and hissing removed thanks to Audacity.
We’re getting there, slowly. Part of the experimentation is shaping the game as much as the original concept is.
I take a relaxed approach to the project development I do, because I have a full time job and a home and my health to care for. This is why I dedicate at least an hour a week to the game development, to coax it into action. Over the holidays it has been a bit stagnant due to being away from the computer. So it amazes me even more as to the advancement we can do with just a small amount of time.
Here we have a moveable character, with a platform, collision, particles and, though you cannot hear it, background music.
As a small team of two people it may seem a bit over complicated to introduce the practicalities of source control. Or may be what I mean is “revision control“.
I think this is the best time to do it though, because you can learn how it works, how it doesn’t work how you may think and what can go wrong. For example, for the current project we’re both working on an ActionScript v3 project in FlashDevelop, utilising BitBucket. The first stumbling block we happened upon was that, the two don’t directly integrate. It involves the use of at least three to four other applications which, handily, are compacted together into tools such as TortoiseHg and PuTTY – the former contains some hybrid of Mercurial/Git to some extent.
So after discovering that the SourceControl in FlashDevelop doesn’t appear to work beyond ‘Commit’ for the files that have changed (synchronising, especially on the fly doesn’t appear to work from the guides we have found) that having more than one person share the ‘main’ or ‘trunk’ of your project source is just not a good way to go about it:
Simply put, partly because I lack the ability to describe what’s going on short of the Wikipedia article on source control, it turns into a mess as shown by what I will call the ‘tree’ (or headed Graph) on the left hand side.
Suffice to say, we’ve decided that to help separate development it may actually be better for us to have a main project which either one or no persons work on it directly, but they ‘fork’ it (effectively making a copy) and then commit and push to their own, with ‘builds’ of files they’ve changed, pushed to the main ‘trunk’ (or main project as I stated) which then means, there’s only merges done that make sense and people can happily mess up their own copy, while re-cloning or pulling from the trunk as required.
It’s taken a bit to get our head around, I try to think of it as a main river splitting off into streams, or a tree trunk into branches (probably the common analogy).
