RSS

Category Archives: Making a Game

Ludum Dare 35 – Post-Mortem


This April I took part in Ludum Dare 35, my first ever game jam.  I was fairly apprehensive going into it, all I heard leading up to the event was that more than half the people who enter these jams don’t end up submitting anything before the deadline.  With that in mind my goal for this first jam was just to submit “something”, even if it wasn’t everything I wanted or even a good game.  Long story short, I did manage to submit something, and ended up somewhat happy with the end result.  If you’d like to see the final result, you can check it out here.

So how did I do?  Not too terribly if the final ratings are anything to go by

LD35-rankings

The ratings are a little hard to understand, although it helps to know that most categories have around 900 entries, except for Humor and Audio which have around 600.  With that in mind you can see that I hit rock bottom for both Audio and Graphics, although I’m fairly happy with how I did in the other categories.  I’m especially please with my Theme ranking, getting into the top 100 in any of them is something to be happy about.

I learnt quite a lot during this game jam, especially mistakes which I’ll be sure not to make again.  I didn’t read the rules properly until a couple of days before the jam started, and didn’t realise that I couldn’t use publicly available, pre-made graphics and audio, which meant I was woefully unprepared for how to create those.  I also messed up uploading my project several times, first by linking to the web version incorrectly, then learning that I’d uploaded the wrong format for the web version, then finally by having the default resolution be too big to display cleanly inside the web game window.  While you could get around this by entering full-screen mode, I’d assigned ESC to bring up the menu in-game, which then threw you back out of full-screen mode.  Every one of those is a mistake I’ll be sure not to make next time.

There’s definitely some things I need to work on before my next jam.  The graphics and audio are a definite must, although I don’t ever expect to be great at them.  I would at least like to get to a point where I can make a game out of something other than primitive shapes, even it still falls firmly into the category of “programmer art”.  Making music is also something I’m never going to be good at, but the rules of the jam allow you to make songs by remixing very basic samples, and it would be nice to learn enough to put together some simple background music.  Basic sound effects I made using Bfxr, but there’s still a lot I don’t know about even that straightforward tool.

The biggest area I found myself struggling with was level design.  I was fine coming up with mechanics and ways to use them, but when it came to spreading them throughout a level I just didn’t know how to lay them out.  You can see this in the game, every new mechanic is introduced fairly quickly and is only used a couple of times.  While this can be nice for a short game it’s not sustainable for anything longer.  I wasn’t expecting to have as much trouble with this area as I did, and I definitely want to spend some more time studying up and practising putting together some more levels.

I would like to fix up some of the bugs and minor issues I had left when I submitted, mostly the physics glitches and a couple of other bits that didn’t feel nice.  I have no plans to take it further at this point, but if anyone’s interested in what I did they can take a look at the source code on my Bitbucket Repo.

 
Leave a comment

Posted by on May 11, 2016 in Making a Game, Uncategorized

 

Tags: ,

Making a Game – Final report (for now)


Well, the year is up and it’s time to take a look at how things went.

How it went

The game still has a long way to go, but I’m quite happy with what I’ve managed to create this past year.  I’ve got a very simple 2 player game where you can create your own teams, choosing names and weapons for each of them, then having turn-based battles across multiple territories until one team’s conquered all of them.  Granted there’s no difference between the territories, and the combat isn’t particularly fun, but I never said I made a good game.

Even though the end result is currently a bit mediocre I’ve finally gotten around to one big thing which I’ve been meaning to do for years, which is make a game, and learnt how to use Unity in the process.  I’ve certainly learnt a lot, and going forward I’m going to keep on trying to make games, although as before it’ll mostly be for fun, rather than a serious attempt to make money from them.

What I would do differently

While working on this game I’ve also learnt a lot of things that I’ve done wrong, or things that weren’t necessarily wrong, but I would do differently.  While I still feel that writing a complete game design document ahead of time is not the way to go for smaller indie games, I should have spent more time putting together some of my design into a single document for reference.  As it was, too much of the design was either stuck in my head, or spread around several of the notes on my Kanban board.  I also tried to make something far too ambitious to complete in 1 year, especially for one person.  Choosing something with a simpler 2D design would have helped make this more achievable.

If I could do it over, I would definitely shrink the scope down.  Starting with a grid-based movement system rather than the free-roaming one would have helped keep things simple, even if it wasn’t quite the same feel that I was going for.  Looking at other games such as XCOM and Jagged Alliance for inspiration, they all use a grid-based layout but disguise it well enough that the players don’t really care.  Replaying XCOM I was especially amazed at how simple so many of the features appeared to the player, how easy it was to flank enemies while boosting your own defensive position.  I’m sure there’s a lot of more complicated work going on in the background, but one big problem with my game is that I didn’t have any plans for making things less complicated for the player, which would have made everything a bit frustrating to play when you have to move one character back and forth repeatedly to try and get them in the right position to take a shot.  If I were to do everything over, I would come up with a much simpler concept for my first game, something that didn’t require fancy 3D models or a lot of complicated design to get something that’s fun to play.

Another aspect of making games which I didn’t even consider at the time is that I was focused on the wrong sort of thing when coming up with an idea for what to make.  Having read quite a few stories over the years it seems that most people focus their initial design around a certain idea, feeling, or action (Gunpoint for instance was developed around sneaking through buildings in Deus Ex).  My game on the other hand was trying to replicate the feeling I got from playing Necromunda as a whole, rather than just a single aspect.  If you have a single fun activity to focus on then you can look at every new feature you want to add to the game and ask yourself “Does this add to the main focus and make it more fun?”, whereas I often fell into the gap of “Does this make it more like the game I used to enjoy playing?”.  Now, I firmly believe that my route was the wrong path to go down, and while there’s nothing wrong with making a game which is inspired and apes parts of other games you enjoyed it causes too many problems to try and make the entire game that way.  This is probably why Game Jams which focus on a single word and idea tend to be so popular.

The plan for the future

I’ve decided that I’m going to put this game on hold for the foreseeable future.  I would like to come back and finish it one day, but there’s a lot of things I need to learn before I can do a good job of it, and a lot of high level design changes that I would need to make.  Instead I’m going to focus on creating some smaller and simpler games that I can get mostly finished within a few months, rather than something that would take years.  I’m going to keep on improving my skills through practice, as well as reading more on design theory to come up with better, more enjoyable ideas.  End result aside, I’ve really enjoyed this past year and I can see no reason to stop doing this.

I’m going to sign up to several game jams this year and do my best to submit something that’s half decent.  There’s enough game jams out there that I could do that every single weekend, but for the sake of free time and sanity, I’m only intending to go for the Ludum Dare jams.  I might change my mind and join another jam here and there, but my aim is to submit something to all 3 Ludum Dare competitions held in 2016.  The first one will be in April, so keep an eye out for that one.

 
Leave a comment

Posted by on January 1, 2016 in Making a Game

 

Making a Game – Report 21 (Tech demo released)


What I did

First off was setting some limits on the team size.  Now you can’t have a team smaller than 1, or larger than 8.  I might change that later, but that’ll happen later when I have the combat fleshed out enough to start fine-tuning the balance.  You can also change the sprite of your team members.  I was going to let you select an image from your computer and use that, but it turned out that Unity doesn’t supply an in-built way to let you browse your computer for files.  So I ended up throwing together a quick gallery of faces to choose from.  I’ll have to come back to this later and figure out how to allow people to use their own images without much work.  That’s a “would be nice” feature though.

Team and team member data is now saved to and loaded from disk when changes are made to it.  It saves each team to a separate file and is fairly easy to cheat by editing the files manually.  Granted there’s not much advantage in doing that right now as you can do the same things by using the in-game team manager.  Another thing I’ll take a look at fixing up much further down the line.

On the world map front I’ve made a few changes.  You can now only attack territories which border your own, which means you have to select one of your own territories to attack from too.  I’ve hard-coded which territories you can attack from for now, which I’m not entirely happy with.  I’m not sure what solution would work better though, other than storing it all in an XML file.  I could do something based on the distance between hexes, but I don’t want to have the art start affecting the gameplay.  I’ll put this on the backburner to look at again later.  Also, I’ve made sure that when a battle’s over the losing team’s territory will be passed to the winner.

Each battle now ends with a battle results screen, which lists the characters in each team and the damage they took, damage inflicted, and have many killed. There’s plenty of room for improvement here but most of this can wait until I’ve fleshed out character progression, which will clarify what sort of data is important to show off.

I managed to fix both the annoying bugs that cropped up a couple of sprints back.  The first one is the health bars disappearing,  I spent a couple of afternoons trying to figure out what was wrong with this, reaching some sort of success by changing the renderer sorting layer’s during runtime (didn’t work if I set it in the editor).  Eventually I decided to upgrade Unity and the issue went away.  Turns out it was a Unity bug that must’ve crept in when I upgraded in the past…  The other bug was a bit more devious.  It was happening seemingly at random and thought there there was no-one in the first team even though the check didn’t happen until after they’d been generated.  Looking at the logs the people had definitely been spawned but it still thought they were dead.  A little more digging and it looks like my IsAlive check was to blame, as it always returned false until the CurrentHealth was set partway through the internal setup work for each character.  A simple enough race condition issue to fix, but a bit of a devious one to track down.

With everything completed this sprint, I decided to go ahead and release a new tech demo, but at this point it’s starting to turn into a very rough Alpha.  I’ll try to release them a bit more often from this point.  You can find the current version here.

What I didn’t do

Somehow I managed to get everything done this sprint, so nothing for this section.

What I will do next time

Right now the game is mostly complete, although many areas are still in a slipshod “it’ll do for now” way.  But you can start a new game, and attack enemy territories one by one until you’ve taken over the map, so long as you don’t mind seeing the same demo combat area over and over again.  There’s also one noticeably outstanding issue, which is the game still needs you to manually control each team.  Originally I planned this to be a multiplayer game but it really needs decent AI for the single player mode.  Unfortunately I don’t know much about developing AI right now, so this sprint is going to be a bit vague and involve a lot of research and prototyping

First thing to do is find some articles on basic AI theory and practice. I’ll try not to spend too much time on this, but if I don’t understand the basics beforehand then I’ll be making my job that much harder.

Afterwards I’ll start putting together some prototypes. The first one will be getting the AI to move someone to the closest of 3 specific points. Next I’ll do the same, but have them prioritise the slightly further away one which provides cover. Then I’ll do the same, but make them check to make sure the cover will be effective against an existing target. I’m realising that I could make job significantly easier if I replaced my click to move system with a simple grid system. It wouldn’t be what I originally envisioned but it would make this a damn sight easier to get off the ground.

I’ll also try to create another set of prototypes for combat. It won’t be as in depth, but I’ll first make one to target people based on the highest chance to hit. The next can do the same, but will take into account how much damage a target has suffered. Finally, if I have time, I’d like to make another where it looks at which weapon each enemy has and decide who’s the biggest threat. More often than not it’ll be the one closing in with the shotgun.

That should do for this sprint. I’m not certain I’ll get it all done, but it’ll give me plenty of practice either way.  Ultimately I’ll combine these ideas into a single opponent who can assess the enemy ahead of time and move into appropriate cover to take out the most dangerous target. That should be fun.

As always you can see the status of my current sprint on my Trello board.

You can also find the current tech demo here.

 
Leave a comment

Posted by on November 17, 2015 in Making a Game, Release

 

Making a Game – Report 20


What I did

Had some things occur this sprint which took a lot of time away, but somehow it still ended up being a somewhat productive.  I’ve thrown together a quick world map with a number of territories (shown as hexes) which display some basic info and can be occupied by any team. At first I was all for using hexes, but now that I’ve had some time to play around with it I’m not sure it’s right feel for what I’m after. I think something with fewer, more spaced out territories with better graphics to represent them would be nice, but as I’ve said so many times before it’ll do for now.

HexMap

I still really like hexes, but I just don’t think they’ll work.

I’ve changed the character placement in the combat mode to randomly place characters within that teams spawn area. This lets me put any number of characters in each time, although I will have to add some options for choosing where to play them later. Could do with a better demo level before that though.

I’ve completed an early Team Management screen. It’s very rough, but does the job until I have the time to do some proper UI research and design. From here you can change the name and equipped weapon of any team member for any team, and add or remove team members as you will. I haven’t placed a hard limit on the how many/few team members you can actually have yet, but that’s a fairly trivial thing to set.

TeamManagement

When I say rough I really do mean rough.

What I didn’t do

Only have a few missing features from the team management screen now. I want to be able to set the portrait used to represent your character. Later I’ll build a library of images to choose from, but it feels important to allow players to import their own faces to use. I’m not sure if that’ll stay long term, but it’ll certainly work for now.

I’ll also want to save all team data to disk, and loads it again when you start a new game. It won’t be very visible to the player, but it’s important to do right and will need some research doing beforehand.

I want to update the world map so that you can only attack territories adjacent to your own. There’s a few ways I can do this, some quicker than others, but what I really need is do is make something adaptable which I can just load in for future maps. It’ll take a bit of planning, but shouldn’t be too difficult to figure out.

Finally I still need to let teams take over enemy territories when you defeat them in combat (or lose of your own if they defeat you). It’s kind of key to the whole persistent strategy side of things.

What I will do next time

I intend to implement all the features mentioned above, none of them are really optional at this point. I’ll also fix the issue I discovered while writing this post where there’s no lower/upper limit on team sizes. I’ll look at this properly later when I start to balance things out, but for now I’ll set them to 1 and 8.

On the bug side of things there’s 2 annoying ones which gave popped up recently which I need to fix. First of all the game will sometimes instantly leave combat mode after it begins. I’m not sure what’s causing this to happen, but as its intermittent I think there’s a timing issue somewhere which I need to look at.

For the second one, I’m not quite sure when it happened, but most of the health bars aren’t showing in the combat mode. It just flicks between showing one, then another as you move and rotate the camera. I’ve got no idea what’s causing this one, so I’m going to need to crawl through my past commits in git to see when it stopped working.

HealthBarBug

You can only ever see the one belonging to the top-most visible character.

When that’s all finished up I’d like to create some sort of post battle report screen which appears when the combat mode ends. No idea what I’d like on there right now, but the health levels, damage done, and characters killed for all people involved seems a good start. I’ll also need to track that data during the combat.

If I can get all of this done then I think I’ll be ready for another prototype release for anyone who’s interested. It will still be incredibly rough, buy at least I’ll finally have something resembling an actual game.

As always you can see the status of my current sprint on my Trello board.

 
Leave a comment

Posted by on November 4, 2015 in Making a Game

 

Making a Game – Report 19


What I did

Well this ended up being a productive couple of weeks.  Not only did I manage to do everything I’d set out for this sprint, I managed to get a couple of bonus tasks completed too.

I tied up the health bars which were still sort of broken from my multiplayer attempt.  Health bars are now rotating to point towards the correct camera when it moves and rotates and the health levels shown in the team roster is also updated correctly.  While fixing that I also noticed that the health bar shown in the character details pop up was also trying to rotate, but as it’s part of the UI it just looked kind of weird from certain angles.  Apparently I’d added a script to it at some point telling it to keep pointing at the camera.  Not sure when I’d made that change, but after removing it everything looks fine again.

After that I could finally start on the strategic view, or world map.  For starters when you begin a new game you’re taken to the world map initially.  From there you can select an enemy territory and choose to attack it.  There’s placeholders to show information about these territories and the teams that hold them but for now shows no real info (that’s something I’ll be working on in my next sprint).

Each territory is different depending on which team holds it, and attacking different ones takes you into battle with a different group of enemies.  When the battle ends, whether you win or lose, you’re taken back to the world map to continue playing.

What I didn’t do

Nothing for a nice change, a very productive sprint.

What I will do next time

I got a lot more done this past sprint than I expected, so this month I plan to finish off the rest of the world map changes, and expand the combat mode some more.

First up is expanding the world map to include a larger number of territories.  From there each team will own several territories and you can choose which one you want to attack, winning that territory if you win the resulting combat or losing one of your own if you lose.  With that in mind, I’ll also add some information to the territories which will pop up when it’s selected.  It makes sense that you can only attack bordering territories too, slowly working your way to the edge map where the enemy team’s more heavily protected home base will be (that will come later).

I will update the combat mode to randomly place team members within their starting area, which will let me increase team sizes to more than 3 members.  I also want to add in some team customisation options which you can accessed from the world map.  For now you will view existing teams, change their equipped weapon, create new team members (specifying name and loading in an image for the face), and dismiss existing ones.  To aid things I’ll also make this persistent so that the team data saves and loads in the background.

That’s all for this coming sprint.  This may look like a short list (and it’s easily one of my shorter reports), but as you’ll see from my Trello board there’s actually quite  a few tasks involved in this.

 
Leave a comment

Posted by on October 18, 2015 in Making a Game

 

Making a Game – Report 18


This report will be a little different to the past ones as I’ve done in the past.  Being that I’m 3/4s of the way through the year of trying to making this game I’ve been doing.  For the most part, I’ve been focused on trying to make the core game and combat work to a reasonable degree.  While this is important, I feel that I’ve lost focus of my main task of “making a game” and have instead been chipping away at all the features that were needed for the combat work.  I had an inkling at the beginning that I wouldn’t finish this game within a year, and it’s plain to me now that this definitely won’t happen.  But what I wanted to happen within that year was have the core framework of the game set up.  Instead I just have a fairly basic turn based combat mode.  This wouldn’t be so bad, but I’ve spent the last 2 months trying to get the basics of online multiplayer to work, and while it works ok so far, it’s a long way from being done.

Considering the relatively small number of people that might actually play this game when it’s done, I’m not sure it’s worth spending any additional time trying to make the multiplayer work.  None of the time I’ve spent on this has been wasted, as I’ve learnt a lot about how Unity’s UNET system works, and also refactored a lot of my code that needed some serious tidying up.  The way my game’s set up now it’s fairly easy to get it working in either single player or multiplayer mode.  Instead of them, I’m going to spend the last quarter of the year making the basic framework needed for the rest of that game.  I still expect the combat to be the more complicated part of the game, but the rest is still essential to make it a more complete package.  Now, on with my usual report.

What I did

Despite my moving away from multiplayer, I finished off 2 features that were causing me some annoyance, but didn’t take too long to fix.  When it was the other player’s turn you could still see the movement circle and create waypoints around their current character.  Neither of these served any purpose and didn’t matter a great deal as you couldn’t actual move them, but it looked untidy and could cause some confusion.  When play moves away from you, both these features are disabled.

At some point when I was refactoring my movement code to work with multiplayer, I’d messed up how it calculates the remaining movement after you confirm where a character should go.  Instead of using the correct value, it was reset back to the original value, letting them move around forever.  I had to change where the calculations take place, but this is no longer a problem.

The biggest task this sprint was refactoring the game to work in offline mode again.  Thankfully it wasn’t as big a task as making it work with online multiplayer originally, and the code’s considerably neater as a result.  All of the original online code is there and the game should still work in online mode when I come back to it later, although I haven’t tested it and probably won’t for some time.  There’s still a few issues left which I’d like to finish up, both of which were introduced from my original multiplayer refactor.

What I didn’t do

Every other networking task that wasn’t listed above.  As I mentioned at the beginning of the post, I’ve stepped away from working on the online multiplayer for now and won’t be doing any more tasks until I need to.

What I will do next time

Over the next couple of sprints I’d like to get the strategic overview of the game world working.  That means being able to look at your territories, as well as those of your opponents, viewing your team status and being able to select a territory to attack.  Some of these features might end up in later sprints, but here’s what I want to accomplish for this one.

When you start a new game you should be taken to the strategic overview rather than jumping into combat.  From here you will see the enemy territories and can select one to attack.  This means you will encounter different enemies with different equipment when when entering combat.

I need a UI for the strategic mode too.  Most of it will be placeholder buttons and fields for features to come, but I’m going to set up what I can now so that I can at least make it obvious what will be coming in the near future.

When you finish a battle you should come back to the strategic overview screen.  Later on I’ll put in a battle report view, and have the game overview update to show territory gained/lost, but for now this will do.

Finally I’ve got 2 areas that still need fixing after my move to multiplayer.  First of all the health bars in the team roster have stopped updating.  I’m not sure what I’ve broken there, but it shouldn’t take a great deal to fix.  Slightly more of an issue is that the character names and health bars aren’t pointing towards the camera anymore.  That’s going to take a bit more thinking about to get working correctly, but also shouldn’t be too difficult.

As always, you can see my current Trello board here.

 
Leave a comment

Posted by on October 4, 2015 in Making a Game

 

Making a Game – Report 17


What I did

First thing this sprint was the “quick fix” to get the character’s rotations synced correctly.  It turns out that was a bit more tricky than I thought, with me using the wrong method to point towards a point 3 times.  For anyone interested, the correct method in the end was “Quaternion.LookRotation(pos2 – pos1)”.  I had to tweak it a bit too if your final move was going down a ladder, as it left a player facedown on the ground.  Unless a bug presents itself there’s nothing left to do with this one now.

After a fair amount of roughness, play now switches between players correctly.  I had a lot of trouble with this one, with it refusing to sync player names correctly, but it’s finally working. In the end, the trick was to realise that my game logic only cared if you were the current player, and beyond that it simply didn’t matter.  I had some issues where it was changing players, but not changing teams, and another when it was changing teams, but not players, but both of these have been resolved as well.

Finally I made it so that when play switches away from you, all the turn-based UI buttons are hidden from view.  You can still move the camera around, look at the controls, exit the game, etc (when the buttons work that is), but everything you shouldn’t be able to do, you are now prevented from doing.

What I didn’t do

I wasn’t able to start on synchronising health levels and character deaths. In fact, when doing some testing it seems these values aren’t even being updated on the div local machine. Quite a bit of work to do here.

It’s not enough to show a character lose health, you need to see the shot taking place. I’m going to create a small package containing the necessary information (character shooting, character shot, damage, hit success, etc) and that as a one big update when the Fire button is clicked.

When that’s finished I’ll be at a point where I can start working on the main game mechanics again. The first thing is to get the game over screens to show correctly, whether it’s a success or fail. When I’ve got something more interesting to display I can turn this screen into a battle report, showing the immediate and long term effects of the battle (injuries suffered , loot found, experience gained, etc).

Finally I’ve still got 3 videos left to watch in the UNET tutorial series I’ve been following, totalling 40 minutes. Shouldn’t take too long, and the next one deals with writing a customised HUD for the network manager, which I’ll need to do before too long as the default one isn’t very pretty.

What I will do next time

As mentioned above, I’ll be synchronising characters health levels and whether they’re alive. I’ll also rewrite the firing methods to send a package over so both players can watch the shot take place at the same time. Each player will be taken to the correct game over screen after finishing the game, and I’ll watch the last few UNET tutorial videos.

Currently the movement circle is shown even when you’re not the current player. It serves no purpose so it should be hidden.

Additionally I’ve noticed that the movement circle is reverting to its original size after you’ve confirmed a move. I’m not sure what’s broken here, it’s either the code for resizing the circle, or the movement mechanics. Either way, it needs fixing.

When you’re the inactive player you’re not alerted when your turn begins. For now I’d like to move the view to the character you’re controlling when this happens. I need to do something more than this, but I’ll think about that a bit longer before I try something with it.

Even though they can’t move anyone, the inactive player can still place movement waypoints. Should just be a case of adding an extra check when you try clicking anywhere to make sure you’re the active player.

As always, you can see my current Trello board here.

 
Leave a comment

Posted by on September 24, 2015 in Making a Game