GDW Progress 4 (Sad Violin)

Oh yeah, gotta love the feeling of hopelessness. One week left until GDW is due, one more week until Design HW2. Apparently I hear we may get an extension for Design HW2, regardless I still don't know how I will pull through for the rest of the semester.

Let's start with Design Homework. I received my mark for HW1, and all I can say is that it is not pretty. 35% by my standards is not a good mark, at all. Guess what the average was, 32%! So you may say, "Congratulations Mario, you received 3% higher than the class average!" I would respond, "It would be foolish to base my success on everyone else's success. If everyone suddenly became stupid, should I gloat about my intelligence, when in contrast to the old average intelligence, I was not too far from the average?" Apparently we were to include research on our work, as stated in the syllabus. Only problem is that I almost never look at a class syllabus, as I assume that it contains the usual class schedule, how to behave in class, yada yada. I figured that anything that pertained to the homework, would be in the homework document. Oops, I guess not. Rather than blame the professor for my stupid ASSumption, I've decided to take this as a learning experience to ask more questions... even in despite that I already ask more questions than the average idiot. Regardless, it wasn't just the lack of stated research that lowered my mark. Apparently on part one, where I was to explain how to convert mature games like Batman Arkham Asylum, Rock Band, and Unreal Tournament into something kid friendly. For that I received 0/5 for research (obviously), but more interestingly, I received a 1/5 for communication, and a 1/5 for Design. Huh, interesting. Apparently the "first off, secondly, thirdly, lastly" structure is no good anymore. I recall in Technical Communications (an elective course I took in 1st year, 1st semester to improve my writing skills), making your document as concise and simple as possible is the best way. Fluffy and repeated sentences are the worst thing you can do to your reader. Now for design, I guess my ideas were no good. For example, in my explanation to turn Rock Band into a kid's game, I explained that the best thing to do is to tone down the dark aesthetics, and to play only kid-friendly music like Michael Jackson and Justin Bieber. There exists Lego Rock Band, which I think is the best way to rid the dark overtone, and introduce a style that kids can enjoy. What more can I say? Those two sentences alone should be enough to explain my position, no? I guess not.

Now the GDW. Everything that has to do with my game can be seen below.

Good God...

Doesn't that look fantastic?! A black screen! That's right, my group and I still don't have a functioning game. Throughout the semester, I've been programming an engine for the game to allow implementation of the assets (models, sounds, etc.) to be quick and painless. Only problem is that this venture has been taking me too long. So far I have created a mouse, keyboard, window, light, sound, 2Dtexture, camera, 3Dmodel, vector, and linear physics system. I was in the middle of creating a matrix class called rotation, only to realize that I will not finish the engine in time to make the game.

My beautiful incomplete engine class list.

In case you don't know, my group started the game a semester late, since we all broke off our old groups from last semester. Thus we had to create a new game from scratch. I volunteered to be the lead programmer, since I figured that I can utilize the skills I've gained from making the world's stupidest game, "Happy Culture Shootout". I spoke to my professor, Prof. Hogue, a few days ago, explaining my position with the GDW. He suggested  for me to stop building the engine, and to make the simplest, most bare-bone design for a racer; slot-car racing, similar to Rad Racer for the NES.

Difference between this game and our game, is that our game will hopefully be finished in one week. Hah...

I believe that completing such a dry, bare-bones game is realistic. However, I'm scared to see what kind of mark we will get in the design class, as little design can be implemented into the game, especially thanks to the remaining time we have. Apparently we are supposed to include all of last semester's requirements in the game, like the A* search algorithm, particle system,  matrices and quaternions, forward kinematics, morphing, behaviors, interpolation, etc. But given the time we have, it's very unlikely that we can do any of them; we may be able to do the particle system if we're lucky.

But what's more frightening for the GDW is all the design documents we need to supply. I am literally ready to cringe into a fetal position just upon the thought of the expectations.

1) Concept Design Document: Describes everything about the game. I have a feeling how long of a document we will generate for that (obvious sarcasm).
2) Technical Design Document: Since I'm the lead programmer, guess who knows all the game's algorithms best? Me! I'll have to go into detail on how every class and algorithm used in the game works. I'll also have to supply a UML diagram (which Visual Studio can generate automatically, so Visual Paradigm and its painfully tedious UML system can go to hell), but also I'll have to create a flow chart for each algorithm. I scared to even think of how to contruct my flow chart for my light manager class, as that alone spans around 2000 lines of code. I am not kidding. I'll also have to describe my menu system interface/GUI, something I currently don't even have. Heck, I don't even have a game yet, what am I talking about?!
3) Scope Document: Our game stands out for being the most hopeless in the class, especially thanks to the dumbass programmer who spent too much time making the game's engine, and moping on Facebook for personal melancholic reasons.
4) One Page Design Poster: I could have sworn that I did this in Business of Gaming class. My poster looked disgustingly rushed.
5) Justification and Research Report: Our design came ultimately from this philosophy, "How do we make a game as quick as possible, so that we can pass the course?". Usually games like this generate an abundance of fun (more sarcasm).
6) Q.A. Report: Hah, funny.
7) Balancing Report: Balance what?
8) Developer Profile: Everyone but the programmer is not a dumbass. Simple.

Apparently we were to have a started version of each document by the time of midterms... lol.

This face alone should convey a powerful enough message.

I know this blog update was longer than I expected to write, but that just goes to show that I have no idea where to start, and how to start; thus I resort to a simple yet pathetic rant on my blog. I feel like it's Grade 12 all over again; the coursework isn't as difficult as last term, yet I'm receiving much lower marks, and my sleep and social life are still lacking as usual. Oh, did I mention that on my Accounting midterm, I gained a 61%, and on my Sound and Audio midterm I received a 62%? Yeah, second semester of second year is biting me in the ass when it shouldn't be, especially since first semester of second year for me was the pinnacle of academic difficulty in my life.

Here's the thing, like all students around me, we love the summer. However for me, it's mostly for another reason; I can catch up on last year's material at my own pace. Last year I made the world's stupidest game, "Happy Culture Shootout" simply to prove to myself that I can program a game, especially after the failure of my last year's GDW game. I also made it as suggested by Prof. Hogue, instead of taking 2nd year courses to fast-track. This summer, I plan to create a game with a group of friends on the engine I originally wanted to first build for my GDW game. I love it when I can do my own project outside of school for two main reasons:

1) I move at my own pace, because as everyone knows, I'm not the quickest or brightest man.
2) My work roots from intrinsic motivations. I remember learning from my Leadership class last year, that intrinsic motivations are far grander than extrinsic motivations. Think who would be more successful, the one who works for money, or the one who works for his dreams? During summer I can do my own thing; during school, not so much.

I have to say though, since I started university, I've come a long way - especially with my programming skills. But now it's time to put that aside, as start honing my other skills like art/drawing, writing, business, and most importantly, design. In case you don't know, from the beginning I wanted to be a game designer, not a programmer. All of my professors/instructors would always say that in order to be a successful designer, you must be skilled in programming, art, animation, writing, etc. I think I'm pretty safe to say that I've got programming under control, however the other fields need a lot of work.

This is a recent picture of my current art skills. I drew this around an hour's time. As you can tell, I have a long way to go.

I'm sure by this point you expect me to wrap up my junior high-school level writing skills with some sort of conclusion, but as you can probably tell by my previous posts, I often find it difficult to get to the point. The only reason why I realize this, is because my Gr. 12 English teacher pointed this out two years ago. Sometimes I do get the feeling that I successfully wrapped up a document, video, or by some divine miracle, an argument; but often I don't get that feeling, just like right now. However I guess it could make sense that such a scenario had to occur now; I'm talking about something that hasn't been reached yet. Not just my GDW, Design HW2, and other homework, but my intrinsic goals and ambitions. This is where the history book runs into blank pages, they have yet to be written. I know this sounds extremely corny, but I guess when you've hit the bottom, you have no place to look but up. Not saying that I have hit the bottom (or that I'm anywhere near it, thank God), but I dunno; throughout writing this blog post from beginning to end, I've suddenly turned from scared, angry, and depressed, to strong, determined, and ambitious. Perhaps it's because I'm looking at the character in the picture above. How I feel like I'm in the dark, yet I still see the glimmer of light in the distance that I have spent my whole life to attain thus far. And guess what, I will attain it, some way or another...

The essence of corn encapsulates my last paragraph...

I've tortured you enough with my words of corn. Thank you for reading, and have a great day! =)

GDW Progress 3 (Bah...)

Hello world.

Yes, that's it. Fascinating, huh? I know you may be thinking that I am now in a hopeless position since I still don't have a game, it's due in merely three weeks, and all I can draw right now is a teapot - a teapot that can easily be rendered thanks the GLUT library's already created function. Well guess what, I've programmed a lot more than what you see. I have completed a Light Manager class. What does that mean? It means that I can easily create a light and apply it to any object with very few lines of code.

(Just a heads up readers; if you're not a programmer (as for those who don't know, I send my blog links to my friends on facebook), you may have trouble with understanding what I describe below, and ultimately bail on the article. I apologize for this, and I'll try to make my explanations simpler next time, sorry... :S )

Naturally, the OpenGL system provides eight lights, and are tedious to apply in dynamic scenarios. So what I did was create a class that holds a whole bunch of variables that can be applied to any of the eight OpenGL lights. Such variables include colour, position, direction, attenuation, etc. and they are contained within (what you can imagine as) case-holders. Such case-holders (which are managed by the light manager) are essentially  "light-shells". Those "lights-shells" can be applied to an OpenGL light on the fly, transferring the shell's qualities (colour, position, etc.) to the actual OpenGL light. Once the OpenGL light gains the appropriate parameters, it can then be applied to an object. Up to eight lights can be applied to a single batch of objects. Once the lights are applied to the object, the programmer will then have to call a function called "release", which clears out all the OpenGL lights, and readies them for the next application. The Light Manager also chooses which OpenGL light to apply a given light-shell to (0-7). If all eight lights are used up, then the manager will refuse to add any more light.

So in other words, we can save many many light-shells as a positional light (like a light-bulb), directional light (like the sunlight), or a spotlight. Let's say we want a directional light-shell that contains a dark green ambient light, lime green diffuse light, and bright green specular light. We pull that light (which is labeled by an enum ID number), and apply it to an OpenGL light. If OpenGL Light0 is already being used, light manager checks if Light1 is being used. If it isn't, the light-shell that we pulled out will then be applied to Light1. Once all OpenGL lights have gained the required light parameters, it can finally be applied to an object(s). Once they have been applied, the programmer must refresh all OpenGL lights with the "release" function, and ready it for the next object(s).

Additionally, the lights are also able to move... somewhat. Let's say you have a car object, and you want it to have headlights. Easy, all you have to do is apply a spotlight, and as the car moves, update the position of the light by using the "setPosition" function. Simply input the position of the car plus an appropriate offset, and you've got the new position of the headlight. Now let's say the player restarts the game. Simple, use the function called "reset", and it resets specified light-shell's parameters back to the original parameters it had when it was first initialized (such initialization occurs at game start-up). But wait, what if the player wants to switch off his/her headlight? No hassle, just use the "SwitchLight" function; if it's on, it will turn off, and vice-versia. There are also other functions, including one that allows the programmer to switch the light on, whether it was previously off or not, and vice-versia.

Unfortunately, the light manager isn't entirely complete, as I want to implement a "material manager" within it. Every object has material parameters that are applied before it can be drawn on screen. I want to eliminate such a tedious process with an appropriate materials manager. Rather than create this manager as a separate entity, I'd rather implement it within the light manager class, so that any programmer will instantly know that it's solely related to the OpenGL light. Materials will also have material-shells, and can be called using the enum ID system.

Minus the intended material manager, my light manager alone currently takes up 1,770 lines of code. Yes I worked very hard on this, it was a long-process, but the end result was very worth it. Once the materials manager is complete, my next goal is to perfect the sound manager, and input devices (keyboard, mouse). After that, I will begin to integrate Matricies, Quaternions, sprite holders, OBJ loaders, camera system, and test the texture manager. Those are just a few of the many things I have left to program, however I hope those features each don't need to take up as much code as my light manager did. Once everything I need to do is complete, my engine will be asset ready, high-level (easy to use for my other group members), and game production will increase exponentially. I hope to reach this point by Tuesday the latest. Thanks for reading! :D

GDW Progress 2 (somewhat...)

Hello, here's just to show what exactly I have on screen for my GDW game:

Yeah, that's basically the PGM assignment that I was required to do for my Graphics class. I wrote around 1350 lines of code for that assignment. I'm sure most people in the class (if not, all) wrote a hell of a lot less than that to complete the assignment, but I wrote more to make the lighting more dynamic. I wrote a LightManager class that automatically handles functions to do with lighting in the OpenGL graphics engine. However it's still buggy, and more functions need to be written.

Other than that, I have a TextureManager class that handles all texture mapping to 3D objects. Only problem is that I haven't tested it yet; I simply copied and pasted old code from another project of mine, and refined it to make it more dynamic and easy to use. It functions on an engine called DevIL (which stands for "DEVeloper's Image Library", not Satan, relax).

I also created a SoundManager class that functions on the FMod Sound System. However I feel that there's still some polishing needed, and then I plan to check it with the Sound and Audio TA to ensure that I'm using FMod to its full potential.

So yeah that's about it. There's no "game" as of yet, but my primary goal right now is to perfect the Texture, Sound, and Light Managers. However before then, I have to complete my Business Pitch assignment, and study for my graphics midterm. Oh the woes of a university student...