#cityfuture

Hello guys,

These past couple of weeks I decided to dedicate entirely to the road system. And that is what I have being doing during my spare time. I quickly discovered that the road system is the single most complicated and time consuming system in the game. A procedural road will need code to create the mesh on the fly, rotate the road towards the mouse, modify the terrain below the road so it stays flat and nice, create nodes to divide the roads so other roads can attach to it, and create a list containing the relationship between all these nodes.

Last week I completed the basic mesh creation and rotation, this week I focused on the node relationship list alone because it is a critical part of the system. Despite of the hard work put into it, I'm not done. Let me explain better what is going on.

The image above shows the basic structure of the doubly-linked list that I'm implementing in order for the nodes to know which node precedes and follows themselves.

Each square on the image is a node that contain exactly another set of the same structure. For instance, if I have the node "Node.Previous" I can get the "Node.Next" by saying "Node.Previous.Next.Next". The first next referencing the center node, and the second next referencing the node after the center node. That is how a linked list works, it is very confusing in the begging but after some practice it gets a bit more manageable.

Right now, I have almost everything working, including when adding T intersections and 4 way intersections. The only problem is that when I have two separate roads that don't share any nodes, the list still points one end of one road to the beginning of the second road, which is wrong since both roads are not connected.

After I figure this out, I should be all set to start messing with dividing roads when a T / 4 way intersection happens where there are no nodes. Ex: A have a straight road and then I build another road crossing the first one in the middle, a node should be created at the intersection and all the relationships should set correctly.

I almost forgot, in the process of creating the node list, I solved a few bugs such as some null refs. and roads inclining when they shouldn't.

This is it for this week, if you like my work let me know in the comments section. 

If you want to contribute to the project, go ahead and check the project's Github page.

Roads, and more roads. This is what I worked on the entire week. Despite having made great progress on the procedural road system, I am stuck at rotating the pieces of roads so they always face up, see the picture below: 

Don't mind the graphics, they are placeholders only.

No matter the method I use, these darn quaternions never align! To store the nodes of the roads which are the pink cubes that allows for connections between sections, I have implemented a doubly-linked list, this way each node knows who is the next and previous nodes, allowing much more control on what we can do with roads such as pathfinding and more.

I hope you stay tuned for more, because I will not rest until I get this right.

This week I don't have much to show since I had to study and do homework all week long, including Saturday (I have class on Sunday, I now!).

Despite not having time, I could complete the streets structure, which includes all street classes, helpers, and factory. I haven't implemented any particular method of the streets yet since they are very logic heavy, and that would take me a lot of time that I don't have.

I also went ahead and implemented a camera mouse pan / zoom class which lets me navigate through the scenery and be able to see better what is going on around.

On week 4 I will continue working on the streets, trying to implement procedural roads, the keyword is trying since I've never done that before. But I think I will be able to accomplish that after some hours of studying how it works.

This was a short update for week 3, hopefully next week I will have more things to talk about.

This week I went ahead and jumped into making the agent classes that are composed by Citizens and Vehicles. My initial plan of making a base interface didn't work since I had to extend Monobehavior, this lead me to make it similar to the building structure, which isn't a bad idea to make everything uniform.

Agents are much more complex than buildings, they have many more behaviors and properties that I have to count for such as if they are employed, or if a kid is in school, or even if a person is homeless. I opted to use strategy pattern on some of these properties such as employment and students, because, this way I can have a employed class with information about the person that is employed, the building where they work and the salary they receive.

I also created the agentFactory class which takes care of making new agents on demand. The following Diagram describes how it works:

link

After all of that was done, I started creating the streets system. Although, I don't have a concrete picture in my head of how it is going to work, I started laying the basic enums defining the types and directions of streets, including one way or two way streets.

I have high hopes for next week, streets will be fun to work with, and I do intend to implement the procedural street tool if time allows me.

In the first week of the project I have decided to write a few classes to get a feel for the difficulty of the project. That is when I found my first wall.

Problem 1

In unity, if you inherit from Monobehavior (make the class a component) you can't initialize the class with the "new" keyword. So I had to look for a solution for that, and what I came up with would not work with the design that I previously had. After a few hours of research, I came to the conclusion that I needed to use the fearsome term "Design Patterns".

I have never worked nor had any idea on what a "Design Pattern" looked like, the only thing I knew is that it was used to define a structure to the classes and interfaces of the project.

After watching and reading a few lessons, I started getting the overall idea behind the different design patterns, more specifically: strategy, observer, factory and singleton patterns. Reading a bit more on each one I decided that the best design pattern to use in the current phase of my project was the factory pattern with a few touches of strategy pattern here and there, since it allows me to have a single class controlling what types of buildings and agents would be created. Instead of having to call multiple methods, now I have one "makeBuilding()" method that I can instantiate any building in the game.

After finished the Building interface and implemented a few classes, I could finally test it in the game. For my surprise it worked like a charm, now I can simply call "makeBuilding(buildingClass.residential)" and it will do just that. Wonderful! Now I'm just missing the position and checking if it was an available position (not occupied), but I don't think that would be a major task.

3rd Day

On the 3rd day on development I decided to start making the agents (people and vehicles) interface. I quickly noticed that the agents would have a much more complex structure compared to the buildings. So I paused the coding and went ahead to a new subject that I also had never worked with before: UML Diagrams.

UML Class Diagram

Looking for a way to visualize the structure and how everything worked together, I went to Youtube and a few websites and looked for tuturials on UML Class Diagrams. after a couple hours I felt ready to try and design my first diagram.

link

I am still having trouble with the different arrow heads symbols and associations but for now it will do the job. There are probably major flaws on the diagram, but again, this is the first time i'm dealing with design patterns and UML.

This is about everything I could accomplish this week between my college classes and homework. Next week I will probably have the agents interface done and will be starting with the interaction between agents and buildings, so keep checking back for more updates.