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.