Monthly Archives: April 2015

Making a Game – Report 7

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.

Leave a comment

Posted by on April 22, 2015 in Making a Game


Making a Game – Report 6

This sprint I managed to refactor the movement system, so now it can group multiple movement steps into a single action, which in comes in handy when someone’s climbing a ladder.  That might not sound like much on the surface, but it sure makes the code a lot neater and easier to manage when planning your movements out.  I’ve also completed a very simple aiming mode,  Right now all you can do is look at the different targets available, with no regards to their team, distance, cover, or any other factors (it does stop you from aiming at yourself though).  There’s a lot more work left to so here.  I’ve also added a few more UI buttons to allow you to cycle through targets and move the camera up/down levels as you view the map.  It does the job for now, but it’s starting to look a bit crowded.  This will be high on my list of things to fix when I start tidying everything up.

I didn’t get around sorting out my problems with the Visual Studio Tools for Unity, and that’s something that’s going to come back to bite me if I don’t get it sorted soon.  With the combat mechanics next on my plate, it will be a real pain to debug if I’m trawling through log files instead of watching the data as it changes.  I also need to sort out some form of source control for this.  Right now, everything’s backed up, but not in a way which makes it easy for me to go back through older versions of my code.

For the next sprint, I’m going to first get Visual Studio tools for Unity working.  If I don’t do it now, I probably never will.  After that, source control.  With a quick Google it seems that it’s fairly straightforward to use Dropbox to host a private Git repo, which sounds good as I don’t really want to make everything open source.  After that’s all done I’m going to focus on the more in-depth combat mechanics.  I could probably come up with a few formulas myself to decide on the hit percentages, but there’s likely a wealth of material out there already which covers this sort of thing in greater detail.  After I find and read through said material, I’ll start putting them into play, and show the likelihood of hitting a target based on distance, elevation, and cover.  When that’s all completed I can take a look at tidying things up a bit to see what’s needed for a tech demo of sorts.  It’s far too early to call it an Alpha or the like, but when you can at least move people around and have them shoot at one another, it’s got enough in it to show off.

You can see the Trello board for my current sprint here.

Leave a comment

Posted by on April 6, 2015 in Making a Game