Getting Started : To Code or not to Code

The Problem:

This week the focus was to start migrating our prototype to full c++. What I figured would be a somewhat slow but tedious task, quickly became a long struggle of what seemed to be nothing going right. Moving the damage system to code went smoothly with a short learning process on how interfaces are implemented and executed in C++ with Unreal. Where I realized I had underestimated this task was when I began migrating the enemy AI. In blueprints I was able to get a quality base with a melee and ranged enemy. When migrating ai there is a lot of things seemingly hidden behind the blueprints that you need to access differently. Learning all the components and what each one is used for turned into more reading than actual coding to get a better understanding of what was happening. The setting everything in blueprints to start was good for moving the prototype along but getting too far ahead without stopping to move to code sooner has become an issue.

The Solution:

Looking back now I believe the only solution to this setback would be to start coding sooner in the process. With our quick deadlines and requirements for the prototype of Month 1, I got in the habit of blueprinting everything with the plan to code it quickly at a later time. This was a mistake and would not blue print as far ahead as I did next time. It would be better to sacrifice the quality of the first prototype to have the base classes coded from the start then to have to go back and put more pieces together to get the code working properly.

In the video it is easy to see that in the same amount of time it took to blueprint the prototype enemy behaviors, migrating it to code has produced far less. In the time it took to have the enemies attacking the player one at a time and circling them in blueprints, switching that to code has 0 enemy movement, and only sight detection with the ability to take damage and die.