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.
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.
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.
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.
This week I have learned: A* & GOAP (and a little bit of D*)
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.
This project was not the best way to start, but I can say that I learned a lot about my work ethic coming out of a break.
Lack of work hours resulted in lack of total work.
For the first two weeks(the timeframe of the Bytesize project) Outside of class I only completed about 3.5h outside of class. I believe this was caused by a combination of two main factors. The first being that I still feel like I do not have the necessary skills to be where I am today. A feeling that I have lucked my way through and have no right to be here. This is frustrating as I know that it is not true. As I have a lot of respect for my past and current facilitators. And I do not believe they would have let me progress to this point if they did not think I was capable. The second factor. Is that I did not feel that I entirely knew what to do with the project, but did not make more of an effort to reach out to my facilitator for guidance. That is on me, and requires me to be more proactive.
I have already begun to mitigate some of these. In that I have gotten some feedback for research tasks to motivate me to work. As researching is something that in the past has helped me get into a work mindset. Might be worthwhile for me to plan the start of each day to cover a short research topic. And to do with the skills garbage, I just need to have more faith in myself. And break things down until I feel that I am able to complete them. In the 5 minutes to midnight class, the facilitator covered a great way to approach tasks. By breaking them down, the same way that I have done in the past but in a more aggressively systematic way. This is something I feel will be beneficial and easy to implement upfront.
Learning through Implementation.
One big thing that I have really clued into during this project is that I learn best through implementation. But it’s not that simple. I need to understand what I am implementing at least in its most basic form. This is not really a revolutionary revelation. As it is the basis for how this course is structured. In the past lots of my work has been a result of “just get it done” this has not been the best way to actually learn from my work. As a lot of the implementation has been other peoples solutions hacked together, to make it work. Now these solutions have worked but the real issue is that I have not truly understood as to why the solutions have worked. So I plan to make a stronger effort to dive in further to how all the little bits and pieces work.
Short term: Start the day with some quick research for motivation. Systematically dismantle the task at hand until it is in its smallest parts. Make an effort to understand each of the parts.
Long term: I plan to keep tracking my progress and reflect after each project on how I went about implementing the solutions to the problems of past projects.
This week I have learned:
Some great tricks for storing data, using enumeration, and dictionary’s in unity. Great work on that btw Ethan. I have also learned about C# extension methods, and how awesome they can be. In short they allow you to be able to add on functionality to inaccessible classes, this can be great for wrapping non project standard workflow from external classes in project relevant functionality without having to specifically write a wrapper class. I have also learned about some pathing methods, some of their use cases, shortfalls, and common elements. These being;
- Spatial Graphs
- That use discrete points to manage their pathdata.
- Navigation Meshes
- That use mesh information such as polygons or polyhedron’s. So they are able to store path data, in points and edges, allowing for an efficient and flexible method of generating pathable areas.
- Potential Fields
- That use vector data to determine directional force inside of an area, allowing the path to effectively “roll down hill”.
Also learning about all of the things that you can do with Path data to take advantage of preprocessed data stored in memory to reduce runtime processing is quite extraordinary.
I look forward to the coming week to learn more about these systems and how we can take advantage of them for our own purposes.
What did I learn about my practice in Studio 1?
I learned that I do not work well when trying to make my own goals. This is a key issue that I know has affected me all throughout my studies, but only reality clicked that it was a key issue that had such a drastic flow on effect, during the wrap up of studio 1. Ways that I plan to mitigate this issue is to find someone I can use to help me plan realistic Finish Lines and Checkpoints. This someone should if possible be close to the project for a better perspective of the requirements, but if necessary, a friend or coworker that is willing to help. Finish Lines, are key stopping points, times where the body of work should meet a deliverable state, with realistic time frames, these are discussed and planned with the review of the someone. Checkpoints self reflections of the body of work between finish lines, where I check for any Redflags.
Redflags are as follows;
- I do not have the necessary knowledge to complete a task.
- Solution; is to do some research, and ask for help.
- I have spent far to long on the same task.
- Solution; reorder priorities and finalise talk to minimum viable.
- No documentation, jumped into production with too little planing
- Solution, step back and reassess planing.
What do you already know about AI? what do you want to learn?
I know that AI is about deriving a state from inputs, resulting in a desired behavior, that can be counted on to respond in the expected way when encountering the same world state. This is a wordy way of saying we expect an AI entity to react to stuff and things in a predictable way within the desired framework of that AI entities world space.
I want to learn about how we make AI appear to make smart decisions, I want to learn about how they communicate with other game systems. And how to make that an interesting thing for an external force(such as a player) to interact with.
What do you already know about maths and curves in games? what would you like to know?
Maths in general are one of my weakest areas of knowledge, If it is logic based maths I feel I have a strong understanding but dealing with numbers and doing complicated mathematics is something that I struggle with on a regular basis, but I feel this is an area of self development, more than a focus for studies.
I want to know lots of cool formula and curves and how they work so I can use them to implement interesting behaviors in efficient ways( the area of efficiency is relative to the task).
What do you expect to out get out of Studio 2? What do you want to get out of Studio 2?
I am expecting to get a lot of understanding of some of the more complicated areas of games development, and to hopefully make some interesting stuff. But what I would really like to double down on is sumilatory systems and how to make them resilient enough that they can work in conjunction to become more than a sum of their parts.
What is my end goal.
My end goal is to come out on the other side of studio 2 with some great knowledge about AI and system interactions.
This project has been the most productive project in terms of physical work, and output. The project suffered from rigidity and setbacks, but overall has come to a successful project conclusion. The communication dynamic experienced in this project is something that I will push for in future projects. And the implementation problems are something that I can learn from to better focus the efforts of teams that I work with in the future.
Communal work sessions.
Working at the same time as my teammate resulted in efficient communication, production, problem solving, and problem management. This communication worked mostly through discord. Allowing me to ask direct task and goal based questions. We quickly fell into similar work patterns, with a cooperative attitude on both sides of the communication. This was highly motivating for me personally, and I feel like I got a lot of good work done on our project. Moving forward I would like to make an effort to find one or more people in the group too work closely with, in a way that has a similar dynamic as this project. To do this I will be more directed in the initial stages of the project to express the way I work best and asses the most appropriate person to use as my lead. Outlining what I need to stay productive while also making an effort to respect the way they work best. If I cannot find this dynamic I will talk to facilitators about finding a solution. On top of this I plan to work on my problem solving ability to make sure that I can independently find solutions when needed. To do this I plan to work on more solo projects and implement day sprints.
The core interaction mechanic did not work the way we had initially wanted it too. This was caused in part by a break down in planning, and time management, not allowing for overflow time with the level loader. Partly more complicated than initially expected. And Partly because I was hit with a depression low that drained the three days set aside to write and develop the movement mechanic. This then resulted in a mad rush to cobble something together with the physics system. This rushed and overworked attempt to get something working for playtest resulted in a burnout that lasted most of the following week, this severely reduced the amount of effort I was able to put into the hours that I was putting in.This was then compounded by focusing on non key areas in order to attempt to have a stronger output. When the problems with the core interaction were brought up during playtesting, we still opted to focus on making the project feature complete before attempting to fix the core mechanic. We did not really attempt to leverage the rushed movement system as we always intended on fixing it, but we never put planing into fixing it, as other smaller things felt more urgent. We made the ultimate decision to leave it as it was in order to get the project to a completed state. In the future, I would I plan to focus on outcome over output. Make a rule that core mechanics come first. Learn some new things to leverage in future projects that I would have benefited from knowing to develop the two core systems in this project, these being; abstract and concrete types, delegates and events, and unity Scriptable objects. To mitigate these problems in the future, I will be making sure that the core mechanics have a more defined and outline plan of implementation. And during production I would like to make a per milestone checklist, to assess the development and direction of the core mechanics.
In the Clutter Tool project we were tasked with making a tool that could be used by us and others to improve the productivity and workflow of future projects. I was initially excited as Tool development has been something that has interested me since I got into programing. But after the idea had been settled on it quickly became apparent that the team was leaderless, unmotivated and unwilling to communicate. This resulted in production conflicts and the project simply grinding to a halt, and being abandoned shortly afterwards.
This is probably one of the least communicative teams that I have ever worked with. At the beginning of the project when deciding what we wanted to do as a team, there was minimal input from one of the team members and borderline nothing from the other. I believe this was caused by the desire from both of the other two members for their to be a dedicated team leader, combined with my reluctance to be team lead. I was recovering from personal issues so I was on the back foot and not as willing to drive the project as I normally would but that does not excuse the complete lack of communication from the other team members. Moving forward I plan to implement a contact standard for projects. Each team and project is different, but if I push the team to work together to agree on; Contact method. Weekly team cowork hours. Daily check ins. This will hopefully avoid the pit of failure to communicate that this project fell into.
There was only a single document to attempt to organise this project. Not only was this ineffective but directly hampering, as no one updated their sections as they worked, this combined with the communication issues resulted in confronting work, this negatively impacted everyone. I believe this was caused by a combination of no direct team lead, and no one actually caring enough to try, myself included. This is not a work environment where team members actively want to work in a team or keep their jobs. In my experience with student projects, students will not work unless they are motivated to do so, this also includes myself. Moving forward I would like to make sure that everyone in the team is onboard and motivated to work on projects before we commence the division of work. To do this I will actively work towards making sure team projects have at least one exiting element for each member involved. This combined with a agreed upon contact standard should hopefully build a strong foundation for future group projects.