BattleGear Engine

Over the course of this semester I think most of the assignments have been good 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.

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.