Buildr.io

Cool Story

Inspiration

Due to the high demand and low supply for high end computers, it's often difficult to play games that require intensive computation. That's why our group decided to make a game that's easy to learn, able to run on any device, and is multiplayer to allow for all friends to have fun online! After seeing the Ubisoft API, which is lighter than most Game engines like Unity or Unreal, we found that a game centralized around the collection of resources and building of enclosures sounded simple and entertaining.

What it does

Buildr.io is very simple. You start off as a normal player with zero resources. To get stronger, you need to hit resources that are spread all over the map. Just like in real life, resources do not last forever, so mine while you can! Beware though, because there are other players in the game as well! They will try to steal your resources by hurting you, or alternatively, they try to trap you with buildings! Of course, you can retaliate as well! Each player killed, resource mined, and building placed will result in your position on the leaderboard to increase.

Zombie mechanic:

How we built it

We used the Ubisoft API as the Game Engine which has a basic Entity-Component system. In order to network the game, we implemented a low level networking system that sends JSON (ironically) to calculate the logic between players.

Challenges we ran into

Networking was harder than we expected because everything was implemented at a low level. There were many issues sending information between the client and the server. There was also a slight learning curve with the Ubisoft API because many things needed to be implemented manually.

Accomplishments that we're proud of

Networking

Using native c++ sockets a server client relationship was setup. Messages were sent using json and allowed multiple people to play the game at once.

Lerp

Interpolation in the camera movement and player movement, so the games runs smooth.

Lazy loading of Entities

Due to so much traffic, the amount of resources, and the size of our map, it was very important to render only the things we needed. To only render the entities that were displayed in the camera view, we went into the API and modified it so that components and entities alike are only rendered if their boxes collide with each other.

Mouse Position

Calculating the mouse position required some hoops to be jumped through because the position of the mouse was relative to the whole screen rather than the window. We were able to find a solution expanding on the ubisoft framework.

Spawner and Resource Manager

We had entities that managed the smaller, but more abundant classes. For example, resources were managed in an OOP manner, along with spawner logic for the creation of buildings.

What we learned

We learned a lot about implementing low level functions and making small improvements, which we all take for granted in production level Game engines. This has definitely taught us to pay more attention to key details and implementation.