RSS

Monthly Archives: May 2015

Making a Game – Report 9 (Tech Demo released)


What I did

This sprint turned out pretty well, with all but one item completed.  First off was the outstanding issue from last sprint, where I was trying to give all characters a health level and take them out of the game when this runs out.  When their health reaches zero, the character collapses and can no longer be selected to play, or targeted when aiming.  I also fixed a small bug when starting the game where the initially selected character couldn’t take any actions.

I tied up the user interface a bit, and now any buttons which you can’t select are hidden from view when they’re not available.  The interface as a whole needs a much neater design, but I’m not going to spend too much time on that until I’ve got a general design and theme finalised so that I can make something that compliments it.  I also stopped button presses from being treated as movements when the two areas overlapped.  It was occasionally causing problems but mostly it was just annoying.

I’ve changed the team’s appearances so that now they look different (Team A are generic soldiers, while Team B are generic SWAT members).  They’re still very much placeholder models, but at least they look a bit better than they did.  I also stopped them from remaining tilted when leaving aim mode.  They now go back to their forward-facing position when you switch back to movement mode, or take a shot.  Finally on teams, I’ve got the camera to flip 180° when you switch between teams.  Later when I’ve made the team members turn correctly I’ll position the camera behind them properly, but this will do for now as I was forever rotating my view around when switching teams.

I’ve improved the movement code a bit too.  A bug in how I’d set up the movement lines meant it wasn’t showing you moving up ladders correctly after clicking a hot spot.  It now maps out correctly.  I also tidied up some of the code which was causing the game to get confused about which level a person was on, allowing them to walk out over thin air.  I’m not convinced that I’ve closed this off completely, but I haven’t figured out a way to reliably trigger this since.  The movement circle now shows the correct distance a character can move during their movement phase… usually.  To get this to display correctly I have to multiply the remaining movement by 3.  But every so often I’ll be testing the game later and find that it falls short, and I now have to multiply it by 3.33.  Then later again I’ll have to change it back to 3.  This doesn’t seem to be related to how much movement is left, and when it works it works consistently throughout the game.  I need to do some more investigation into this, but I’m drawing a blank.

And finally, I spent some time tidying up the demo level I was using, adding some extra buildings, some blocking walls and a number of different textures.  They’re still very much placeholders, but it helps give me an idea of what types of textures to use.  So far I’m favouring the metal ones which you can see in the screenshots below, but I’m curious what everyone else thinks.

Scenery 1

Scenery 2

And finally, I’ve released an initial tech demo.  It’s not really much of a game currently, and it’s missing a lot of features before it could be considered one, but it gives a general idea of the feel I’m going for.  If you’re interested you can find it here, just unzip and run.  I haven’t put in an exit button yet, so the only way to exist the game if you’re in full-screen mode is to ALT+F4.  When you’ve taken out the last target the game just sits there and waits for you to quit.  Not ideal, but it is an early tech demo after all.  The controls are the Left mouse button to perform actions, Right mouse button to undo a movement waypoint, the WASD keys to move the camera, and Q and E keys to rotate the view.

What I didn’t do

I wanted to make the Camera move up/down levels automatically as your plan your path across different levels.  Unfortunately I’ve realised that the way I’ve written the movement system doesn’t allow this, and carries a lot of other restrictions to boot.  This will need refactoring to make it fit in with how I’ve structured the rest of the project, but it’s not a high priority.  I’ll note it down and work it into a future sprint.

What I will do next

For the next sprint I’d like to improve the look and feel of the game some more.  I’d like add in health bars for each character so you can see how close to death they are.  I’m used to being able to see this in the code at the same time as running through a demo, and it wasn’t until I was testing the tech demo that I’d put nothing in place for this.  A game over screen would be nice too, as currently the game just sits there after you’ve taken out the last target.  Some sort of indicator that you’ve won would be nice.  I need a quit button too, ALT+F4 isn’t a good way to leave, and this is also something I didn’t realise was missing while developing.

I’m not happy with the way the shooting works, it really needs some sort of cover mechanics.  I won’t go into the depth I’d originally planned just yet, mainly because I don’t have any girders, but I’ll figure out how much of the target you can see, and use that.  Some sort of indicator next to the targeting reticle.  I also want to add a delay into moving to the next character after you take the shot, and add in a basic animation showing you hitting or missing your target.  As always, it’ll be a simple placeholder for now and I can substitute in proper firing animations later on.

Movement wise I want to tidy it up slightly by turning the character to face the direction they’re moving, and leaving them facing the target they’ve just fired at (so long as they’re not tilting into the scenery).  I’d also like to replace the movement circle with something which more closely resembles a circle than the large polygon that’s there now.

Depending on how well I do with these items I might end up adding a few more items, but this will do for now.  As always you can see the state of my current sprint by looking at my Trello board.

 
Leave a comment

Posted by on May 17, 2015 in Making a Game

 

Tags:

Making a Game – Report 8


A busy bank holiday weekend threw me off, so this one’s up a few days late.  It’s been a very productive sprint, with only 2 items left incomplete from my Trello board.  I’m now able to detect whether two characters can “see” each other by drawing a straight line from the head of one to the head of another.  It doesn’t take into account things like partial cover yet, but it at least lets you know if they’re behind a building.  I’ve discovered that the aim-cam I’ve set up will need some tweaking, as it makes it look like you can see a character from some positions, despite the edge of the building being completely in your way.  I want to tackle that next sprint, as it’s going to cause problems if I’m constantly getting confused about Colliders and Raycasting.  I’ve also got a rough hit chance calculation in place for when you take a shot.  It’s pretty basic, only reducing it based on distance, but I don’t need anything fancier until I’ve got a more thorough design done for this weaponry and combat in general.  If you do hit someone they take damage, but this doesn’t have any in-game effect.  That’s going to take a bit of thinking about, but I can polish it off at the start of next sprint.

Finally for combat, firing a shot ends the turn and moves play to the next character.  There’s some flakiness still, as it does this at the same time that it tells you whether you’re shot hit, and what happened to your target.  Usually you’d sort this by spinning this out into a separate thread to tidy things up after a certain amount of time passes, but in Unity you can only do certain things, like hide the aiming crosshair, from the main thread.  And I can’t delay that thread too much without blocking the UI, which would also stops things such as firing animations, watching characters take damage, etc.  It seems that the accepted way to fix this is to start a timer and move the code to sort out these changes into the Update thread.  I’m not particularly fond of this idea as it will clog up the main Update thread and you lose some control over when the difference actions will occur, but at the moment I can’t see an alternative.

While it’s not as big as getting basic ranged combat working, I’ve now got some rough team mechanics in place.  Again, it’s nothing major, but characters are now split into 2 teams, with members of each one only able to shoot the others.  I’m not sure if I’ll be changing it later, but the way it works now it will always shift to the next usable character in the other team.  So if Team A has 3 members and Team B only has 1, it will always change to that 1 member after Team A finishes their turn.  I took some inspiration from Worms here, where even if you’re one or two team members down, you can still scrape through to victory with one plucky survivor.  It’s never felt enjoyable to me when you lose someone early on and it ruins your chances for the rest of the game just down to sheer numbers.

As said a couple of times earlier, I’ve only partially implemented health.  Each character has a health score which starts at 100, and when it reaches 0 they’re taken out of the game.  I’ve also not worked on the cover mechanics yet, using simple line of sight to decide if they can shoot someone, and this will take a bit more thinking about.  If someone’s hidden behind a barricade with only a few gaps in it, then that would be considered heavy cover, but if the person behind the barricade is shooting, should the other guy also be considered behind heavy cover because the barricade’s between them?  I’d say no, but then how close to the barricade should you be for this to not be the case?  What about if it’s not a barricade, but a gap between two large obstacles, such as buildings.  How far can this impromptu cover go out before you can’t just aim around it and stop them from using it as such?  What about two people on opposite sides of a set of girders, should both of them or neither of them get cover?  So yeah, this will need a bit more thinking about before I try to do anything.  It may just be safer to put this off until later so I don’t end up doing a bunch of work that’ll need completely rewriting after a design change later on.

Which brings us to next sprint.  The first thing that needs finishing off is taking characters out of the game when they run down to 0 health.  I’d like to keep their models around, so I plan on pushing them over to show where they were.  The game will also need to end up there’s no more characters alive on one team.  While I’m likely to leave full cover calculation until later, I’d like to put some rough work into place so you at least get some protection from standing behind a chest-high wall while shooting out at someone standing out in the open.  Other than this I want to focus on tidying things up a bit so I can start taking some screenshots.  There’s a lot of huge buttons all over the place, some of which don’t matter when you’re moving, and others which are just as useless when aiming.  It makes sense to hide those and free up more of the screen.  I also want to stop a button-press from counting as movement if it’s positioned over a walkable piece of terrain.  I’ve looked into this before early on, but I hope that now I know more, I can figure out where I was going wrong.  Mostly there’s just lots of little tidying up tasks that need working, which aren’t worth going into major detail here.  I’ve also taken reading The Art of Game Design out of my sprint, as every time I finish one chapter, it’s replaced by another straight away.  I’m still reading it, but it wasn’t helping anything by having it up there.

As usual, you can see the my current sprint on my Trello board.

 
Leave a comment

Posted by on May 7, 2015 in Making a Game