Well obviously as an avid gamer I know about the flow.
What was said in the audio lecture about getting into the game flow state really connected with me. Especially in high-pressure moments in games like Guitar Hero and 2D twitch-shooters (kind of like asteroids but crazy), all my focus is on the game and surviving the level.
With respect to the flow chart, the major example that came to mind was Guitar Hero. It was an early birthday present for me several (quite a few) years back to get my mind off of getting dumped by my girlfriend. I started on easy and went through the entire game start to finish, then did the same on medium, then on hard. A whole month shot by as I gained GH skills and was eventually playing on expert.
I remember at the time that it was the only activity which could get my mind off sad thoughts. Despite everything going on in my life, when I got into the flow state playing GH it all disappeared (thankfully), as I lost all self-awareness. From this example I could see how often I've experienced the flow state without every knowing what it really was. The hours of dungeon-grinding and adventuring throughout the years didn't seem like much time at all.
Recently in my spare time I found a little game called Scoregasm to get my mind off things. It is the aforementioned twitch-shooter, and it certainly is crazy. The level of concentration needed to survive requires the flow state. Anything less and your brain cannot process the information fast enough for you to react and dodge the incoming enemies and lasers.
It doesn't apply just to these types of games though. Any game that can keep me interested and engaging will have me whittling away the hours in a flow state. I think its a really cool theory and that game designers should really focus on striving that perfect balance between the flow chart axes. This will keep gamers entertained and coming back for more.
Since I don't really have much else to talk about right now, I will continue to talk about my programming woes and triumphs. Firstly I'd like to say I have my object loader working perfectly fine, and things are good on that front. It can load in multiple objects in different viewports, so now I just need to get lerping!
On the other hand, the particle system is...halfway there. I got glMultiTexCoord working as it is supposed to, but this resulted in a rather nasty runtime-check error.I've googled it for a depressingly long amount of time, and have surmised that it involves the difference between how c++ and c function calls work.
The difference comes down to __stdcall and __cdecl, and because glMultiTexCoord works off a dll which uses c, it is corrupting the stack pointer when it tries to clean up the memory. I have found a way to force the program to run anyways, but after 5 particles on the screen the stack pointer becomes corrupted so...not much of a particle system. Oh they are all there...you just cant see them -.-
With a little help from the game dev group I've learned how CG shaders actually get their input parameters from the program. Certain opengl functions such as glTexCoord and glVertex are automatically used by variables in shaders with certain semantics, TEXCOORD and POSITION respectively.
As for the 'uniform' variables, they are explicitly set in the actual program with functions such as cgSetParameter#. In the shader the uniform identifier states that the program will take this variable, and these types of variables stay the same across all vertices/pixels. The aforementioned variables are implicitly called as varying, because they are different for every vertex on the screen.
So that's my little shader variable wrap-up, until next time!
