Speaking as a writer/gameplay designer/level designer with low/medium level of programming understanding, I think the hardest thing to grasp when entering programming is the sheer number of functions you have at your command. It's daunting to keep track of what you can use to solve what problem. Some of the maths logic (especially regarding pointers) also makes my head bleed.
Scripting, whether visual (Blueprints) or code (GML, UScript etc) does help in simplifying the function numbers down, but it still requires a great deal of time with the cold documentation to memorise what you need. It's nice when you have access to look-ups (like in Blueprint, I can type in a number of words related to what I want to do and find something that matches or comes close), but it does mean that the programmer who names their functions needs to speak the same language as the designer who uses them.
That said, I think code-script is a dead end. We should be simplifying but still providing access to the raw code, so users can build confidence and eventually dig deeper as they need it. Visual Code still does have a place, since many designers can actually see the flow of their logic.
The Alessa demo accelerates from here. Next week/week after we have to do our final project pre-production presentation, and then it's full steam ahead.
The team is loving me because they can't read documentation about the A.R.T. rigging toolset, and I'm going to have to design the level by myself. Fair's fair though; I have the least classes this term, so I should probably be doing the most work.
Let's just hope I'm not driven insane.
