Moving Forward

After what feels like weeks of procrastination and struggle, with motivation and depression being punctuated by suffering a rather severe ankle injury. I finally think I am ready to push past the struggle and just get this shit done. So here is my plan to do just that. Good luck me, I guess.

Demonstration of AI – GOAP

My current demonstration of Ai in the creature feature project is lacking in its implementation. The integration of the AI with entities, world generation, and pathfinding are overly interconnected, and poorly planned. Resulting in any changes to one system require full thought to how it will impact the other systems, this is a big mess that is overly complicated to work with. To mitigate this and demonstrate ai without driving myself insane, I have decided to demonstrate through a different project that’s soul focus is the ai itself without any other complicated systems.

High Concept

Cover the idea of the project, the AI system, and the limited supliment systems.

Ai Breakdown

An in depth point to point breakdown and plan of the AI system.

Tech Spec

A breakdown of the supliment systems.

Tech Spec Documents

I need more progress on these in the areas of Writing and Updating. I plan to cover these with the GOAP project and the WOFSM project.

 

Post Mortems

Up to this point I believe that I have shown that I know how to write a decent post mortem, I just need more examples of that. I will be writing a post mortem for each of the coming projects. These being:

• Creature feature
• Home
• GOAP
• WOFSM

Tech User Doc for WorkOrderFSM

This is a small WIP project that I used to focus myself back into work after my injury. It is designed to make moving forward with the GOAP project easier, and also to prove to myself that I knew how to write a useable abstract Object Oriented class.

User Manual

Being I plan to release the WorkOrderFSM project as a public Git that others can download and use in their own projects. It needs a user manual.

Tech Spec

The tech spec will accompany the user manual as breakdown of the abstract class as a how and why.

DD Week(‘s) 3-5

Week 4-5 – Generating a world

This has taken me quite a lot of work to get right. It is still not quite how I would like it as the world is generated from tiles with perlin noise added to give some variation to make it look more organic. But the tile selection is still random, as i would like it to work from a seed so that maps can be reproduced.

The Maps:

This is true size of the maps they are 16×16 pixels using grayscale to store the information.

This is them with 900% zoom.

Black represents 0, this being the floor height. White represents 1, this being the wall height. And grey represents the ability to sway, between wall and floor, this allows the perlin noise to take advantage of this to change the design how the noise sees fit.

How it works:

Because the maps are 16×16 the world is only able to generate square multiples of 16. The map generator takes these 16×16 images, selecting from them and putting them into an image that is 1×1 pixel per position for the final map. Once it has generated this new larger X*16² pixel image. It then uses the pixel information to generate the world, as it reads the pixel data for each position it takes into account the perlin information base on that pixels position. The result is a 0-1 scalar value that is than simply using a bias for wall placement where any value below the bias is floor, and any value equal to or above becomes a wall. I am also using the perlin information with a different bias to place resources, that is why they all clump together. This is hopefully temporary.

Drones

I have taken this and the pathing from the weeks before to create drones capable of navigating the world, this still needs quite a lot of work, as they have a lot of issues, that I hope to address in the coming week.

The Remainder

This week we learned how to set up a simple physics interaction, in the form of rope simulation. And how to use Verlet Integration, to make it more performant. The last class of this week we will be looking over spatial partitioning and how it can be used to improve performance.

 

DD Week 2

This week I have learned: A* & GOAP (and a little bit of D*)

A*

I spent a long time trying to implement a pathNode generation system. That honestly turned into a pile of crap. But that’s how first attempts go. All it all it looked good:

After I had this thing working I begun to try to implement A* base off the class presentation. But quickly realised that the way I had done the grid implementation did not work effectively enough for a good implementation of A* as the two systems generated problems that I did not understand in their entirety. So I decided to make use of a previous tutorial(Sebastian Lague A*), that I have worked through before, this was a good result as I gained a better understanding of each part and its function.

GOAP – Goal Oriented Action Planning

Basically just read this and watch your horizons expand: Three States and a Plan: The A.I. of F.E.A.R. – Jeff Orkin

But in case you are to lazy to read it(Seriously, take the time to read it!) The gist of it is: Their are goals and actions. Entities have their own internal understanding of the world, and how it can effect that state to complete a goal. To do this goals are generalized to a desired world state. This means that any entity in the game can be given the same goal. And it must use its own abilities to attempt to shift the current world state to the goal state. To do this it has a range of actions that it is able to take. These actions can be anything that is relevant to the entity, the actions have prerequisites, and effects. And the system calculates the cosings of each action to stack them in an order that will hopefully result in goal state.

The little bit of D*

D star is a path originally based off A* pathing, it is designed to be able to handle the possibility of unknown path data. And to be able to improve the efficiency of repathingas the pathData is updated. To do this it makes use of propagation waves that are used on repathing as the propagation waves make it less likely or more likely to plan paths through areas based on the result of the previous pathing attempts. This alongside the fact that It plots its from target to current location make it able to update the path from a position up the chain allowing the entity to continue to Navigate along the old path while a new path is planned from the updated PathData. This can then be spliced into the current Path, allowing a continuous flow.