After a surprisingly easy process, I now have my Unity project stored under source control. I had some sound advice from a fellow developer (thanks Andrew), and instead of trying to use Git with Dropbox I created a private repository using BitBucket’s free service and manage my source code with SourceTree. After quickly running through the tutorials it was pretty straightforward to upload my work into a fresh repo, then check in some minor changes to confirm it all worked. SourceTree is a really nice tool to use too, and whilst I do like diving into the command line this seems like it will be a much simpler process. I’ve also get the Visual Studio tools for Unity working correctly too. Turns out it’s also pretty easy to do so long as you actually read the documentation. This will be a massive time saver for me next time I’m having trouble debugging.
I didn’t have a great deal of free time this sprint, but I did manage to squeeze some in to look at ways to calculate hit percentages to keep it fair and balanced. Unfortunately I haven’t found much information on that topic, mostly just articles on AI decision trees, although I did discover several fascinating articles on probability in games such as XCOM. The biggest discovery was learning that the random number generator isn’t as broken and unfair as everything thinks it is. What I did learn though is that even completely balanced systems will seem unfair to a good number of players. Not really an issue when I don’t have much of a game, but something to keep in mind when I eventually get to playtesting. I’ll have to schedule in some more research into this area for later, but for now I’ll make do with some really simple calculations based on the range and amount of cover.
Speaking of which, I managed to do some research into cover mechanics too. Again I mostly found irrelevant articles on AI, but I did find one interesting perspective on the Unity3d boards, and I can see where they’re coming from. At the end of the day it doesn’t matter what fancy pants calculations you have in the background, it’s what the player perceives that’s important. One memory I have of playing Necromunda though is looming over the game table, carefully nudging characters around to try to line up a shot that will just get past most of the cover. If I want this then I can’t get away with a simpler cover system based on position and direction which games such as XCOM use. So I guess that means doing things the hard way. There’s a bunch of fancy calculations I can use for this, and that’s top of the list to get working for next month, as well as showing the hit chance to the player.
For next sprint I want to finish off the work I started on ranged combat, and get to the point where you can shoot someone and inflict damage. I’ll also want to get a number of characters in different teams and switch between them as you move around shooting each other. Shouldn’t be much longer before I’ve got something I can call a rough prototype.
You can see the Trello board for my current sprint here.