Project deadline passed - new deadline

OK, December is here, end of November, so game is released now?  No, release did not happen.  It's not all doom and gloom, I am close, but I'm constantly finding problems, and while they are now mostly behind me, I didn't even get to finish some mandatory features.  So I am going to extend my deadline by a week to fix up last minute bugs, and add the last few features.

This last couple of weeks has been yet another solid reminder of what difficulty AI, animation and physics is.  I noticed people saying this about sports games when I started the project, but really now understand it.  As they said back then, if I just made game X, Y or Z, there would be so much less AI, so much less crazy animation combinations, etc, etc.  Yes, I once again had a really tough time of it getting through various crazy bugs and conditions.  Since I had many repeated issues, I'll mention the high repeat ones:

• Attaching AI script files to avatars.  My AI is built script by script, so rather than a mega AI script, I have one for contesting the ball, one for getting to a contest, one for leading, etc, etc.  One of the biggest problems I keep running into is I just haven't added a script to the player avatar.  It starts off with watching the AI do something really silly, and thinking I have to fix that.  Then I try to work through the script logic, seems like it should be doing the right thing.  Perhaps the entry logic is incorrect and the logic never gets run?  No that looks OK.  Finally, when I can't give a single reason the logic isn't firing, I realise the script isn't attached, therefore not even running!  It's the easiest thing in the world to fix, yet has alluded me probably a dozen times and caused a lot of wasted dev hours.
• Floating targets.  Leaving physics to Unity does some weird things that aren't game friendly, so early on I decided to tackle it myself, but doing it yourself is a major pain too.  One of the issues I constantly stumble on is players floating away or falling through the earth.  There is nothing that takes you out of the game quicker than seeing someone runs towards a spot 2m above the ground, or sinking through the earth, or someone rotating on a 45 degree angle to the earth (eg they should fall over doing this).  I have little of this happening right now, though I've had to temporarily disable bumping, which I really want back in, so more work to happen, eg what do I do when someone is bumped mid jump, they need to still land again (currently they idle in mid air)
• Timing a target.  I knew this would be painful.  The ball is flying in using gravity etc, and we need to jump to meet it.  At first I programmed it to just mark if the radius is close and we are closest, but lately I got a real trigger working on the players hands, where they only marked it if their hand got to it first.  This works pretty well now, but was a huge effort and is still not 100% yet.  When it works, it is very impressive however.

So, with the deadline done, was I just a few bugs short?  Not really.  Every day has feel like 1 step forward 2 steps back recently, and it's worn me down too.  As an example, in October, I could mark a ball, go back to kick at goal, and go to the next play after kicking a goal, with the score ending up on the scoreboard.  It was rough and buggy, but all that worked.  In the last few weeks, I have struggled getting a mark.  I have broken and just recently fixed the ability to get back to kick a goal.  I have broken and just fixed the ability to have another play after the first.  I have broken, and is still broken, the ability to even kick a goal, though to be fair, this is a new game mechanic I've been working on.  And then there were bugs!  Finally by the deadline, I had patched most pieces together, and to be honest, most stuff is coded pretty well, so I should be in a good position to use this code as a base, not retrofit 90% of code after beta release.  I have a few fluffy things to finish off with, like celebrations, crowd, umpires, but even some of this I've been working on.

I could probably get the beta "finished" by the weekend, but I'm giving myself another half a week to add a few features I really wanted from day one.  The game itself won't have any content outside of playing, so I want the beta to feel a little more than I just got something working, I want it to feel like my game.  A couple of the features I've really looked forward to adding is AI around celebrations or crowd, where the players react more real depending on the situation.  It's annoying to play a sport game and see someone do a massive celebration 10 goals behind in the last quarter, or the commentator get excited, eg. in that exact situation commentator AI should be choosing between things like "a small ray of sunlight on an otherwise gloomy afternoon" or "that's not going to affect the result today."  But instead they say things like "he's just really firing today," completely out of context for the game.  Or even better (and with unlimited time to code a commentator AI), it would take into account things like the season.  "That won't change the result... but percentages are very important late in the season and being in the mix for finals" or "that won't change the result, but they'll want to get a bit closer to make sure this result doesn't ruin the start of their season."

My point is, I don't want to be putting out a product that just barely gets the job done, I need to build some strengths where I can, and hopefully add something positive to the playing experience.

So now that I've breached my November deadline, I'll add roughly a week on until I reach the objective of be able to play a basic game with minimal bugs, and perhaps a few nice extras in the game play that aren't yet.  I'm still going to push hard to have that done by Wednesday 7th December.

2 weeks remain - animation animation animation

With less than 2 weeks left, I should be looking at putting some polishing touches on this game, but am instead running circles around the ball, both metophorically, and in some cases, that's what the actual player is doing.

I'm making progress, and at some point, I would have had to do what I'm doing if I wanted a complete game, I guess I figured I wouldn't need to go through this hassle in the 12 week project part.  On paper, the game seems to have changed in very small ways the last 5 weeks, possibly going backwards in some ways.  But I had reached the abosolute limit of my hacky animation controller, and it was taking me hours to make a small change, because it would break something else in the process.

OK, so the things I've been up against recently:

• Animation.  At one point this was a simple little thing, that just needed slight tweaking to finalise, at least in my mind.  A better way to actually look at it, it is a monster.  Unity and Mixamo kicked my ass for a good few days.  There is generic model/animation and humanoid model/animation in Unity.  By default the Mixamo stuff comes out generic, but that doesn't work well with Unity transforms.  Google helped me realise I needed to change it to Humanoid, but that just plain didn't animate.  The answer alluded me brilliantly, you need to find the base avatar, set that Humanoid, then change every animation.  Next, the animations now work, but look rediculous, like when running, the animation itself looks great, but when rigged to a humanoid avatar, limbs just go in weird directions, making it look like they are in the process of turning, when they are going dead straight.  I have no idea how I resolved this, but I had 50 attempts before something just worked.  And apart from that, I found the more animations I got, the more complex and buggy the Animator became.  It's frustrating debugging the animator, seeing the flag to start jumping is set, and the animator is completely ignoring it, when the only thing I've set is to jump when that flag is true.  This just went through a complete overhaul.  I've now ripped the entire original controller out, and replaced the animations with sub states, where the main state is either idle, moving, jumping, bumping, spoiling, but under each of those, there are substates, so under moving there is running, walking, running backwards, etc.  This works well, and whats more, adding another animation is childs play now.  In terms of content, I've worked through a few types of marking, I've added bumping and walking.  Animation is not complete, but it's definitely in the best place it's been for a while.
• I also finally managed to get some colour on my characters.  I heard an interesting comment about game design, and saying it's easier to get excited about a project if it's looking good.  That is it's all well and good to say you should be able to make the controls and physics work while the characters are just cubes, but it's easier to get excited about it if they look like Aussie Rules players.  I had no idea how I was going to do this, but Adobe stepped in for me with a free preview tool called Fuse.  Fuse allows you to define a look for a 3D character, from skin, to hair, to body shape, to clothes.  I used this to get a sort of Aussie Rules type clothing, but there is no colour editing in that tool.  The final edit was a little hacky, each clothing is an object, but has several files to render it, some for the mesh, some for the material qualities.  I opened the diffuse map in paint.net, reworked the key areas to be like teams tops, shorts and socks, and now have proper looking players.  Not perfect, but not bad at all.

So, I'm up against it for time now.  A lot of things seem to be on the too hard list now, and just getting a non-buggy gameplay could possibly soak up most of the remaining time.  There is no point backing down though, I am going to push hard this next week and a half, and just see how much I can squeeze into it.  With a little luck, I can get a decent product up and running, and have my solid base to work from.

So things to look at this week:

• Finalise the bumping, spoiling and marking.  This will not be perfect, but I have to call it quits somewhere, and it at least has to have bumping and some level of marking/dropping a ball.  Spoiling doesn't have a good animation, but again, I don't have time to learn 3D animation creation, so I have to work with what I have.
• Finalise the decision making of the defenders
• Organise the player positions at the start of every play
• Finalise camera positions

Nice to haves if I can squeeze out a couple more hours:

• Umpires and crowd
• Noises
• Music
• Settings (eg. sound on/off, less graphics for older phones)

The list of things I'm not going to attempt by next week is too big to bother listing, but it's essentially down to getting a solid base by next week, and then I'll try to look back and re-assess everything that I've done.  I have to then look at what other projects I want to play around with next (the list is growing), and whether there is enough in this product to bother continuing with, or whether to just put this down as a learning project.

Wednesday update #7 AI Physics IOS

It's been 2 weeks since a Wednesday update, AI, AI, AI.  Well, to be fair, AI and physics.

As November fires up it's engines, the end line looks exceptionally close, which is good and bad.  On one hand, it will be good to see an end to this project, on the other there is nowhere near enough time left!

Here is how the last two weeks went:

• AI.  Getting the first two players to try to mark properly has been kind of tough, and I'm not even sure I'm going to fully get it by release either.  I've spent about 2 weeks working through some physics/AI/animation issues here, and it's a slow process.  When there are problems that don't make sense, you goto to debug the problem.  Here, I've had a big problem, as the debugging often freezes up after a little while, restarting Unity and VS are sometimes needed.  I'd say in every dev session, this has happened at least 5 times, and it's realistically 10 minutes gone once you finally give up on it, restart everything, get the code back to the same break point.  It's also just generally slow to get your head around these issues.  You can have a few triggers that might end up affecting a case, and if a certain code doesn't get hit, it could be because of something wrong in 3 different files, so knowing which part is not correct can cause problems.  A few big AI issues around contests have been looked at.  Right now, the player can decide if they have time to go for a big mark, or just run to a place where the ball will be lower to the ground.  If they get there in time they can pause and wait, if they don't get there in time they don't try to jump.  It looks pretty good so far, but there are a few really obvious missing entries.
• Animation.  I've been meaning to have a little crack at animation editing, and yesterday did some.  I had a good AFL like marking animation, but it was too slow, so the player goes from running full speed, to stop, to slowly build up to the jump.  To fix this, I duplicated the mark animation, and set the starting point of the animation to be as he's about to lead into the jump.  Now he runs toward the contest, and just launches into the jump, it looks and works well.  The animation controller allows him to go from idle or running to jumping, and has kicking etc too.  So far so good for animation, there is a tonne more to do.
• Physics.  I say AI a lot, but really a lot of it is physics.  Most bugs are physics bugs not AI bugs right now, like right now when the player completes a mark, they make a crazy looking semi-arc back to where they launched for the mark.  This will be easy enough to fix, but there are random crazy looking things everywhere.  A big thing I've looked at is timing the player to meet the ball.  This is definitely a science, and the problem is a ball approaching really quickly, and a player jumping at the same time, the timing is not quite there for me to perfect this unfortunately, but I have it pretty close now.  I've managed to find the players hand object, so part of a mark is getting that hand close enough to the ball object, and claiming it, which I do by making the hands it's parent object.  I got the code to a really good place yesterday.
• IOS.  I got a mac, and ordered a dev license, so have nothing but a little pain in front of me before I can develop on ipad.
• Other.  I did get a couple of other things in.  Grass.  This has been a pain, and at this point, I think I've ditched it, and gone with my weird looking terrain.  One of the big problems is getting the grass short enough.  Unitys built in grass looked fine at 1m high (in my game), but when 10cm high got an extremely blotchy field.  I found a couple of good examples of better things to try, a tree stripped down to look like grass and then use the tree option on terrain.  This worked fine, but again was near impossible to get looking right for low grass.  I had a rest on this, and a breakthrough the next day to use an image with just a small height grass, ie lots of space above it.  This worked for both methods, but... using the grass terrain, it looked fine from below but just looked awful from above, and chewed through my frame rate once you tried to display the whole field.  The tree method wasn't much better.  In the meantime I'd been learning a bit about shading the grass to look more realistic tone, and essentially just kept the same field I had, but toned it better, as well as toning some other elements better.  This gave me a decent result, and I can still get my high frame rate, so this is pretty much me for now.  If the project goes well enough, I may need to invest in a grass asset from the asset store.  Other things were minor.  Got some advertising boards done, needs to be finished off though.

Overall, the leading for the ball, running, jumping, marking all looks good in a very simple example.  Of course AFL is not simple, and thus the big problem I'll have going forward.  I was watching an 80's game on TV, and just noticed some things that you really can't get an AI to do, as an example, the ball was kicked to a contest, and two guys wrestled near the target point, as my game will hopefully do.  Another couple waited patiently in case it wasn't marked.  Then a player from the other direction ran back with the flight and took an amazing mark over the two guys wrestling.  This is where AI gets really interesting.  Now lets say I see that, and say, yes I guess that is a possible move someone could make.  It can't happen every time a player is there, it would spoil the game.  Yet it was mark of the day, and what fans really love watching about the sport, the one off big moves.  I need to think about this somewhat.  Perhaps I could chamber 5 or 6 "exciting" moves, and when a chance to use them comes up, I randomly pick it like 1 of 5 times the situation is possible the player goes for it, and maybe 2 in 3 they stuff it up anyway.  Food for thought.

But way back here in current reality, I have a release to work towards, and a lot of much bigger problems.  This week I'll be aiming to:

• Add non-jumping marks, eg player just puts there hands up and marks without jumping
• Add spoils.  The worse off player should try to spoil the marking player
• Add more physics logic to a mark.  Right now it's just proximaty to right hand, but it should be the spot in between both hands, and given I don't have crazy good animations, probably need to accept marks if it's slightly under the hands, but exclude marks if they are too high or low
• Bug fixes in those general areas
• If I get sick of AI/physics, probably time to start working on the player uniforms too, finish off the advertising banners, finish off the stands properly.  

Weeks to go!

Wednesday update #6 late - Hump Week

It's been a tough week, hard to get into it this week for various reasons.  I finally got the momentum going again last night, but technically that was Thursday, so really a very poor return this week:

• Got a training area.  I plan to make the AI work itself out here.  So rather than mess with the main scene I created a trainign scene, and plan to build a whole lot of scenarios into this scene.  It will be sort of like an AI unit test, although I'll have to visualise the results, but it's just too difficult to do other ways.  The plan is to make changes to AI, then run this in as many scenarios as I can, and watch the AI do it's thing.
• Cleaned up some code.  Creating a new scene showed me there too many weird dependencies in my classes.  I couldn't add AI to a player, without having to add this to the scene, with then needed the manager, etc, etc.  I have cleaned it up a little, though for the most part I just added the components, I need to move on.  Also, as I work more in the AI classes, I plan to clean up the code somewhat.  The structure isn't too bad yet, but evertime I come to an AI class I haven't seen for 10+ days, it takes me 10 minutes to work through the decisions.  I think In future projects, I may end up adding a tonne more AI classes, specific to different ideas, with descriptive class names.

But to be honest, I didn't get any real traction on any real work.  I'm hitting a bit of a wall when it comes to drive on this project.  I guess I came in thinking, that if someone who likes Aussie Rules games hears about this, I will get a lot of support, that might grow and grow by launch.  But there are many factors playing against me.  Firstly, I have never actually written a game.  Love sports games and complain about them as I do, this doesn't make me any more of an expert then 50m other sports gamers.  This really reduces peoples care factor about what I'm doing, because they (maybe rightfully) don't think I can do anything good at this stage.  I think another factor is the limited scope I'm aiming at.  It's a catch 22, because I don't think I could have finished a project if I was aiming at a fully blown console version.  But then nobody really wants a cut down version.  Then I guess it's just a bit disallusioning looking more into the future of what is indie dev for me.  If I can't even gather any interest in a specific sport with a huge lack of games in that area, then what chance do I have competing in bigger markets as a sole developer?

Well, last night I got some decent stuff going, so I'm back on focus again now.  I figure I'll do this until end of November, try to deploy as a beta to android, perhaps even IOS, and re-assess.  But there is no point putting in a half assed final 6 weeks, and looking back and saying I couldn't get any support.  At this stage my final hope for getting some support is to really work hard at making a decent fun game, and hope those that do step up to have a go like it and spread the word.  So this week I should be:

• Working on unit testing.  That is boring code talk, but it essentially means my AI will have a set of conditions it needs to pass.  I did half of this Thursday, when I set out the conditions for when and how a player should get to a contest, but technically that's next week.
• Work on getting to a contest AI.  There is a lot of AI to think about still, my first target is to get players to intuitively get to a contest, thinking about other players, the ball etc.
• If I still have time, it's then collisions.  The biggest difficulty is going to be making a non-repetetive way for players to collide, be it the bump before the contest, a player flying in from the side, 3-4 players all going for the jump at once.  I have some ideas, though the code for this one will be interesting to say the least.  My ideal is that my unit test scenarios will produce not only somewhat realistic contests, but also not the exact same contest each time.  Like occasionally one of the 4 players should jump too early, because they are nervous about the upcoming contact from up to 3 players.  Yet other times they should nail the jump, and perhaps even take the mark.  But it is important to keep it simple first, so something there will likely give.

Wednesday update - half way point and screenshots

I have achieved what I set out to this week in terms of rounding off some of the gameplay options:

• Scoreboard - this is now showing the score as well as menu options.  I also added a similar styled scoreboard in the game itself while playing.  I would have just gone a TV styled score tracker, but again through the grass roots idea would benefit from an old fashioned look to the in game score, I think it looks good.
• Timer - again my default thought was a timer shown in a computer font, but again the old grass roots timer came to mind.  It's something any WAFL/VFL fan would instantly recognise, so it is now a must for my game.  Getting the hand to cooperate took more time than I'd hoped, and in fact the main one is still not working 100%, but it's mainly useful for in play, so you can now get a feel for roughly how many shots you might have left.  This will not only leave a little nice feeling see that style of clock, but also hopefully give a feeling of nerves.  Those clocks don't tell you exactly how long the game has left, so it's a bit of guesswork needed, good for nerves if it's a close game.
• Gameplay options - I was a little worried about this, but it came together nicely.  I didn't want to complicate things too much, so kept to some pretty simple rules.  Firstly, the clock ticks a minute (of actual play time) and randomises whether opponent or you can get a play in.  For opponent right now, you pretty much just see the result (may choose to allow a defense against CPU later), for out turn, we get to play.  When we play, you'll notice in the top, the clock has moved on, and the score may or may not be different if opponent has scored.  The only smarts I'm building into the strategy, is if you get 2 goals in a row, the other team drops a player in defense.  This makes it a little easier to get it into your forward line, but the extra defender makes it harder to actually score.  Apart from tweaking the randomness a little, this is now pretty much complete.
• Graphics - had a little less energy last night, so I just played around with a few graphics things.  I added a hot dog stand, and right where it used to be at Lathlain Park.  I added the 2nd stand.  I found a park bench that I will use a lot of, but putting it in the stand (as it is in real) doesn't look right yet.  Plus it adds 100+ detailed 3D objects to the scene, so not sure this will stay.  I might create my own very low poly bench for stands, and just never do real close ups.

As for general thoughts, it's been a yo-yo week.  A little on a high thinking that I'm half way done now, and I have a decent amount of game already behind me.  But I have a nagging problem I can't shake off.  If I release it as planned, it may well be fun to play, but for the random player, just playing any sports game without a league or something for it to mean something, will leave it too light.  If I saw such a game without knowing any background, even if I loved the gameplay, couldn't leave it a 5 star review, as it would feel incomplete to me.  Then if anybody doesn't like the gameplay, or finds a few bugs, might reduce it more, maybe even 1 stars.  If you don't get any 5 stars, but you do get some 1 stars...  it won't end up a good rating.  It doesn't mean that much in reality, as I know why it's not great rating, but it's still a public showing of my skills, and 2.4/5 isn't something to brag about.  Essentially, while the 12 week project is a great idea to get something up and running, and get something done, it's a little weak when it comes to app store releases, especially something like this, where not having a league option is an obvious hole.  I now figure I might get away with a public beta.  In this way, I can still release it in 12 weeks, but nobody will assume it's a fully finished product, and will hopefully mark accordingly.  I will still aim to do this on android (have checked google play, it's possible), and hope to be getting a Mac very soon, so then will start looking how to do this on ios too.

Next week it's back to player AI again.  I'm going to start with 1 on 1, but with the idea that it could be 2 on 2, 3 on 3, and any of those plus a floating defender.  But I imagine I'll be working on the 1 on 1's for some time still, as it's easier to identify and fix bugs.  If I get a bit of lighter time, I still have a lot of the ground features that need to be finished.

Screenshots:

Main menu.  Was a 2nd option, but it's not planned now, so just removed it.  Side white bar is an ad bar:

Start of game.  Our guy has the ball up the ground, you drag the full forward to give him a path

After taking the mark, camera drops back behind player to take a shot:

 1/4 time, and we go back to the scoreboard:

Wednesday Update #4

Very little real time since the last late update, but some progress has been made still.  To be honest, I've been fluffing around the big issues of AI and collision, but I feel on any day I can be in a position where I want to demo my game on my phone (happened quite a lot on holidays), and while I was proud with what I had to show, a few days work to fluff up the graphical side of things would have made it far more impressive.

Work done in the last couple of days:

• I have a logo.  I created a facebook page now, and it asked for a logo, so I created one.  It's not too bad, and I've already put it on top of my scoreboard, which I think looks nice
• I had a side thought about how to manage instructions in this game, and came up with a coaches whiteboard, so whipped one up.  I found a handwriting font, so it looks a little more like the coach is writing on a whiteboard.  It doesn't look spectacular, but is nice, and lerps in and out from the side.  I aim to use this for "commentary", which will effectively be coaches tips at 1/4, 1/2 and 3/4 time... assuming I have time to do this.  At very least I may have an array of encouraging comments for these breaks.  There is then a "got it" magnetic sticker that the user can press so they don't need that instruction any more.  The whole thing works quite well I thought.
• I had various thoughts about this game being too easy, which essentially it would be in real life with just a 1v1.  The forward can lead anywhere they like, and without AI cheating, it would be very difficult to stop them getting a mark.  But if I allow more than one player to control my discs, which I didn't love anyway, won't work.  I also had a very simple approach to a moving version of this game, for mobile.  Drag a player to move them, tap to pass.  This works actually somewhat better than console sometimes, because I can instruct 3 players to move in directions, then tap to pass it to the one that works best, this would be difficult to master with xbox.  Well, I got it working.  Now, when you drag your finger from a player, it plots out points every 4m or so (felt about right) and shows it while you are still planning.  Then you press play, the path disappears, but is remembered by the player and they execute.  Once they get to the last point, the AI kicks in again, and if you don't want that you should be able to drag them again, though it doesn't currently allow this, and I may leave it out of V1 for simplicity reasons.  The way it works is it starts a tracking if MouseDown (also finger down) hits a player or their disc, and then tracks until mouse up.  It only stores points if they are 4m away from the last point, which works well, even if they completely change direction.  It stores those in a List of points for the player, then the various AI elements check to see whether that List is empty.  If it's not, the AI follows point to point, deleting points when they get close enough.  When all points are gone, other AI elements will again wake up and decide where to run to next if needed.  If the ball is kicked, the path is also destroyed, and they will either go for the contest, or not depending on where they are, who they are.  This works really well so far, and the player changes direction in quite a realistic way when following crazy paths, as I made them slow down more the larger the change of direction is.

That is all so far, and the list of changes needed don't seem to get any smaller.  Here is a somewhat brief overview:

• Game management.  Have a main menu, can reset play, it tracks scoring.  But, it doesn't show the score.  I have a scoreboard, but am not thrilled about panning in and out all the time to show this, so would like an on screen score.  This could get tricky, as I've noticed I can't assign free text to the instructions board, and completely different free text to another element.  I'm cheating around this by making images of common wordings (like "got it", "Play", "Start new game"), which I may just continue to do, or find a better way to do text.  Other management issues not yet tackled include 1/4, 1/2, 3/4 time breaks, AI for opposition scoring, storing any setting change, previous scores.  There are stacks of bigger things, but that will be V2 if ever.
• AI.  It's off to a nice start, there are plenty of minor bugs still.  I need to also think about when not to run full speed to places, such as getting to a contest still jogging, not sprinting to a stop and then jumping at contest.  When to run backwards, when to brace for a collision, when to lead or hang back.
• Contest.  Similar to above, but worthy of it's own section, this is nearly non-existant so far.  So I need to build good physics around bumping into players, wrestling, diving for a ball, change of direction.  Not really AI, but more physics around how things will work.  This is vital, if I get this right, the game will feel right, and if feels right, it will be a good game, pretty much that simple
• Graphics.  This area improved a lot, and I need to focus just on what I can easily achieve I think.  I need to paint the bipeds with football clothes, which I started and wasn't all that problematic.  I need to check through the animations and get those looking OK, especially around contests, though animations are going to be a weakpoints, and there is no easy answer there.  I need to work more on the home ground, though it looks OK for now, so this might be a lower priority.  Scoreboard still needs completing for when showing scores, not the menu.  Grass textures, ads on signs/field, crowd, umpires, animations for celebrations, coaches, kick to kick, these are all on the way too low priority right now, AI/Contest are far more important.
• Sound.  There is none right now, and perhaps by V1 release too, again due to not being as urgent.  What I do have planned is crowd noise, football impact, collision noise, players calling.  I'd like noises for pressing options, music in the background.  Options to turn sounds off too.
• Sound.  There is none.  However unfortunate, it may stay that way too

Looking at that list, I could spend a bit more time getting the ability to play a game with scoreboard going, which I'm only a few steps away from, so perhaps that is my main focus by next week, and then AI/contest has to become most of the focus:

• Fix any bugs around end of play, should be able to also go to next contest without fuss
• Show scores after each play, and the score during play.  I'm thinking of using a scoreboard like material and images to place on top rather than free text, somewhere central and big for current goal/behind/miss, and in the top right corner for current score, to give it a more authentic feel, will see how that looks
• Have a 1/4, 1/2, 3/4 times and game finished.  Show the full scoreboard with proper scoreboard look at these breaks too.

Wednesday Update #3 (Sundayish)

This will still be basically Wednesday, as I flew to Melbourne Thursday morning for a few nights away, and have done nothing since.  In fact, I was away from Friday before that with family and did nothing then either, so very little has happened.

I did get a few little pieces in:

• Discs under players.  I will get some player looks done sometime soon, however I still don't know that will quite be enough.  I also like the discs under players in AFL TV shows, and realise it's pretty easy, so did that.  I put a 2 colour material on it, so we now havve noticable teams, blue and yellow, and red and black.  If the player has the ball, the disc spins too, so it's obvious when someone has the ball.
• I also added a trail to the ball, to make it more noticable where the ball is and the angle it's going.  It's as simple as a Trail Renderer in Unity, and took only a few minutes to tweak into something quite impressive.  I might have to stop it when a player does grab the ball however, as it's more for when it's being passed.
• I also took a couple of looks at the AI, mainly stopping the crazy running in circles, as it's driving me mad.  I tried to slow down when trying to turn more than a few degrees, and also to be more liberal in knowing when they are almost at a target.  Still not there, needs more time.

Most of all, I've changed the scope down to a total of 12 weeks work, from when it started.  It comes back to an idea from the Unity forums, which is to get something released.  The theory is if you set your ideas too big, the end line can shift, things can get a bit too hard, other projects come up, etc, etc.  It's essentially easy to not finish something, and always have that idea that never really led anywhere.  So the 12 week idea is to get something released in 12 weeks, just get something done.  Beyond that, is yet to be seen, there are so many variables.  In my honest opinion, it may need some support to go too much further.  I'm not necessarily talking financial, more just community support, which I'm hoping to get from a football forum, and perhaps even just from downloads/ratings on the app stores once live.

The 12 weeks will be essentially end of November, and I've really warmed to this idea, as it gives me a harder deadline, but that allows the scope to stay small, and perhaps just to grow as needed from there.  Also, in reality December is a difficult month, so having something out there is probably better than to be expecting to work on it hard.  Perhaps it's a good time to work on some post release work that is needed, if nothing else clean up some release bugs that come up.

So not much to report, but hopefully it's back on track this week.

Wednesday Update #2

A lot of good things have happened this week. I'm still quite shocked at how easily things have seem to come in the first few weeks of using Unity.  I'm not saying there aren't concepts that are well beyond my current skill level, but when I do think of doing something, it tends to be something Unity has accounted for more often than not.  You know, it's kind of the opposite to a lot of things, eg. Netflix (OK, Netflix AU especially).  When you browse Netflix, it seems wonderful and grand.  Like a framework that demos all it's strong points in an instructional.  But if you search for a specific film on Netflix, it's massively dissapointing, quite like having an idea, and seeing your code framework won't support it.

It's difficult to know just where to start for this update, I think I'll just do a walk through of how the game currently plays, and how much I've done in each area.

Firstly, a little theme overview.  Having no licensing for a sports game poses problems.  No matter how you put it, people love characters and teams, sometimes more than the sport itself.  So while the obvious route would be to make a fake league that mimics the big time, I'm going a very different way.  I'm looking at creating a grass roots game, with the look and feel of the smaller leagues, with it's small but passionate crowds, interaction, kids mucking around on the oval, ice cream truck on the hill, mates with eskies, old fashioned stands and scoreboards.  It might seem an odd choice, but it really fits with me.  I go to big games sometimes, just last week went to a game with 60K crowd, last year 100K grand final.  But I honestly enjoyed if more in a 6K crowd a few years ago when my team travelled way out of the city to play the newcombers.  Best of both worlds for me, good football, good atmosphere and feel.  I really don't gel with the sardine like stadium seating, long queues and massive prices for anything, an hour to get out of the carpark.  I figure I have to be true to myself first, and in doing so can hopefully catch a few other hearts out there too.

So, in saying that, here is the run through:
* Start.  Last Wednesday I had a functioning start menu, with one working option, Start New Single Player.  It was a 3D floating canvas, and looked fine, but I had concerns over how to get that to the next level of look and feel, not my strong point.  Even the crud AFL games have some slick menu systems.  It came to me Saturday.  If I'm going grass roots, what better way than to display the menu on a grass roots scoreboard.  I already had the scoreboard, so quickly added a couple of cubes, put an image of a nice old scoreboard font (similar at least) saying Start New Single Player/Multi/Settings.  It stuck my eye that the scorebaord was black, just just windows paint black.  I looked around for how to make it look more realistic, and settled on a hybrid image, which blends between black and grey in a random sort of way, and now it looks a little tired and worn, excellent, a real scoreboard.
* After you click Start, you go straight into the game, and have to choose what your full forward should do, lead forward, drop back, or move slowly to the middle and wing it.  Not much has changed here, there are 3 discs that appear, click one of them, choice is made they slowly disappear.  After choosing, the AI defender chooses what defense they will attempt, and a 3, 2, 1 countdown begins.  I loved the discs at first, but am less fond of them today, they may go, I might get the user to drag the player to where they want them to lead to instead.  The countdown may go too.  It's mainly there to allow for networking problems in multiplayer, so attacker and defender can make a choice, it's an indication both of you have chosen, but come to think of it, I'll probably just have a sign showing that other player hasn't chosen just yet, no need to slow people down with a 3/2/1.  Although it's still nice to know how to do it.
* Once the countdown finishes the player starts doing what you told him, and the defender does the defender AI choice.  There is also a player further up with the ball already, and another defender on them, and they are just staying there as if in a marking situation.  There is a tonne to do here still.  I have lost some AI code here, I want the AI to allow player or defender to be able to choose a 2nd strategy if their choice is clearly not working, but that shouldn't be too difficult to add in soon.  I will also look at adding more forward/defenders, as 1v1 seems a little easy.  I might even make this fairly random, so sometimes you do get the 1v1, other times it's a crowded forward half.  Perhaps it's not even that random.  After you kick 3 goals straight, AI decides it needs another defender, so suddenly there is a spare defender too. Less random = better in my opinion.
* You then tap somewhere on the field to pass it there from the half forward.  To be honest, this part still feels fine.  One part I love is that a player can make the decision to pass it anywhere quickly, because there is usually a big disconnect here between player and what button to press.  Eg, in a Madden situation, I have to learn who is XYAB, and while the play is on I'm trying to remember which button is B, woops got it wrong.  In real life, the difficulty is knowing how far in front to pass it, not looking down to see if it's button B.
* So the ball is kicked, and the full forward and full back forget their leads now, and try to get to the ball target.  If they get there early, they stop.  This is technically not wrong, but it looks silly, they should slow down to a jog if they are getting there too quickly, or perhaps wrestle/bump first if they aren't open.   But it's fine for now.  They at least aim to meet the ball before it lands at good jumping heaight, and jump at it.
* Next up the contest.  Forward and back both jump at the contest if they are close enough, with forward trying to mark always, back happy enough to spoil unless clear.  This is one of the biggest areas that needs improving.  It works OK, but the contest is one of the most important parts of the AI/animation if I want to get a realistic game.  We should have things like bumps, players jumping over others, etc, etc.  But for now, it's simply if I'm more open I'll mark, otherwise it will be spoiled, which is OK for now.
* If the forward takes a mark, they line up for goal, and the defender stays on the mark.  This is all new, and I love it with minimal efforts made so far.  Something to mention here is the camera.  I had a 45 degree, behind the goal view for the game, but when I changed the menu to the scoreboard on the hill, I added a pan back to the game view position and rotation, it works so nicely.  So I did the same here, and for the first time, you are down with the player, staring at the goals.  At this stage it's a simple task, just tap somewhere on the hill behind the goals, and it sails through, but I will add some difficulty to this later.  A box collider registers it as a goal/point/out of bounds, and the player is shown this result on the screen.  It's a 3D text at the moment, but will probably be soemthing fancier, and likely even have the goal umpire running round doing their thing later.  I also want the player to celebrate/get upset depending on result, talk about this later on.
* The result stays on screen for 3 seconds, then the camera whips back to the top down view, and you start again.  Scores are kept, but nothing gets displayed at the moment.  There is also no exit/skip function, and it's possible to get stuck if a mark isn't taken.  In this case the players keep playing, and you can even still score a goal/point, but if you don't there is no way to stop the game.

Overall, the AI is still very weak.  As has been shown above, I've played with quite a few areas this week, and while some new AI has been added, I still haven't replaced everything I lost a couple of weeks ago.  But there is random strangeness creeping in in most areas.  For example, if I mark, the defender correctly goes to the mark, because they are closest.  But then the other defender comes down, and also tries to stand the mark, while his opponent drifts into goal for an easy mark and goal.  Also, I had no animations until a day or so ago, but added idle and run recently, then jump and kick(s) last night.  It works fine, but I had to stop just moving players around like chess peices, and instead get them to rotate to where they are running.  Before, if there was an overshoot to the right, they'd whip back to the left, and so on, left/right/left/right.  Now that they turn and run, when they overshoot, they start running circles around their target.  It's easy enough to fix, but I need a more realistic solution, which will include a lot more animations (eg. stop running hard, turn back to the left) and physics (don't run in a big circle to turn around, slow down, change direction then start running again).  If I kick at goal the raycast hits an invisible collider, so players start running towards the hit point, which is 5m in the air, so they float up while running.  Very funny, but very not life like, and any one of these things will immediately take you out of the game feel, so I need to get on top of these things.

I'll call it quits on the Wednesday update, but have a bigger scope sort of email coming up too later.

Wednesday Update - 14/09/16

A lot of stuff can happen in a week, and I really want a track record of where things are going, and where they've been, so this will be a weekly post.  As my skills grow, I may even set weekly goals, but as this is a hobby project, and my skills are low, I'm just happy to progress much week to week.  Suffice to say I am working off a goal list, but timelines are not a problem for me yet.

First, I'm trying to work out the start point of this project.  I came off the rush of programming an olympic schedule, and spent the first week of the olympics updating that app, and Web Api with schedule updates and medal tallys.  But as the 2nd week came along, most things were automated, and the app was good enough to leave alone, so I stopped there.  For about another week, I started a 2nd Android app, which I still intend to finish, although I'm waiting on a Mac, as I'll probably start my 2nd app as an IOS app first just because, well... because.  Then I got hooked on the idea of writing this game.  I first started looking at the OpenGL libraries, using the OpenGL ES from Android Studio.  I managed to get a 2D version of my sprite player charging at the sprite ball.  About half way through that process, my work colleagues told me Unity instead, which I ignored at first, because who wants a factory to build a tanker when I'm trying to build a tin boat.  But I read up on it anyway, and eventually decided to give it a go, and I was instantly hooked.  Sprite moving from A to B came a lot easier, so much more fun to do, so much more power, C# code, I think I'll be here a while.  But then the more research I did, the more I kept hearing Unity is kind of 2D retrofitted, and you should just start practicing in 3D at least, so I did.  Once again, hooked!  I'll put a start date of my Unity 3D game to somewhere around August 20, which sounds insane as that's only 3-4 weeks ago.  Seems like a year ago, but the dates don't lie.

So much has happened in those weeks then, that it's going to be really hard to sum it up, which is why I probably need a weekly update to all this.  First of all, wow, it's mind blowing how much thought I've put into this so far.  It's an idea that's been a long time coming, but the details are flowing through in a huge hurry now, partially with the game, partially with Unity and game programming in general.  I'm pleased to be putting a lot of effort into it, but am still hamstrung by time, with a day job, family, etc.  Programming has a very slim amount of time to allocate, but I'm getting decent chore time to listen to youtube tutorials, or just think out some concepts.  It also hasn't hurt that weather has been pretty average, so I've been on the train a lot more recently (as opposed to bike commute), more time for youtube/planning.

Learning 

Which gets me to my first update, learning.  I've been doing a tonne of this.  My usual podcast routine has been rudely interchanged with Youtube Red videos.  I probably do 10+ hours a week of mindless chores and used to listen to podcasts/music, but now it's Unity videos.  Some of it escapes me as I focus on what I'm doing, but I hear a lot of the same concepts, so they are starting to seem familiar.  I'm mainly focusing on beginner stuff, because I don't want to spend 3 days doing something basic that I could have got from one of the many basic tutorials.  New to Youtube (aside from music, and the kids watching Dan TDM drone on), I'm finding the big challenge is a big clear voice to listen to, especially as I'm rarely sitting in front of a TV/computer when watching.  Speak up people!  My memory does me no justice at all here, as I'm sure I've seen a lot of good videos I can't remember now, but the highlights have been quill18 and Holistic 3D so far.  Very different approaches, but easy to follow, loud, and interesting content that seems to flow nicely.  I haven't found a good book yet, though reading is not my strong point anyway.  I feel like while I've seen videos touch on almost every part of Unity that I'm interested in, I am still (obviously) getting by on very little real knowledge in Unity.  That said, a lot can be done on very little knowledge, which is what I'm really enjoying about it.

AI

  

Since it's one of my favourite topics right now, it's also one of the first problems I tried to solve.  I wanted to make sure I can do this, because a simple game like mine needs something to keep you engrossed, and I think AI is a big part of that.  First big challenge was finding a way to write the AI.  In my first attempt at the HTML5 version of this, it was literally going to be if/then statements.  I can only imagine the joy I would have had once I got more than a couple of basic concepts in.  I'll be honest that I haven't tried every approach yet, but have found one I liked.  I first played with State machines, which I thoroughly enjoy, here is an example I followed:

https://unity3d.com/learn/tutorials/topics/scripting/using-interfaces-make-state-machine-ai

This works, but I don't know it's 100% right for my project.  I feel like I will go to the same state from several states, and I think this is where this model will get hard to maintain.  What if I change a condition to go to this state, and it's from 4 states?  

I looked at behaviour trees, but to be honest not a huge amount.  I didn't try it myself, as I was worried that again my situation might get too difficult to maintain with behaviour trees, though it wouldn't suprise me if that's wrong.

I took a look at Apex Utility, mainly just watching their whole youtube series.  It looks very good, and I still may jump over to it, especially if I have issues with performance and debugging:

http://apexgametools.com/

I found a lot of resources on GOAP.  This sounds much better for what I'm doing.  Write an action, give it requirements and outcomes, then that action is written, completely isolated from your characters, their state, etc, etc:

http://alumni.media.mit.edu/~jorkin/goap.html

Out of a couple of GOAP Unity examples I found, this seemed to be clear and easy to follow:

https://github.com/anneomcl/HappieGOAPGame

The big problem I found (and would love to still know the answer to this) is it seemed really difficult to interupt an action.  For example, if you've read through the GOAP stuff, imagine your character is very hungry, so the best action is to get food from fridge.  But on the way, ninjas appear.  I couldn't find a clean way in this code to break the food action if ninjas attacked.  I managed it, but hated how I did it.

Which led me to a seemingly simple approach, which ticked all boxes:

https://www.youtube.com/watch?v=bc86es4YOoc

With this, I could manipulate it easily to do everything I wanted, including have the AI "sleep", and wake it up, have the clean simple actions, have the weight based decision making.  This is what I've chosen as an AI framework, and so far no restrictions or issues at all with it, though I've been bitten a couple of times by creating a new action, and forgetting to assign it to my players..

What I do have issue with is backing up.  Early last week I imported something, which I really didn't like, so I went to delete it.  Long story short, I deleted everything!  My previous backup was from 4-5 nights earlier, and was 90% AI code.  This was very frustrating, but rather than dwell too much, I used it as a way to streamline my thoughts on the project in whole.  Firstly, I have a tonne of learning to do, a tonne of code to write, and I was going too deep on AI that wasn't going to be necessary to release, like what to do in situations that weren't possible in the first cut of the game.  So I may have lost some code, but gained some focus.  Since then I've worked mainly on other areas, so AI is back to near the starting point in terms of code actually in my project right now.

Graphics

  

Yes, I am awful at that stuff, and this is where my game should really struggle.  But thanks to Unity, thanks to Youtube, it's nowhere near as sucky as it should be.  I can only imagine some people will laugh when they see it, but if you know what I'm capable of outside of Unity... well, I'm happy with what I've acheived.  The concept of scenes is OK, though I'm still fumbling a lot around with the cameras, lighting, terrains, etc.  A simple concept in my head is either done in 5 seconds, or sometimes 2 days, in a much more complex way than I thought it would be.  Some things I haven't been able to do, but to be honest, it's mostly been good.  

Firstly, to make my life easier, I've used a scene where 1m = 1x or 1z.  So I know a player might kick the ball 50m, that's Vector3.Distance = 50f, this seems to work well so far, and makes it very easy in a script.  Next up was a grass like surface.  I used a terrain, and added a grass texture I found.  Graphics people may be laughing at it, but I like the look of it.  I knew as soon as I saw it, that a few line markings, fences, stadiums etc, and this would look great, which I still think.  The characters and animations I got from maximo.com so far.  I'm really not looking forward to trying to do anything that isn't supplied in this area, but we'll see, as I know people get upset if the animation doesn't look great.  I understand, I don't want to give people easy reasons to dismiss my efforts.  The boundary lines were going to do my head in, but I found a link (can't find it now, grrr) that lets you place a transparent picture onto a terrain, it worked brilliantly.  I now have boundary lines, 50m lines, center square, goal squares, and it all looks great.  For fences, I built a bunch of 10m long, thin cubes, and placed them around the boundary line.  Looks good, though I do want to put some gaps in later, and advertising on the remaining.  Like many things, beyond the fence seemed daunting.  I wanted some grass hills, and some stands.  For the hills, I started with rotated cubes going from the ground near the fence, up to a high point.  It was OK, but had problems.  What I really wanted was to raise the terrain into a normal ramp like hill, but it was impossible to do it as I wanted... until I found this article:

http://answers.unity3d.com/questions/211089/best-way-to-make-ramps.html

That was 100% what I wanted, and gave me really realistic looking hills.  There are even some mild imperfections, exactly as you'd expect given real hills are not a perfect flat surface.  I think they look great so far.  Next up were the stands.  I found a pictture of what I wanted and actually did it in Unity itself.  I tried Blender, but had no idea what I was doing, so used Unity, basically adding levels on top of each other, which is what the picture looked like anyway.  For colours, I downloaded some more textures of asphalt (what the ground was in the picture), corrugated iron for the roof. and brick for the wall.  To be honest, my lack of skill showed up here, as the textures look great as a single tile, or up close, but from a distance all you notice is the repeating patterns in them.  That said, it still looked way better than I thought I'd be capable of.  The last things I got up last night were trees and scoreboard.  Not complete yet, but I just wanted a little something extra before I called it quits, and this was easy to do and looked great.  I had a couple of animations going, but lost those in my backup disaster, so the characters are bland T shaped mocap characters that float to the ball right now.

Gameplay

After I lost my code, I went about some of the starting points of starting a game, like a main menu, and a couple of game choices.  In fact, I went from nothing here and a lot of AI, to nearly no AI, but a way to get all the gameplay options done.  I don't mean all the menu options, I mean click start game, make a choice, click on things for gameplay etc.  It's all very early on, and it looks very bland right now.  As for actually gameplay, I have played a bit with colliders, rigidbodies, physics, etc, and find there is a lot to do here. As an example, because my ball can bounce, and my character is a colider, the player can't pick the ball up, because as soon as they get close, the ball bounces in front of them.  I have (perhaps unwisely) turned off a lot of physics for now.  For the ball flight, I tweaked this code to simulate a kick or handball:

http://forum.unity3d.com/threads/throw-an-object-along-a-parabola.158855/

It works really well, and also gave me an insight to coroutines, which I still haven't used elsewhere, but guarantee I'll need to (probably AI before too long).  

As for scripts, there is a game manager script, which stores the state of the game, and can do some updates for UI and gameplay type things.  As an example, I have a 3, 2, 1 countdown on screen before the action starts (may or may not keep this).  Some discs also come out of the graound at some point to allow you to make a choice, I hope this stays.  Each player then has a player script.  On Update the player moves/animates whatever they were doing, and every so often (time depends on the current state and position) AI will refire.  As an example, you could in an action to lead to a pass, but once the ball is kicked, you are no longer leading, but trying to get to where the ball will land (actually to where it will be head height to catch).  Every player also has all the AI scripts attached to them.  It doesn't matter that the full back will probably never kick at goal in my game, they are still a player, and should still have the capability to do so.  At very worst, it would be embarassing if they somehow got the ball in front of goal, but looked to pass it because they weren't taught to kick.  Some of this may hurt performance, but in that case I doubt it as the kick at goal action requires you to have the ball and be close to goal, so there will mainly be a lot of return null with a single if.

That is a big update.  Things will obviously slow down a lot over the next few weeks.  As I said, no official goals this week, as I could end up spending the next 4 nights on a single issue, or perhaps learning to use blender.  Still, I'd like to leave every weekly update with a list of important links I've found.  They are a bit lacking this week, notb because I haven't seen a lot more, just because I've forgotten about them.  But hopefully from now on, I'll keep a better eye on the links I use:

This one is completely new to me, viewed on my train commute this morning, but apart from being a bit quiet and slightly rushed, the first 3 videos in this series are seriously packed with blender info.  I'm looking forward to this series now, who knew 3D was so easy :)  

https://www.youtube.com/watch?v=zlv0zn5xJqU

Not sure I'll use this at all, but perhaps a method to make the terrain hills/other things more low poly, if necessary:

https://www.reddit.com/r/Unity3D/comments/1uy2ma/creating_low_poly_unsmoothed_terrain/

http://gamedevelopment.tutsplus.com/articles/go-beyond-retro-pixel-art-with-flat-shaded-3d-in-unity--gamedev-12259

The following are all based on app idea I've had.  It's core functionality is half written in Android Studio, but thought it may be fun to write in Unity too.  Pros are could make very cool special effects for an app.  Cons are it's almost certainly too much to download/startup time for a fairly simple app:

http://answers.unity3d.com/questions/706142/openstart-device-camera-in-unity3d-app-using-c-scr.html

http://answers.unity3d.com/questions/266244/how-can-i-add-copypaste-clipboard-support-to-my-ga.html

http://forum.unity3d.com/threads/zxing-library-with-unity.335017/

https://www.assetstore.unity3d.com/en/#!/content/52154

http://forum.unity3d.com/threads/mapnav-google-maps-navigation-toolkit-released.213631/

More advanced discussion about mechanim and it's problems, a bit over my head for now:

http://forum.unity3d.com/threads/mechanim-pain.420398/

Half decent story about release time:

https://madewith.unity.com/stories/pre-launch-panic-attacks

Will call it quits there, got to get back to coding this thing.

Game AI (part 1): To exploit or not

Rock, Paper, Scissors.  Imagine we were building the AI for that, how would we do it?  It seems simple at first, randomise the decision, we can't be beat, right?  It is right, statistically we could win or lose against a computer doing this, but over 1000s of games, we will win the same percentage as the computer, it's essentially a no win decision.  It is also an unexploitable AI decision.  No matter how clever we are, we can never find a system to get better than break even in the long run.  This is not fun for humans, we like to be able to beat AI, so how do we dumb down this decision just a little bit?

Lets look firstly at making the decision a whole lot smarter.  Think about this.  After playing this rock, paper, scissors game for 10 minutes, we come to the conclusion it's completely random, so we starting choosing paper every single time, because we just don't care, or perhaps we are trying to work out if it really is just random.  This is no better or worse for the player, because the AI is indeed random.  Our unexploitable AI decision now seems very dumb though, because it should be choosing scissors every single time and winnning.  If you were playing against a human, there is no way the human would randomly choose rock if we had chosen paper 5 times in a row.  So the AI in this case is unexploitable, and completely non-human like.  That can't be good?  So lets add a bit of logic.  If human player chooses paper 4 times in a row, choose scissors, else choose random.  For argument sake, lets say it's also coded that any decision 4 times in a row, on the 5th attempt make the decision to beat that decision on the 5th attempt.  The AI just got a little bit more human, and at the exact same time, is now exploitable.  Once the human works out the AI decision making process, they can make a strategy that exploits the computer.  Once worked out, I would always choose rock 4 times, then on the 5th choose scissors.  Then scissors 3 more times, then paper, etc etc, until we are splitting 4/5ths of the time, and winning 100% of that 5th turn.  In this game, that's a pretty decent level of success.

Again, the human decides instead to just alternate in the exact same order, rock, paper, scissors, rock, paper, etc, etc.  Again another human player would pretty quickly work this out and start exploiting, but how does a computer do that?  Most likely they have to recognise it as a pattern, which we effectively have to program in.  So we program it in, if they chose, rock, then paper, then scissors, we'll choose paper next, to thwart their next decision, which probably rock.  Next instead the human keeps trying scissors, paper, rock (ie. reverse it).  Now, the computer should be able to exploit that.  We could end up with a lot of code, just trying to be more human.  And every bit of logic we add in, makes another part we can exploit.  To go down this route too much further would be recognise a human pattern, exploit it, but then realise we could be exploited back.  The code gets really hairy here.

To go to the nth degree on this, look at this web page:
http://www.nytimes.com/interactive/science/rock-paper-scissors.html?_r=0

In theory this is the machine learning approach to beating us.  When a player does X, and we do Y, our DB, sampled over 1000s of users says their next move is most often Z.  There could probably be a whole book on the approach to using this data to make a great machine learning rock paper scissors, and the machine learning itself could be extremely simple or complex depending on who is driving it.  I think in terms of the one used here, it basically looks over the last 5 decisions made by both players, and matches that up against a patter in the DB of all the other users it played before, and works out what your next decision will be by weight of most common next human decision.  This strategy is creepily good, because humans are actually pretty predictable when playing this random game.  Yes we are trying to exploit, but then so are most humans, and we get caught trying the same exploit.  To be honest, with a decent range of games and opponents that have played, this AI is very human like, and a very smart human like... however, it's still exploitable, because it goes into every game with a set strategy.

Finally, this approach, though very awesome, still says nothing about me personally.  Forget rock, paper, scissors for one second, and think about a generic FPS game.  The programmers have gone to great lengths, and machine learned everything, right down to how fast humans usually respond, lets say 0.3 seconds, and the AI decides to make their decisoin 0.35s, giving the average human a slight edge.  This is great, but if the human happens to be more like 0.4s, we will get slaughtered and likely stop playing.  Likewise, the better players our there are well under 0.2s and they think this game is far too easy.  This seems an ideal time to think about either editable settings, or perhaps going the rubber band theory, allow the AI to adjust it's settings based on previous history.  Of course, the major issue with rubber band theory is the rubber band can be manipulated.  For example, if I play 3 games in a row, and deliberately react 2s for every shot, the AI will have a lot of evidence that I am on the extreme side of slow, and treat me accordingly, how could it not?  So when I go to get a high score/show my friend how I crush this game, I suddenly go back to 0.3s to show them, and suddenly I'm winning the game with amazing ease.  Yes, this theory is exploitable too.  I could probably adjust way quicker with the rubber band to evidence of suddenly improved times, this would make it a lot more human.

I guess it comes down to, the first thing you have to admit with AI, is that it will in some way be exploitable (or be your lifes work), so at that point, you can embrace that fact, and make sure you control just how you want that exploit to be happen for someone to beat your AI.  I'm planning to have a little fun with exploiting in my game.

Unity 5 Reboot

Time to dust off this old blog.  Why?  Because I'm doing this game again.  In short, the HTML5 version went nowhere very quickly after my last blog post.  But the idea never died, it just lay dormant for a while.

It's back, better than ever.  HTML5, what was I thinking, Unity 5 now!

I actually blog this a few weeks into development, so I've had time to adjust my brain to the idea of building a real game, and I'm still not so scared off that I'm quitting, so it's time to blog about it again.

The aim of the game has actually changed very little from previous posts, fair to say it's virtually identical.  You get a player to lead for the ball, AI tries to stop you, your aim is to score goals.  I still think this alone can make a fun and interesting mobile game, so I'll be aiming for ios/android.  

On a macro level, I've added a few small ideas, and had a million ideas on the micro level.  But the bigger feature ideas include:

• Decision making is extended to where you want to lead, kicking to the right spot, kicking the goal.  AI will still do a lot of the heavy lifting.
• Can now defend against AI also
• Can play multiplayer against other humans
• 2D is now 3D, but more of a 2.5D game, as is intended to be a top down view gameplay (that in theory can be any view, perhaps even a user setting depending on their preference)

Now, I did just recently throw together a quick android app for the Olympics, a schedule app.  This went mostly the way I expected with just a couple of glitches:

• Don't try to write an amazing app in 2 weeks.  Amazing very quickly turned to glitchy, featureless and awkward looking
• Don't publish an app that isn't amazing.  The biggest problem with "glitchY', is that users are itchy to give a 1 star review.  Then the awkward look/featureless stopped people giving it a 5 star.  To you, it's your little baby that makes your heart shine to look into it's eyes, but to the rest of the world, it's just another smelly, screaming baby.  That analogy is a little harsh, but the overall point is, you have to be able to detach yourself from the app, and really criticise it, until it can stand up against your harshest criticisms.  Then you can publish.
• People don't think the same.  I talked to a bunch of people who installed this app, every one of them had a different way it should be to be a better app.  At first, this was taken a little to heart, "why can't you see that it's written in a really clever way."  But after the 3rd or 4th bit of "helpful" advice, I realised it's impossible to please everyone.  We do think of this in our day jobs, but it's always an eye opener when you get feedback that doesn't sound logical to you.
• UI is not my thing.  I know what I like, not necessarily how to do it well.  I had some ideas of how I wanted my app to look, it really didn't get there though.  It may be a case of more time and planning though, so it would be interesting to see how I go with a 2nd published app, which I intend to do after this game.
• Google does a pretty good job protecting the official apps.  I had to change a logo because it had olympic rings, name because it sounded like the official app.  I almost certainly won't be able to call my game AFL, as that is a brand, Aussie rules is the sport.  This kind of sucks, because nobody ever searches Aussie Rules, it's always AFL.
• And I sort of covered this in the first point, but polish takes time and planning.  Trying to force a product to a deadline has the exact effects you'd expect.  I had planned to have a learning AI server.  It would see what others "like you" had manually chosen as their favourite sports, and suggest it to you.  It would suggest Swimming for Australian fans, because we love our swimming.  It would suggest womens rugby if your team made the final, etc.  But in the end, the AI feature was completely ditched and you were on your own with choices of favourite sports.  It's a shame, because this was the part of the app I was most looking forward to writing.

All that said, I enjoyed writing the app, and it wasn't as flawed as I make it out to be, it just lacked some polish really.  I used it a lot, and thought it performed well for what I wanted.  

Now, the future is this Aussie Rules game.  I've got to allow myself a lot more time for this, I'm aiming at the start of the 2017 season.  Given there is a bit of time, I'm going to go about some proper planning this time.  So here I'll layout a fairly high level overview of the core goals:

• Goal 1: polish and publish.  I think I can knock up a playable prototype in around 2 months, so that leaves 4 months of polish.  This assumes of course I don't go down some other rabbit hole.  I'll give two examples of polish.  One would be AI.  Not only do I want the AI to be fairly bulletproof, I want people to walk away thinking about it.  So I want mindblowing AI.  You may say "how do you do mindblowing in such a simple game", the answer is of course, polish.  I'll get more into this in another blog, but I want polished AI.  Another example is user interactivity.  I don't want people left with too limited options, nor too many.  I basically want to have people play the game without too much learning curve annoyance.  A good example is having a tutorial, allowing the user to see it first time, but be able to replay it in case they skipped it the first time but now want to watch it.  Not critical, but nowhere near a high priority yet, but still would be part of a polished product.
• Goal 2: mentors.  I'll admit to be a bit of a hermit programmer.  My idea is always better than the group idea, at least to me.  A very experienced friend drummed it into me that I must do the mentor thing, it's not even worth doing a project without it.  This makes sense, but it's not how I wanted to operate.  However, I'm going to do it, because he is right, it's something I should do.  I haven't gotten the full details down on this, but I'm going to search fro someone to help me through this process, and plan to use the approach again if I make apps.
• Goal 3: contribute.  Similar to the mentor thing, not really my game.  But I've got a unity account, and should get active on forums.  I should also blog (tick), and tweet about it.  
• Goal 4: profit.  Of course, money?  Not really money, more like downloads, game playing.  I don't really know a realistic goal, so lets start with facts.  Fact 1, AFL official app on Android has 1 million downloads.  I'd imagine a similar number on IOS, and I'd imagine a percentage of people that have installed it on multiple devices that they don't even use anymore.  Either way, 1 million is an impressive figure.  Fact 2 and 3 are the official licensed AFL Live game is only 1 thousand downlods, and a non official game is 5 thousand.  Fact 1 is skewed, partially because it's a $10 game, which is expensive relative to other games, and it's also a huge download, which makes it impossible to install on a lot of devices, it rates only average overall (including a lot of cannot install/play reviews ) and finally, it's only been released recently.  That said, it has AFL in the title, is fully licensed and is a pretty good game, going by the ipad version a few years ago.  The 2nd game is more likely what I'm up against.  It's free with ads, doesn't have AFL in the title, and it's a small fun game.  My game aims to be a lot better, time will of course tell.  I'm going to aim at 2 thousands downloads in the 2017 season.  I'm also going to aim for at least 10 days of playing the game on average.  That may not sound like much of a goal, but that is already 200,000 game days, which will be near impossible if I can't deliver a decent game.  Actually, I'm also going to aim for at least a little forum posting about it (and not by me).   Money wise, it's probably a "for fun" project to be honest at this stage.  If there really is 200,000 game days (which I hope to accurately track using a web service, maybe), it would be silly not to expect a little advertising money may slip through.  Maybe enough to pay for that web service?  A very rough calculation says even if the pickup is 10x that amount, the advertising wouldn't be quit your day job sort of money either, so I might as well conceed this is a for pleasure project, not a for money.

OK, kick off time.  I'll be following this up with some more interesting blog posts (for me at least) about the actual coding challenges and ideas soon, which I hope may help some people more.