I’ve grown very attached to the many possibilities of the ListView control from the Windows Forms library in .NET and decided to try and make something similar in Unity using the standard GUI system.
So, for this week I got a lot of the UI done, which is obviously using the Unity GUI system. Unity Technologies recently announced a switch to a better GUI system in the upcoming release, so it’s going to suck pretty hard redoing the entire GUI when the time comes, but I’m sure it’ll be worth it.
I also finally implemented some of the development cycle. You can now choose what type of software you want to release, how much you want to focus on innovation, stability and usability, pick a team to design it, then promote it to alpha and release it when its done.
In the final version there will be delays at the end of the alpha, depending on how competent your employees are, a beta phase of fixing as many of the bugs as possible and after release you will have to take care of marketing and assign a team to support customers and fix bugs, or get a bad reputation. All of these steps will be affected by many factors, which includes how good your employees are and how well they are doing.
When you release a product, its quality, compared to similar items on the market, will have an effect on how well it sells. So, if you release a 3D modeling application right as another company has released a much better one, yours will sell less, but you can use it on your next game without having to buy a license. I use a large amount of variables when calculating how much your product will sell each month and how much popularity it generates.
Finally, I simulated winter. It seems like a good way to illustrate time passing, though the snow texture and particle effect could use a loving hand.
For Software Inc. I decided to learn a bit about implementing AI, so I read a couple of paragraphs, got impatient and started coding stuff, because I am not smart and, apparently, I like messing things up I could’ve otherwise avoided by just studying a bit.
Normally when I implement AI I end up with a 1000 lines of IF-THEN-ELSE and switch case statements. Behavior trees seemed like a cool alternative, so I went looking for implementations, because when it comes to programming, NEVER reinvent the wheel, so after seeing something to the tune of “200$”, I decided to reinvent the wheel… Poorly… And share it with you, of course, for free(Requires .NET 4.5, only works with C# files, simply select a cs file and the program will generate two new partial classes, one of which (class.impl.cs) contains the methods you need to fill in. It will not overwrite previous state methods when you export on top of it. BACKUP BEFORE USING).
So I made a small application in which I can visually draw states and connect them, and when I am done, I simply choose a C# file with my class in and it will generate all the method stubs and the code to generate the behavior tree, as seen in the picture below.
For this week of development I had a lot to implement to get to a point where I wasn’t just going to abandon the project. I expanded the AI of the employees (more on that later), I implemented stuff like hunger, energy and satisfaction. I also strayed from the blocky look by making the walls thin, which required making corner walls and dealing with all sorts of z-fighting issues, which eventually culminated in a convoluted algorithm that rebuilds all rooms on a floor when you change something, and merges all the walls, windows and doors in to one big mesh.
I also implemented meetings. I work as a student programmer and we have meetings once a week, and they’re always very interesting, I learn something new and I get motivated. I wanted to recreate that in Software Inc. by giving boosts for a team if they’re in a meeting, which requires a team leader setting them up, and tables and chairs to sit in.
It took me some time to decide how tables and chairs should be implemented. I ended up with a solution which determines which tables are touching and groups them together. Chairs can only be added to tables and will be added to the group the table belongs to and when a leader wants to use a table group, the room finds the largest available one. And finally I started modelling furniture, as seen below, I am NOT a 3D modeller.
I also felt like I had to implement the ability to choose working hours for each team individually so the game doesn’t get boring between 4 PM and 8 AM.
Software Inc., as you can imagine by looking at the pictures, is a grid based game. As such, it was really easy to decide on using a gridbased pathfinding algorithm. My problem was that I wanted multiple floors and if I just made a giant grid for each floor, if I then wanted to go from one building on the fifth floor to another building on the tenth, I would have to do a lot of testing to see which floor led where while also navigating each floor.
My solution was to implement a layered pathfinding algorithm, which probably seems completely obvious to you, but bear with me. Instead of measuring how far away something is geometrically when using a pathfinding algorithm we can use any definition of distance that we desire, we might say, “What is the distance between happiness and cake?”, as long as we can figure out some way to actually measure that distance we can find the shortest path from A to B (it is direct in this case).
What I did was to ask: “What is shortest amount of doors/elevators to traverse to get from room A to room B?”, notice the distance is not in meters or feet, but in number of doors and elevators between room A and room B. Then, for each room I want to traverse to get from A to B, I ask: “What is the shortest distance from door A to door B?”, which I work out by giving every room its own little grid for the pathfinding algorithm. In the end, I append all the paths found in to one big path and call it a day. To make people avoid rooms I simply ask, before going through a door: “Does this room belong to a team, and if so, is it my team?”.
Both of these algorithms are implemented using A*, which I think is pretty neat.
To finish off, I make a giant invisible room on the ground floor that connects all rooms to the outside, because logic.
After more than 12 years of developing games in my spare time, I finally managed to stick to one project for longer than a couple of weeks and I really think it’s looking promising.
The kicker for me in actually keeping my motivation, I think, was having a large detailed todo-list of everything that needs to be done in order to make the game playable. I’ve tried this before, but I usually slack a lot in keeping it updated. I’ve found that dedicating some time for cleaning the list and elaborating on points has helped keep up the motivation and I always have an idea of what to do if I get bored. I really can’t overstate how important this has been and if you’re into game development, I recommend that you try always having clearly defined tasks waiting to be completed.
I’ve been thinking about creating this game for quite a while now. I first started developing a school tycoon game, but realized all the action happened once a year when the it was grading time, the rest of the time was spent waiting. I then tried developing a 2D version of what I am making now, but I got stumped on some technical issues. Then I had a sudden burst of inspiration for a pathfinding algorithm and it motivated me to start again in 3D.
I was also hugely inspired by Game Dev Tycoon and I felt there were so many possibilities to go more in-depth with the software tycoon game idea. With Software Inc., my goal is to go more in-depth when it comes to the development cycle, the buildings and staff management. I want you to not just push out virtual products to gain some points in a game, but also feel like there’s an entire ecosystem just below the surface, that you have to manage.
When these pictures were taken I had implemented rooms, doors, elevators and lamps to create buildings with. I also had an employee type person, who would turn up once a day to sit at a desk/box, to test the pathfinding algorithm.