Spring Blog 6

I ended up no longer being in my position as a producer. I wasn't cut out for the role and quite frankly it was ridiculous of me to even consider it. I started working on programming instead. I ended up working on a code base I wasn't super sure about and every other time I look at it I realize how bad of a job I did as a producer. 

 The first thing I did was fix the AI. This was something that was bothering me, genuinely, for weeks and I was hoping for a solution to be found and nothing was found. So, what do I do? I come up with something mediocre in a few hours that ends up being ten times closer to the intended scope of the game. 

 

 

 Originally, the AI just guaranteed random movement. Crops would spin, move, and stop, and generally not act like players whatsoever. 

 My solution for this was relatively cut and dry. I look at the navmesh, I pick a point on the navmesh that's a minimum distance away. The crop goes to it. Repeat. With that, you then have an AI that has a more natural style of moving around the map with some kind of purpose, and while it's not great (I have to play with the minimum distance and find ways to force it to take inefficient paths) the way the new producer and director reacted when they saw it almost made me feel like I had a future in this industry. 

I know better though, and I also know better than to really let that be the end all be all. To further make them resemble players, I had them follow some reasonable strategic patterns that players would employ. Crops now keep their distance from the farmer if they're able to, some will go out of their way to collect nearby pieces of scrap, and will migrate and sit around touchpoints for a random period of time. These are all set up as a list of priorities along with the random movement. It's a state machine as constructed by a Chimpanzee.  The AI will avoid the farmer at all costs, and then there's a random chance of it going for a nearby piece of scrap or a touchpoint tested every few seconds via coroutine. I thought about creating a manager to make sure only a few AI at a time go for something at a time, but I decided that was too much effort for too much control that I didn't really need, and would've actively subtracted from the naturalism. It is honestly ideal for there to be a chance of multiple AI going for scrap, or multiple AI on different sides of the map going for touchpoints. This'll help give the players patterns of AI behavior to play off of. 

 

 

Additionally, Diego had fallen in love with the classic isometric perspective while looking for ways to make the game pop, and I was tasked with changing the controller input so it felt right with the new perspective. It was as simple as adding a rotation to the input, but it made that entire setup possible so I felt somewhat good about it.

 

 

 

I thought I'd hate working on party games. Another reason why I think I'd choke on gravel if I had a serious job in this field. What I found is that there's a genuinely really deep meta when it comes to creating rules sets and design for a game that's relatively simple to pick up and put down. This is likely not a revelation to anyone except for me. So much stuff can't be just taken for granted as something the player figures out; everything has to come naturally, or be discovered, which is a real pain to code. 

 

While I had fun this sprint, I'm going to be digging deep into the actual structure of the code this next one, focusing primarily on setting up player spawns to be just right and attaching events, audio, and animations to different entities. This is the Charlie Work of programming, and it's just about on my level.