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:
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:
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:
Out of a couple of GOAP Unity examples I found, this seemed to be clear and easy to follow:
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:
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:
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:
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 :)
Not sure I'll use this at all, but perhaps a method to make the terrain hills/other things more low poly, if necessary:
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:
More advanced discussion about mechanim and it's problems, a bit over my head for now:
Half decent story about release time:
Will call it quits there, got to get back to coding this thing.
