BattleGear

Download Link at Bottom

--------------------------------------------

I am big into racing games and wanted to work on a battle heavy racing game, this was a fun little experiment to see how it would go in my own engine using the Vehicle Component system that I created previously. Overall I think I’ve done a pretty good job making decisions and reworking what is difficult to use in my own code over the course of the semester. It was very easy for me to create game logic on top of the systems I wrote and integrate new assets into my game as well. I spent most of my time on this project building the game structures and logic needed for it to work. Admittedly I probably made this game too fancy for what it needed to be and making it a networked game was definitely not a great decision in hindsight but I am very happy with how well it turned out all things considered.

Systems Use

In terms of using my own engine I think everything worked as expected and I didn’t have too much issue integrating it with my game. The real issue came from trying to network the movement of my vehicles. I realized that I don’t have a good way to re-sync some of the movement information easily when receiving a packet of information over the network. To properly re-sync the movement of vehicles I currently have to manually set each of the variables necessary for calculating speed and motion and to keep working on a game like this I would probably want a more intuitive way to recalculate values.

Working with my classmates’ code was also not too difficult. I added Yan’s Collision System and Roberto’s Networking System to my project and both in terms of use were fairly easy to understand and integrate into my game. 

Yans Collision System.

My main issues with the collision system were that it doesn’t support rotating collision boxes and that syncing the collision boxes to the rigidbodies of whatever gameobject I used had to be done manually. Using SetPosition and TrySetPosition in the collision component as well as changing movement variables on collision responses works, but requires a significant amount of reading through the collision system code to keep movement and collision in sync. There were multiple times that I had bugs pop up as a result of improper collision box syncing. 

On the positive side, the hooks for getting collision and overlap response were super easy to use and made the base level integration very easy outside of the elements mentioned above. I had some issues with figuring out the visual size of collision boxes in relation to my meshes but I was able to sync it with the placement of the car’s wheels so in my case it ended up not being too much of an issue.

Roberto’s Networking System

Networking was a much more difficult process to integrate but I think I had more issues with networking as a whole than I did with integrating the system itself. The setup was definitely more confusing than that of the collision system but going through Roberto’s tutorial section of the download page got me through most of it with some help from Roberto himself. The biggest issue I had was that there is currently no way for a non-host client to broadcast a message to the other clients without going through the host which increased the amount of data I had to send. Other than that I really only had issues with the actual logic of networking my game and resolving de-syncs. It’s very unoptimized but for 2 players through a wired connection it plays fairly stable.

Over the course of this semester I think most of the assignments have been practices in making decisions in terms of how code is structured without knowing for sure the “best” way to do it. I think the biggest thing I ended up spending time thinking about for most of the assignments was what I wanted to integrate into various areas of my code and how the transfer of data from one to another should look. I think the biggest advantage I had this semester was that on one or two occasions I went back to rework areas I had issues with along the way so when it came time to work on my system and the final game it was very easy to integrate everything I needed.

My biggest takeaway this semester was probably the advice that when designing things programmers have to make decisions between things like speed of execution and memory usage and that often you just have to choose one that you think makes the most sense for that situation and go with it until it needs to be fixed or changed. The practice in finding a starting point for certain structural decisions and making smart decisions along the way was very helpful for not only this class and my understanding of engine systems, but also adding gameplay systems and elements to the projects I work on in other engines. I also thought learning the basics of how to add new systems to an existing engine and project along with tools needed for asset imports was incredibly helpful to understand. Although the amount of time it takes to build a fully functional engine is enormous, it does make engines like Unreal and Unity seem more approachable in terms of how you would start to structure a piece of software that large and how others can add on to it without constant need for restructuring.

Semester Design Thoughts:

I’ve found that I prefer to do a lot of the underlying structure planning of my systems beforehand and have a solid plan going in on how I will start building it. There is always some level of creating the structure on the fly as well but if I have clear design goals and needs in mind I can at least plan out how I will start. In the process of planning a system I usually come up with a few key hooks and other helper functions in advance but I will generally create the api design as I go and need specific functionality. Its not always fully intentional but I generally don’t want to spend extra time implementing things I don’t need for base functionality especially when I don’t have much extra time to work on things.

I think I realized at some point this semester that “good design” is hard to see from a user standpoint and is so greatly affected by the circumstances in which you actually write the system. As a user of other people’s and my own systems all I feel when a system is well designed is that it feels like I’m not constantly fighting it to do things I want it to. It's really only obvious when I’m using a poorly designed system since it’s frustrating and often makes integrating its functionality difficult to do, but when a system is designed well there’s no real gratifying feeling of it being easy and understandable and consistent, there’s just the other work that it doesn’t get in the way of so the well designed system isn’t actually ever the focus. That being said I think good design is the easiest to describe as the design that lets it do what it needs to efficiently and consistently. Designing something well just means understanding the use cases and planning for them in a logical way. Something that is designed well when it was created can be designed poorly for someone trying to integrate it into a new piece of software later on because the original creator never knew it would be used that way. If the use cases are unknown then maybe designing things in a way that they are easily adaptable and expanded on later is the best choice. Either way this class has definitely taught me that there isn’t really a right answer to what good design looks like other than designing for the situation at hand.