• entries
32
0
• views
2940

This is my Game dev blog for Fraud simulator! Let's make a game together!

## Refactor and Polish

This week has been has just been refactoring and cleaning up the code, finding more efficient ways to do things. All the bugs I've found I've crushed except one. For some reason if you try to build a building without the necessary resources, the text is not displaying that there's not enough resources. I've tried to trace it but can't see from a surface level detection. My first hard bug. I'll have to do some deep diving, but for now the behavior is correct...the building isn't being created. Just something with not displaying the text. I've ripped out my entire research system. The display and the data model. I've come up with a new idea. We're going to hunt and find collectible items, and slot them into slots on a research screen. The first research I have is the Storage building, researching a way to store resources. It's not game breaking or anything, but I was messing with some of the polish for the images and came up with this (Mind the placeholder art. It will likely be some sort of cube with shaders in the future): As the Macguffin gets closer to it's storage slot, it starts to shake, and then we will have a slow hum start to build up as the object gets closer and closer, with some effects and shaders when we've slotted the item in the research slot. This act of putting the storage macguffin into the slot unlocks the storage building, and that works fine. As for the refactor, I've decided that my most likely best course of action now is to have a different class for every dialogue and research in the game. I've tried to come up with ways to have a generic research or dialogue class that somehow knows what it's supposed to unlock. But I need custom behavior for pretty much every dialogue unlock and research unlock, that I've just gone with a separate class for each one. Will that mean I'll have 100 files? Yeah probably, but I can't think of any other way to deal with it right now. Plus, this allows me to unload all the strings of dialogue from memory once they're been read, which is nice I guess. Either way, we are moving on. I now have the entire beginning of the game scripted out, with each building being unlocked by actions and dialogue, and the storage building being unlocked through research. Next step is to code up humans and begin to work on that system. I will also work more on my research screen. I really like this idea of having slots and putting items we find for research, instead of just clicking a button. There's a lot to polish there.

## Communicator up and running

Hey all, I just got my communicator working. It's not glamorous art, but it's good placeholder for now. I have 4 counselor robots for the 4 pillars of the game: Build, Navigation, Research, and Military. The communicator blinks a button when we queue up a dialogue. The screen will then fade to the dialogue screen, where we display the character portrait, and run through the dialogue. Lots of placeholder art. We run through the dialogue, we have lots of choices in the bottom portion of the screen when we get to options, and when it's done, we go back to the last screen we are on. The DialogueDB keeps a dictionary of all the dialogue in the game, and we send it an enum to pop out the dialogue. The dialogue is queued with the respective counselor button, so if we get 3 messages at once, we will run through the dialogue when the player wants to deal with the messages based on which one came first. If there's more dialogue, the communicator will pop back up and the player can choose to run through the next dialogue. So the next part is something I've spent all week trying to figure out how to handle. How does the game know when there is dialogue? I've thought alot about the observer pattern, but how do I hook up the observer pattern all throughout my code? I want dialogue to trigger when certain events happen. I want dialogue to trigger when you max out your resource stores and lose material. I want dialogue to trigger for ANYTHING. So how do I have my code listen in throughout without using monobehaviors and also not violating SOLID principles or the state of objects or anything that could possibly go wrong? I came up with an idea to have a DialogueTrigger class. This is something I think I'm willing to sacrifice some SRP by having these triggers inside the classes of my Colony Map, or map tiles. For instance, if we max out our storage, and we are now not being inefficient, we will call the dialogue trigger class. Inside the trigger, it can count down, or if it's just an event, it will trigger the event. This will send a message to our dialogue database to trigger a dialogue, and then my dialogue system handles it from there. So I can have these "portals" with dialogue triggers. The code doesn't know what the trigger is, it just sees a trigger and calls it. The class itself decides when to send the dialogue. I really can't think of anymore elegant solution, so this is what I will be going with for now. Visual Studio is actually pretty good about keeping tabs on when these dialogue triggers are called from, so if I need to remove them, I'll have an easy reference back to them. So the first step to game flow is to get these dialogue triggers working, which honestly shouldn't be hard, and then start polishing the game flow from start to finish...what do I want the player to see or do? This will be the next step to getting a playable prototype to start running it by some gamedev forums.

## Unity Combat System in place

Hello World! This weekend met the completion of a goal I thought might take a month or so. I used Unity's ECS system to get about 10k enemies march towards the center of my map, and I had buildings created that could fire projectiles at them and kill them, throwing them away from the projectile. It has a lot of room for improvement, but it was really cool nonetheless. The turret I made is actually hybrid ECS. It uses the same Object oriented framework I have for the rest of the buildings, but I discovered I can just make an entity inside my original classes. So while the combat ECS systems are in different files, the Turret Building that I created, that I can easily inherit and put into my code, can create and destroy a single Turret Entity that my other combat systems are waiting for. So if the building goes offline, it can destroy the entity, and if it's online, it resets the Entity. And then it can check the entity to see if it fired, or let it know it can fire. Easy stuff. The Combat System is seamlessly added into my already existing framework, and I haven't seen any bugs. What I do need to do, is configure the FindTarget algorithm so it doesn't have to go through every single enemy...have some kind of quadrant system that it tests to see if there are enemies in range if they're in a nearby quadrant. But it's currently running at 100 frames per second as it is, so we will optimize in a future update. The Green Dots are the entities with a simple green texture mesh. The black hex is my turret building firing projectiles at the enemies. So with this system in place, what I really need to do is just start filling the databases with stuff to do. I need a story, I need dialogue, I need plot devices, and I need research in order to get to those places. The first thing I need is characters. I'm planning on having a "counselor" for each of the systems I have in place, so 4 counselors, with varying personalities. Luckily, if I'm strong in anything, it is writing. I'm going to make a system where I can pause the game and have characters converse...this is actually only important in big events, like the beginning of the game, and when something important is happening that can kill the player. So with this in place, we then need to define what the research tree will look like. My process will be to see what I need, and make a research for it. For the first few researches, it'll only take time, and to fill this time I want to have dialogue with the characters in order to explain what is happening. Why are we here, what is the plan, how are we going to accomplish our goals. This will all change as the game goes on and all the events start to take place, but I want to get a sense of immersion. We do this by letting the player explore. So that's next up on the agenda...begin to piece together these systems I've built.

## Research Screen Complete

I honestly thought this would take me all weekend. But here we are. New button the tool bar. Research! Not much to look at the moment. We have faded buttons for research that is not unlocked, and we have buttons for available research. This is clearly not going to be the researchs in the game, this is simply for testing. These buttons are hooked up to a database and enum that fills the buttons with whatever is in the database. I don't really want to spend the time to have it dynamically create the positions of the buttons, since I don't think it needs to be randomized or something...the research screen will likely be the same everytime. However, the order of the buttons in Unity will be the same, which I can use to fill the correct links to the correct research. So, what happens when we click a button? The button fades and is not interactable, and a timer starts. The button actually sends a command to the data layer to handle the command, which is to switch research to whatever research I send down to the data layer. It then sends the research for my display to listen to, and on update it watches the time to unlock...what happens when the timer runs out? The next research unlocks, and the Fire button is now permanently disabled. Awesome! The timer also continues when on other screens, since the data layer isn't apart of the display layer, and I can set the display layer to inactive when it's not needed. So to polish this, we would need a tooltip to see requirements of research, maybe hints as to where to go to unlock research and so forth, and definitely things like multiple researches unlocked by a node or one node unlocking multiple researches...I want to section research into 4 categories of the 4 systems in the game (build, navigation, research, and combat). And we can also allow the player to scroll around and view the research tree, zoom out, so forth. But right now this works perfectly. I can change the research quickly, and none of the display changes the state of any of the research...it simply sends a command down to the data to ask them to switch, and it makes sure it is a valid command. So we're onto the last system. Combat. In this, I wanted to play around with Unity's ECS system, see what shakes out. I will need a new building of a turret, to defend our colony. I expect this to take awhile, since I've never used ECS, so sounds like fun. Stay tuned!

## Still alive, still deving

Hi All, It's been awhile, but progress has been moving forward. My navigation screen is complete: I wanted to try and do something different than just make every square a different object like I did with the hexes. For this screen, it's all just one big object, and when you click on a square, it will highlight it, and then output the grid coordinates as a string: Part of what you are going to do with this screen is to explore the planet. The planet can be different sizes and will automatically adjust size and get the grids working:   Pretty cool. We can also send drones out to the squares...Right now that doesn't do anything, but I have it hooked up to a database that I can start to fill that it can retrieve, whether its resources, tech, or plot devices. If you attempt to send drones when you have none built, you get an error message. But once you have drones built, you can send out as many as you want. This can easily be expanded to add different terrains or searches for resources.   As for the build screen, we've updated it a little bit: I've shoved the building buttons under "Build", and there's a check to see which buildings are unlocked, which then immediately adds it to the list of options. We have a stats Display for each of the buildings that listens in on a building and displays their time to produce resources, and also their next maintenance cycle which will drain resources. This all needs balancing and the amounts I have right now are just for testing, but it works. The number at the bottom is the amount of drones available to send off, I'll be moving that somewhere else. And the explore button takes us to the nav map. You can also shut down buildings with the "online" button, and the little green light turns off on each of the buildings. They also automatically shut off when you are out of resources. So that's where we are at, I'm almost done with the research screen and data model, which is pretty simple, and then from there we can start doing the military side. I want enemies coming from all directions, so that there is an actual downside to building too many buildings...your turrets can't cover all your sides and they will be expensive. I'm also to the point where I need to start polishing art assets and sound, and I doubt I will be able to do that myself. I've tried. So I will likely start hiring someone to produce those for me, so stay tuned. My goal is to have a great main menu and character portraits for the characters. I want the beginning to be heavily scripted and then slowly let the player go as they unlock the explore and research options.

## Coding a Mission System

I finished a dialogue system so that it will take any number of dialogue sentences that require a button press to move to the next sentence, then can handle any number of dialogue options from that choice. The map can loop on nodes and really go anywhere, along with code to run once the dialogue finishes.   Having set that up, I wanted to work on a mission manager. I wanted this to be completely divorced from my other managers and just listen in on the other systems. It would, unfortunately, need to know what's out there, but that's a simple compromise for now until I can learn to pass events and delegates through methods. The mission manager is nice. For now I have two types of missions. The first is to stockpile resources, the other is to build a number of a certain building. I quickly discovered some powerful features of properties. I realized that I did not need to define a delegate for every event. I defined one delegate, which was resource changed, that passed an integer. I then declared an event for each resource, then had a a small method to invoke the event. But here's the cool part. I put this method inside the setter of the resource integer. So now my mission manager checks which resource it needs to listen to, and then registers for the resources event to a simple method that updates the mission text. So everytime the resource count is changed, we automatically update the on screen mission text that the player sees. No update needed. I really like these types of solutions. The mission system is ready, the dialogue system is ready, and the building system is ready. Time to polish with animations and fill our databases with assets.

## Creating a dialogue system

This week I wanted to start working on story elements. I decided to create a system for any game I make where I can easily navigate a dialogue tree...and one that is dynamic and loops on itself as well. I just finished it. It does not look pretty at the moment, but the next step will be polishing it. We have 5 classes for this and a struct, although I think one of them might be redundant. Firstly is the dialogue manager. This will be listening in on the game and load the dialogue system when it is activated. The screen will go dark. It will then load the dialogue from the dialogue database class. Once loaded, it calls a method to load the next text response. The Response is a struct that contains the NPC Name and the text. If this Queue has text, we will load the text objects on the screen with the name and the portrait of the NPC and what they said...there will then be a continue button to move to the next Response in the queue. Once the queue is out, we go through and instantiate our options. This is dynamic and created in code, with listeners loaded in code. The Options area is a grid that will line up all the buttons for me, and it can handle however many I want to give it. I need to have it resize things as the options grow, but for now it can handle 9 options without any issues on different screen sizes. Once a button is clicked, it cleans up all the listeners on the buttons and gets rid of the buttons. Later, we can implement a spawning pool here so that we don't constantly destroy game objects. Each button also will update the dialogue map on which node it gets sent to. The dialogue manager then loads up the responses from the Queue of the new node, and we continue on. So now with this sytem, the only thing I need to do to add dialogue is to place it all in the database, and then add a listener for this dialogue trigger in the game somewhere. Super cool stuff. Next time I will have animations polished, and have the UI look a little better to be able to show it off. I'm pretty happy with it.

## A bit of a sidestep

So, normally I tell myself "focus focus focus" and work on this game I'm making. But I'm starting to think I bit off more than I can chew. Which, from reading other people's blogs, is pretty normal. This project is extremely ambitious, and I'm getting burnt out constantly. I keep getting ideas for other things. So I decided to let myself work on something that I think I can easily accomplish, as long as it works on a skillset I don't have...specifically working on art and events/delegates in C#. So, for the past two days, I created something I'm pretty proud of. One of my favorite games as a kid was a game called "Alien Legacy." It was created in 1994 and it did not do well. It was very buggy and the UI is very obtuse. The mechanics of the game are hard to figure out, and don't always work the way you expect, specifically orbital mechancs. It's also very hard. It didn't do well. But I absolutely love it. It's hard sci-fi, with your ship arriving in a new solar system with the crew waking from cold storage, finding out the earth was wiped out by our xenophobic neighbors.  You are all that is left of humanity. You have a sister ship that should have arrived in the solar system before you, but there's no contact. You begin colonizing the planets, discovering the fate of sister ship and running into all kinds of humanity ending threats. You can build as many colonies as you want, explore the planets of the galaxy, limited by fuel capacity and time. You create robots and slowly bring people out of cold storage until you reach your max. If you don't do things fast enough, cold storage malfunctions and you lose half your crew. It's really a great game if you can get past the bugs, and it's abandonware. So what I wanted to do was replicate the base building side of the game.   Here is what we start with...a simple airport. We have 4 buildings to create. Storage isn't apart of Alien Legacy. Clicking on any of the buttons on the bottom highlights areas that we can build...Alien Legacy uses a square grid, but I wanted to mess around with a hex grid. As we build, the grid grows. I don't create the entire map, I create new hexes as we expand, which means we can build infinite games as long as things don't crash from overflow. Construction takes real time, and when they're done they will sprite swap to the regular sprite. We can also bulldoze, and it will sprite swap back to the construction swap and then remove themselves back to the none sprite.  And lastly, I have green floating text that spawns and fades out and rises everytime the inventories increment. This only took me a handful of hours to make, and I love it. This base game I have here can go in so many directions. The inventory is correctly incrementing, I just, ya know, need to do stuff with it. So I'm really happy to be able to use these skills, especially since everything is based on the observer pattern, where the data model for everything is separated from the display model. When the data model changes, it invokes an event, and everything subscribed to it will change. So even though I'm not working directly on Fraud Simulator, I'm still expanding my skills and enjoying the art of game making.

## Markets are done, moving to Service Companies

Huzzah! Not much to really show since everything happens in Debug.Logs and code, but markets are done. So what can retail agents do? Right now they can choose between restaurants or super markets...both of them have a different lists of goods. The restaurants will have the more complex good types that cost more, and supermarkets will have cheaper goods. Eventually I will have retail agents responding to market conditions and possibly switch Licenses. That's for another time. When a market has a positive inventory, they will put themselves available to the market. A list will be updated every day in the game that gets the total market share of all the companies, and creates a random list of markets based on that market share. This only happens once per day, and before agents start choosing markets to eat at. If you have 40% market share, you will have a 40% chance of being picked. An agent will come and pick a market, and then either decide on picking the most popular good  available at the market, or the cheapest. Once decided, the market will feed the consumer and exchange cash. The consumer's hunger goes up based on the good and how well the employees are at their job. If a market successfully feeds a customer, their market share goes up, so being good can snowball. Since this is percentage based on the market share, your market share will go up quickly, but as time goes on, since the change is always a fixed amount, that fixed amount will increase percentage wise less and less. Everyone starts with an integer of 1-10, and it will go up 1 each success. So increase of 10 to 11 is a 10% increase, but a 100 to 101 is a 1% increase.   Anyways, I've unit tested it and each part works, and I'm happy with it for now. The player will have the option of just going wherever they want. For now though, we move on to the last type of company. Service Companies. Service Companies will probably be the meat of the game when all the systems are in place. They aren't going to interact with Goods. They are going to provide services to companies and to the player. Most markets are usually service based. To get them online and working with my company, I really just want utilities up and running. As companies hire more employees, they will need more utilities or productivity will be hindered.  We will need an ISP utilities which I'm bundling with electricity. They will need IT services to keep everything running. Janitorial services. Mechanics. There will be builders that create more real estate for companies to open more businesses. I will have goods that aren't for eating, but required for construction. Legal services for when I implement a justice system. Accounting services for companies to get their financials straight. Customer service to make sure we don't lose customers. Marketing companies to increase market penetration and market share. Sales forces to get contracts cheaply. Service companies require experts, and that's basically it. I will eventually put supplies in the game like pens and pencils, but keep it abstract with just a "supplies" account on the ledger, and periodically decrement it. Productivity will suffer if the supplies account isn't kept up. I have the code architecture in place for service companies, so it should be a simple manner of creating the Licenses and the Job Types for them, and then getting Service Contracts up for their services. Penalize companies if they have a certain number of employees and they don't have required services. Hopefully have that before the weekend is done. But the goods and contracts are all interacting and moving. Once I have Service companies up I will work on how the player is going to interact with all of this, and start polishing the UI and art to get it ready for Alpha!

## Refactoring the Economy

The data model merge took place. I broke the code and then rebuilt it. This is actually more fun than I imagined. So, now I'm working on refactoring the market code to allow it to be extensible as I add in company behavior. All the market decisions were being handled inside the market controller class before, but now with more knowledge of C#, I'm moving it to basically a "flow" controller. The main loop in the game turn is basically 4 for loops...beginning of the day, middle of the day, end of the day, and finalize. The beginning of the day I build up the lists that I need...which markets are available for consumers to eat from? Who needs employees? Who needs a job? The middle of the day is where the player's actions gets executed and all the contracts get executed. The UI will collect player actions and here we inject them into the economy. The Job contracts will perform their tasks, pay their employees, remove themselves if they've expired, and send goods to other companies based on the terms of the contracts. Also we randomize the order of the lists so that the same agent doesn't get first mover advantage everyday. The end of the day is when we execute commands for the AI. Companies hire employees, get contracts, decide on new states for the AI. Finalize is where the economy goes over everything and updates its average market prices and market shares based on the actions of the day. So my old market code was 500 lines long. Now I'm going to have the actual companies decide what they need to do. Retail companies and manufacturers need to do different things, so I'll have an interface for them that basically say "BeginningOfDay()" but they will be done differently. Interfaces are clean and nice for this. I also ran into an issue when I was merging data models. I have two interfaces, IAgent, and IEmployee, that are both on the ConsumerAgent class. But if I make an IAgent, it doesn't have access to the IEmployee methods. I started just copying the methods I needed to the IAgent interface, but then I realized I was violating the DRY principle (Don't repeat yourself). I discovered that IAgent can actually implement IEmployee interface, which is hilarious to me. Interfaces are so nice. I also ran into another issue with interfaces. Production Agents and Retail Agents both have an ICompany interface, which means they both implement a "HireEmployee" method. But it's the exact same method. I'm violating DRY principle by just copy pasting the code. Then I realized I could use both an abstract class Company AND implement interfaces. Mind blown. Seriously. So now when we have financial statements and accounts like "cashOnHand", I don't have to keep copy pasting that property to all these classes. So, pretty excited to get this code refactored and working. No pictures for awhile since this is all just code, but hopefully show some different employees and companies off as I get them off the ground and rolling.

## Solving the tree problem

So, I think I've designed a possible solution to my tree problem. First off, I really like C#. My background when I was young was C++, and learning data structures and pointers was interesting. I did really well with assembly language, and enjoyed those kind of recursive things. But I never kept up with coding, and now here I am much older and way behind. Object oriented programming had just becoming a thing back when I was coding, and until a few months ago I had no idea what it was. I started doing some coding with javascript a few years ago, and let me tell you, that's one of the worst languages to start in. Now that I know what a strongly typed language is, having the compiler interpret what you want to do leads to so many obscure bugs it's crazy. With C#, if I make an error, I know exactly where the problem is most of the time. I haven't really run into any huge logic bugs I couldn't track down. One of my favorite parts of C# is that practically everything is a reference. Keeping track of pointers in C++ was a pain, but C# does it so naturally and intuitively. I absolutely love it. So now we get to the solution part. I don't know if C++ had events and delegates back when I was coding, but this is a dream. Because of how they work, I don't even care about animations or sounds in the game, because I know I can just go find the method that I want a sound to play and throw in an event code and plug it into my audio, or animation. It makes things so painless. We have quite a few objects interacting with this hierarchy tree. First off, we have the employee objects themselves, that hold all the data I need to interact with the economy. Salary, jobtype, skills, hunger, cash, so forth. When we load the screen, we have to spawn an "Employee Card", which is the visual layer for the user. The card doesn't care what the data is, it just has a "data container" for the employee...or a pointer. The Employee card is draggable. When they don't have a job assigned, their just idle, and sit on the bottom panel. There's really only two things you can do with an employee card on the hierarchy screen: Drag the card to an employee slot or the idle panel. Right now, I can drag it anywhere, but I'll cut off that hippie golbydygook user freedom later. The next object we have going on is the employee slot, and I think this is where most of the logic is going to happen. I don't the card really cares what happens to it or where it goes. But the employee slot DOES, because on the display, I want you to be able to grow the tree...in order to do that we need empty slots spawned...and we're going to have to do it for each manager. So if the CEO has two managers, and those managers have 4 employees each, then we're going to need the CEO to have an empty manager slot next to the two managers so you can hire a new manager, and then each manager will have an extra employee slot in order to grow their trees. But, if I drag someone in, we're going to need to spawn another empty employee slot next to it. And it has to know where to spawn. in the opposite vein, if I drag out an employee or manager, then they're going to have to despawn the empty employee slot, since there would be two, and I only want 1. And if you drag out a manager, I want the employees to reattach themselves to a different manager. On top of all that, I currently display things by spawning all the objects. So when I do I refresh the display? I also don't think it's wise to continuously spawn and despawn all these objects everytime something moves slightly. So for the display, I'm going to be doing some spawning pools. The cards and slots and lines aren't unique, and this will help performance. I'll need 3 different spawning pools. The card slots will have event listeners on them, waiting for the employee that they're holding moves. If we drag an employee to them, then we register our delegates and then attach them and then have that slot's manager spawn a new empty slot. I think all of this will work pretty well. I can think of a few edge cases off the top of my head, but I can get most of this up and running this weekend hopefully. I think making the tree itself will likely be the hardest part of the hierarchy screen.

## Recursive thinking

Recursive programming is tough, but oh so rewarding. After 2 days of trying to figure out this thing is going to take shape, I've done it: A hierarchy tree. It's quite dynamic too. It can have lopsided trees and uneven trees. But, what it can't have is managers without employees. It's assumed that if there's a manager, it has an employee. How it works is that while I'm running through the employee roster to get all the idle employees to my idle panel, I count how many bottom nodes there are going to be. Using that, I enqueue up an offset counter, and each time I hit the bottom, I dequeue the list and multiply that by my width of the card. My recursive model races to the bottom first, and then once we've placed the subordinates, the manager just averages their x positions and places himself up. I keep track of how high we are in the tree as we step in and out of our recursive function, and multiply the height counter by the height of the cards. This has been oh so satisfying to code. Now to figure out how to add and delete branches.

## One small step in algorithms

So, from my last update, I got most of it working. Using 3 interfaces, I have the CEO of a company being created, and all the idle employees being placed into the idle panel, along with an empty slot being spawned in order to start getting people managed and working. Which is all fine and good. I'm pretty happy with how the concept worked out. I had trouble working with interfaces for the first time, because I didn't realize what properties were. When I tried to put a field into an interface, it would kick it back. So I thought I couldn't have guaranteed fields for interfaces. I tried to make get methods, but as I began to work on the display level of the code, it was causing all kinds of problems. I finally looked it up online if I could guarantee fields, and discovered properties and get/setters. I don't really understand what the difference between a field and a property is, as in why you would have fields at all if there are properties in the language, but here we are. As soon as I put properties into my interfaces, the display code just fell out easily. So, now I'm at a crossroads. How does the tree know where to place all these card holders onto the board? Clearly we can't have them stacked on top of each other. How does it detect to place an empty? Where does it place it? What if I pull a card out of a slot...does it disappear? Do the other slots need to be reordered? I want to add managers to managers, increasing the tree. Where does it place these cards? Do we start at the bottom or the top? This is going to require math, unfortunately. I'm going to have to develop some algorithms on detecting which tier of the tree we are at, how many items are in the tree at that tier level, and so forth. So for now, at a wall. Time to research and figure out how it needs to be displayed.