A quick update (but hopefully more to follow in the next couple of days).
I've been working for the last month or so on a collaboration project with another XNA developer that I met over Twitter. I won't discuss the game itself as the concept doesn't really belong to me, but this was to be my first time collaborating with someone else on a project, and I was pretty excited about it. However, I soon realised that collaboration is actually pretty hard!
The game we were working on was a concept that the other developer had already given some thought to, although I had some input in what direction we were going to take it, and in refining the concept in general. This process was actually pretty painless, I've always considered game design to be one of my weaker areas, so I was happy to defer in most situations where there was a difference of opinion.
The biggest challenge for me was working with the code itself. Alta is still very immature, and its code is very slap-dash where I've thrown in extra features as I go along. At some point later this year I plan to do a massive overhaul of Alta, both to do some much needed refactoring/ restructuring, but also to tidy up the code and document it so that another developer coming in could use the engine without much trouble.
Anyway, due to Alta not being ready for collaboration, we used the other developer's engine as a codebase. This meant me working to his coding style and standards, which is a completely new experience for me, and one that I'll admit I struggled with at first. It felt very limiting in some ways.
When I have no restrictions on how I code, I can work very iteratively, throwing in a few lines of code, hitting build and run, dealing with any errors, testing, and then going back to the beginning and fixing bugs/ refining. This tends to work very well for me, and makes me feel like I'm being productive. The downside is that if I don't take the time to go back and refactor my code and generally neaten it up and document it, then it becomes a mess that only I can navigate (much like my room as a teenager!).
So working to a coding style that was very neat and ordered was a big transition for me. I found myself holding back on checking in code that I'd written because although it worked (usually! no one's perfect...) it wasn't neat/ in the same style as the other code in the engine, and later the game code. This meant that I wasn't checking in code as quickly as I'd like, and features and progress seemed to take a long time to implement. This in turn lead to a down turn in morale for me, as the project was very quickly falling behind schedule.
Added to that, both myself and the other developer had other commitments, myself mostly to work, college, and family, and he to other projects that he was already working with others on. Perhaps inevitably, eventually we both agreed that the project should be sidelined for the moment, and that we'd come back to it later on.
I still intend to work on the project as a side project, and I'd really like to collaborate with the developer again in the future, as he's a great guy, and despite the initial pain I described above, I really learnt a lot from the short time that I was working with him.
But for now, I'm back to focusing on Sphero. It won't be in any way ready for DBP this year, but my aim is to have a good working prototype with placeholder art ready by then, and then spend the next year refining it and creating or commissioning the art, and polishing it till it shines.
In the meantime I'll still be posting about Farseer as I learn more about it, about the development of Alta as I progress through creating Sphero, and any other projects I pick up along the way (my Unity interface is still on the cards!).
That's all for now, I hope to have a mini roadmap for Sphero to share at some point tomorrow.
Bye for now!
