class __declspec(dllexport) Callback

{

public:

Callback(const ActionFunc& func, std::string_view name, HINSTANCE* hProc = nullptr);

Callback();

template <class T, void (T::* TMethod)(Args...)>

static Callback from_method(T* object_ptr);

//Variables /////////////////////////////////////////////////////////////////////////////

// For member functions 

typedef void (*memberActionFuncStub)(void* mRecieverObj, Args...);

std::string mName; // Name used for unsubscribing and comparison

ActionFunc mFunction; // mFunction to call on event, for non member , non script callbacks

HINSTANCE* mHProc; // Address the script function comes from (if any)

void* mRecieverObj; // Member object, of any

memberActionFuncStub mMFuncPtr; // Packaged member function, if any

// Operators /////////////////////////////////////////////////////////////////////////

operator bool();

void operator()(Args... args) const;

     // Helper functions //////////////////////////////////////////////////////////////

template <class T, void (T::* TMethod)(Args...)> // Class, and member function pointer

static void memberFuncStub(void* object_ptr, Args... args); // Class pointer MFP is in, args for call

// ... Other helper functions ...

};

Jumping in and finding your role/ ways to contribute

In the beginning of the project, there were various specific types of programming roles to choose from, and while some teammates immediately took to things like graphics, AI, tools, and the like, but I wasn't quite sure which role I wanted to take. Since I knew this would be a great opportunity for learning, and potentially doing portfolio-level work, I wanted to find a specific industry role that I could get practice in, while also making sure I could contribute meaningfully. In the beginning, I ended up taking the role of the audio programmer, and it was both a distinct role, and helpful in moving the project forward. But, as I finished the needed audio work at certain times, I eventually just started picking out areas of the project that needed improvement, doing research on what could benefit the project (for example, research on events, which lead to my signals and slots event system), as well as talking with other disciplines, and my fellow programmers, about what may help us. While I can certainly group my contributions in categories like audio, production, and gameplay systems, in hindsight, I found that the most important part of my role during the project was that I was finding ways to move our project forward, regardless of how they I fit a specific role. For example, I may have taken the role of the audio programmer in the beginning, but we still needed a menu system, someone to implement the reload combo gameplay mechanic, and the like. Of course, some people on the team wanted certain tasks, and we needed to make sure tasks were distributed well, but with that in consideration, I found that there was still quite a lot to do. Being able to jump right in to move the project forward was something that helped me make meaningful contributions, even when I wasn't sure quite what my main role was. So, while I knew helping wherever was needed was common in my smaller team projects, it was useful to learn here that the same kind of wearing multiple hats can still be quite useful, even in larger teams.

Modular practices for gameplay and engine implementation

I had heard much about the benefits of implementing systems in a modular way before starting this project, and as I worked on and eventually used the systems the programming team and I created, I began to see for myself why modularity was so important. Making our component system easy to add new components to was excellent whenever I needed to add a new system for our entities to use, and that ease also encouraged decoupling logic into separate components, likely saving us additional bugs. Furthermore, every time we could find related functionality, and simplify it by creating a base class to derive from, it made that system much simpler to add and tweak, being able to update multiple systems through their shared base class. Modular implementations did sometimes take more time to plan and execute, and I can see knowing what to make modular, and what may not be useful to make modular, being important for implementing systems in a timely manner. But, when it did work, modularity was both a nice feeling for the person who developed it, and a life saver for the people that used/ added to it. For example, when I made my button function system modular, so people could add the functionality they wanted to any button in only 1 extra code step, and using 1 tool in the editor. I was the only one using that system for a while, and I wasn't sure if the modularity would be worth the investment, but when we got close to submission, my teammates were able to quickly add settings for their systems to use in our settings menu, saving valuable near-submission time. My system also allowed for one of our designers to manipulate menu buttons using only our engine editor, and while I may have gone overkill on some parts of the modularity, I plan to keep the benefits, and the knowledge of where modularity was/ wasn't useful close in mind as I design implementations for future functionality.

Balancing scope management, supporting creativity, and priorities for game improvements

One issue that we ran into in various instances was balancing scope with our team's creative ambitions. While our initial goal was to shoot for a more polished experience, there were still a lot of mechanics we wanted to test, and we (whether in smaller groups, or as a producer pair of myself and the head producer), found it difficult to decide when to cut off new ideas. We felt we had a fairly solid scope at the beginning, with being an isometric shooter with a few different special attacks, but as ideas came up like adding different bullet patterns, new special attacks, different enemies, and the like, we asked ourselves: "should we let those mechanics be developed, with potential increases to the fun of the game and the amount of testing required, or be more strict, to ensure we can make our polished product and avoid overwork?" While we did our best to predict how certain mechanics would impact the game, and greenlight new features based on that, I believe we shot down too many ideas in the beginning to middle stages of the project. This led to some animosity, as well as some stifling of creativity, and while some decisions do need to be made, I realized that after getting advice later, and seeing what has worked for us, there was a viable middle ground. In adopting a more prototype-based approach, and understanding the benefits of polish vs new features, we could enable creativity, while proving the feasibility of mechanics before they became too costly, and also prioritizing what creates the best experience.

For prototyping, I do want to mention that this project was a bit of a strange situation, as us programmers were building the engine while building the game. So, any prototypes we wanted in-engine came at a bit of a higher cost than developing in an engine like unity or unreal. Likewise, project requirements were a little unclear in whether we were allowed to use unity to supplement prototyping. Though even with this situation, I was still shown the value of prototyping, in that it shows the team in a live example what a person is thinking, and that it also helps prove the feasibility of the mechanic. And, if we had prioritized prototyping over discussions, we would likely have been able to feasibly get more mechanics into the game. Because, instead of this, we often opted for theoretical discussions with the team, where we weighed what could happen, and decided on mechanic there. Other benefits include the ability to adjust or change mechanics quickly once bringing the prototype to the team, and I think with this improved understanding, and an increased focus on prototyping first would be the better way to support creativity, while considering feasibility/ game fit, when a teammate brings up an idea for a mechanic.

Additionally, I gained an improved understanding of how polish benefits an experience, vs new features, and I think this will be crucial for making decisions on how to improve projects in the future. This applies more to the middle to end stages of a project, because sufficient systems need to exist for this to matter, but once a core gameplay loop exists, I realized over this project that it's the polish on core mechanics that makes the experience great. Take for example, towards the end of this project, where we were deciding whether we wanted to add our planned final boss. The main idea was to have this massive fight to make the experience memorable, but while we did settle on a compromise final encounter, if we had done any more work on the boss, we would have missed out on all the smaller polish features that testers reacted positively to the most. To name just a few, we devised bullet particles to make each shot feel powerful, and multiple layers of shield break feedback, to make getting hit a pivotal event (and it was, you had 1 heath and 1 shield!). Others included a flashing red low-heath vignette to make danger feel dangerous, eerie yellow lights, and dynamic music to turn our empty corridor sequence from strange to suspenseful. It was these features that often took a fraction of the time of mechanics and yielded major rewards when seeing how players reacted to our game. So, when deciding whether a last-minute mechanic idea is worth it, instead of saying no, I feel like the better answer is: is there some exciting polish you could be doing instead? Because this way, whether it's out of passion, or absence of things to do, that person can add things to the project that are quite impactful to the experience, while also requiring less pieces to move, and hopefully, less stress on the implementer.

Consistent communication between the sound designer and audio programmer

While audio affected many aspects of the game, for implementation, it was largely the pair of myself, and the sound designer, with the responsibility of identifying the needs/ vision of audio and integrating them into the game. With this, I tried a few different strategies to find a workflow that worked for us and found that some of the best collaborations occurred when we had consistent check-in meetings, and discussions to clarify our vision for the audio. One unique part that I noticed about audio is that it can often come after gameplay mechanics are established, because if mechanics are scrapped and changed, most audio is scrapped with it. In our case, music was focused on while mechanics were being prototyped, and this meant that the needs of audio could change quite quickly once mechanics were solid enough to be given SFX. We needed to be on point in identifying when it was time to jump in with sound effects, and weekly check-ins helped us to be on top of new developments, and to form a plan for the near future. These check-ins were also a good time to discuss the audio vision, because as the game changes, the audio vision often evolves with it. Sometimes the vision doesn't, or can't, but either way, we needed to be on the same page about what the goals were, and we needed to make sure that other relevant disciplines were in the loop on that vision. We did struggle to find that vision, and progress often dragged when we had periods of sparse communication. As life happens, some of that will happen but when we were able to come together to discuss the audio vision, share ideas, and come to a clear, common understanding, that's when some of our best work happened. We were able to work together and create features like the dynamic music in the corridor level, shown above, and some of the more cohesive and impactful SFX, like those of the player's explosion abilities. Once we had a common goal, and were in the habit of consistent check ins, the audio progress flowed much more smoothly, and I intend to keep these collaborative tools in mind for future teams and strike teams of any kind.