Combined Post

Yes I know I've been told that combining posts for Engines and Game Design was bad. But it's crunch and I have no time. I'm also jittery from coffee so please excuse any spelling mistakes. Also excuse the fact that this post will be a long ramble about stuff that ...I don't even know. I'm just writing because I want to say that ...  forget. But the point is ...well you'll see.

So we need a trailer for our game, right? We have a space game. I spent about 2 days working on the battle scene of the trailer. To give you an idea of the work I've put in here's a picture.

Look at all of those ships! There's so many blue fighters and so few red fighters. They're so outnumbered!! I guess you HAVE to help them by playing Quantum Prime and becoming the best pilot on the team. It would be hard to beat the pilot of Hram 4 though. Look at that crazy near miss!! OhEmGeeeee!!

To be fair, I only animated perhaps 90 frames for each ship. But there are lots and lots of ships to animate. I felt like I was playing an RTS. Some ships unexpected, ended up flying better than others. One was even a little slow taking off from the blue mother ship. The guy flying that Stingray (the blue team ship) must have been a rookie, or a droid with some bugs or faulty wiring.

Also, metal ray makes everything look nice

Look at those reflections! I'm a little sad my shaders never looked so good (or that I never got cube mapping working. But I want to someday). 

And Lucas' mother ships look pretty all lit-up. 

I hope this part of the trailer will look nice. I'm afraid I won't capture its full potential when rendering it (or that it looks better in my head).

It's weird not coding for two days, especially during crunch. It's even a little frustrating. But I guess there isn't THAT much left to code. We need to integrate a few things and add a couple of things, maybe even tweak the AI. And on top of that we have assignments like the website and postmortem.

I feel like this semester has been the hardest so far. I feel like I've been saying this every semester, but this is the hardest I've worked in my life! I just hope it pays off in the end. I guess at least Dr. Nacke liked our game the other day. I was surprised because I thought other peoples' games were better.

It might just be a matter of taste, or because I've see how horrible our code has gotten over the past week or two. Or maybe it's just because of the sweat and tears I've put into this game.

Anyways, I think I should sleep. There's so much left to do!

Game Design 1.1

Hmm so one of the assignments for game design calls for "customizable characters". Since we're making a space game that purely involves flying spaceships around and shooting stuff, we don't really have "characters" per se, but we do have a few different ships fighting for each side.

Customization will be possible through the main menu. You can choose what ship you want to fly. Right now we've only put two of them in and they have the same speed and mass. In the end we hope to have one ship be faster and one have more horsepower or ammo or something. I suggested we have customizable hats for each ship but my team members did not agree that this was a fantastic idea. I can't say game design is my forte.

Another game design element we put into our game is the ability to swap your remaining energy from the ships's battery (or health) to ammo and vice versa. This is completely plausible if you consider that it takes energy to fire at other ships. This also gives the player more control over their ship. They must be cautious to balance their ammo and health efficiently so as to deal the most damage while remaining alive.

We will have power ups too but I'm not sure how those will work just yet. It is only after they are programmed in that we can be sure what they will consist of and how they will work.

Speaking of programming, I should get back to that. After I sleep. I've had a good amount of sleep in the last while but I'm still quite tired. Probably because it's my brain, not my body that's tired. It's alright though, because exams are coming soon and studying is a joke compared to GDW, which is due before exams. Studying involves sitting there reading stuff. You never run into bugs that you spend weeks ripping your hair out over when you're studying. If something "should work" that's good enough in an exam. If something "should work" in code, that doesn't mean it will. It doesn't even mean it will be easy. SOMETIMES PARTS OF THE ENGINE ARE BROKEN AND NO ONE TELLS YOU OR SOMETHING IS SIMPLE AFTER YOU KNOW HOW TO DO IT, BUT NO ONE ANYWHERE CAN GIVE YOU ANY HINTS ABOUT IT. AND SOMETIMES THINGS JUST BREAK FOR NO REASON JUST BECAUSE THEY HATE YOU AND WANT TO WATCH YOU SUFFER. Studying is easy, even if your memory is useless at remembering anything except funny quotes you laughed at as a child.

Engines 1.0

Hmm... so I don't really know what to write about. I'm really busy because of crunch. I had been having problems with normal mapping because Ogre does things weird and Dan found out that none of my meshes have tangents exported. Gordon also says Ogre's view matrix is wrong. I finally got it to work though. FINALLLYYY!!!111one!!!!1one ...Thanks to glsl I could bypass using Ogre's matrices and made it work with re-exported meshes.

And since I have no idea what to write about, I instead leave you with this rant.

#pragma region rant

It makes me a little sad when people try to get through Game Dev without actually doing any legitimate work. They try to just complain to professors about things being unfair rather than trying their best to improve their skills to be able to pass. Isn't everyone here to get good at making games? What's the point of being here if you're just trying to "weasel"  your way through? In the end you're the only person that loses because you don't learn anything about how to make games.

And I know it's not easy to get good at stuff. Yeah, sometimes you fail, sometimes you fail really hard. Sometimes you get frustrated and ragequit and cry and whine. It's ok to do that. I do that all the time. I get frustrated and my code starts to look like a curse-word generator was unleashed mercilessly upon it. Sometimes people tell you that you suck at things and everything you have done is wrong or looks bad or doesn't work properly. Don't just unfriend them and hate them for life (unless they're just being really rude about it or calling you names or having expectations that are simply impossible for you to meet in the time that you have), try to look at your work and see why they are saying those things. There's always room for improvement.

You also have to realize that lots of things seem impossible until you do them. (If you have a very short time limit though, some things may actually be impossible.) Shaders seemed impossible when we didn't know what shaders were, but after making shaders we all found out that they're totally possible. In the end, even if you don't think you can do something, you sometimes end up doing it. Just because of how hard you tried . Even though it's true that some people start off with certain advantages, be it mathematical skills, artistic talent, or a great memory, pretty much anyone can surpass them in that ability if they work at it more.

I guess my point is, don't just sit there and quit. Use your frustration to fuel your determination. If people say the things you've worked on look bad or don't work properly, well then use that to make stuff amazing next time so that they'll be left speechless. Use that to work harder and do better. Don't just give up forever. If you want to quit at everything permanently, well then switch into another program and that you like better. Cuz no one ever got good by sitting and doing nothing. And in the real world people won't dumb things down to your level if you can't be bothered to try to teach yourself things. No one is going to say "Well jeez it looks like you can draw an OpenGL teapot on the screen, and even though we were really looking for someone to write manager classes for our engine, we'll hire you. You can render teapots and get paid for it."

If you came to this program to get good at making games, well then do it.

#pragma endregion rant

Engines 0.9

It seemed like nothing was working out and everything was taking forever to complete. I still have not gotten tangent space normal mapping to work properly (the light is still affected by the direction of the camera), and I have set aside working on lens flare because it is not a requirement and after wasting much time on it, I still have not gotten it to work right. Still, we must work on. As the lyrics of one Protest the Hero song go, "The little things that kill you make you glad to be alive".

Thankfully, bloom was really easy to add into our game (assuming that we are allowed to use the bloom included in the Ogre engine). After copying the Examples.compositor file, the Bloom.material file, and all of the shaders these require, it's just two lines of code to add bloom to your scene.

As you can see, our game needs more bloom

I also want to say that ...I forgot what I wanted to say.

It's pretty much officially crunch now, though we've been lightly crunching the whole semester....so back to crunching I go.

Game Design 1.0: Making Alien Planet Textures

This week I spent about two days making a better planet for our game, and one that we can use in our trailer. I followed this tutorial http://www.blenderguru.com/videos/create-a-realistic-earth/, which is quite good. The only problem was that I didn't want to use NASA photos of Earth, because our game takes place
in a different part of space (maybe a whole other quadrant, I don't know). Our planet still has the same colours has Earth (this was the look decided-upon), but the continents, oceans, and (noobish)clouds are completely different. So I guess I'll talk about how I made the textures.

Start off with a photo of a rock. This one is nice and smooth but still has noticeable features that could be mountains and canyons. You can make it a seamless texture by opening Photoshop and going to Filter-->Other-->Offset, then offsetting the picture enough to see the seam. You can now fix this seam using the rubber stamp tool.

Next you need to add an ocean. This part is the most tedious. Believe it or not, I actually picked a very fine brush in Photoshop and actually drew in all of the coastlines on the planet. This was very time consuming but completely worth it. The oceans I made looked like this:

I also added rivers and lakes in a few places, and made the oceans slightly transparent so that it would not look completely flat. You can use the same offset technique to fix the edges of the oceans, then offset them back in place. I added snow at the top and bottom of the planet to hide the valence points in the geometry, and then lightly coloured on grassy areas as well as deserts using a mostly transparent brush. Dark, almost black, areas at the points where the ocean is deepest add a nice touch. So is adding lighter patches where the ocean is quite shallow. After all of that, I ended up with this:

The clouds are a bit tricky. I'm not even quite sure exactly what I did, but here is roughly how I made clouds.

1. I drew a bunch of random white splotches and lines on a black background(in Blender it is possible to make black areas see-through)
2. I applied a Gaussian blur to make everything look diffuse
3. Then I used the Liquify tool and swirled and smudged the clouds to look more like  the NASA cloud map of Earth
4. I applied a filter to make the cloud edges look rougher.
5. Rendering cloud noise as a mask to the layer also helped roughen up the clouds
6. I increased the brightness and contrast till there were only very bright or very dark areas

This method didn't create the best clouds, but I did not find a better way of making clouds. This is the cloud map

All you need to do to make a planet from those textures is follow the tutorial in the link at the top. And since you've made the planet texture yourself, you can make the grass and oceans any colours you like.

Game Design 0.9 : Monopoly

This week our assignment for game design was to create a casual game in Unity, based on Monopoly. Since we did not want to just make a digital version of the board game, we decided to make an original game called Monopoly: Elephant of Evil. As the title suggests, it is heavily influenced by Monopoly, but not a direct copy.

That is a screenshot of the game as a work in progress. As you can see the elephant, top hat and thimble, which are used as game pieces in the Monopoly board game also make an appearance in our game. In our version though, they try to run and pounce on you and then rob you of your money. There are also small, green houses scattered throughout the game which are kind enough to donate money to you.

This house gives you $6 for every second that you touch it

The player must be careful to gain as much money as possible while shooting the thieving game pieces to avoid being robbed. And before the time runs out, they must bank all of their money lest they lose it all. The player has to make difficult decisions in this game. If they wait too long, their time may run out, or their money may be robbed by waves of ruthless enemies.

Engines 0.8

So this week I got glsl lighting into the game. It took a while because everything in a glsl shader is relative to eye space (or something like that) and I want the light positions to be global. We exported lights in our scene from Maya so we wanted to be able to use those lights and not have to set their coordinates all over again.

Getting light positions of light entities in Ogre and then sending them to the shader isn't too hard once you know how to do it. Finding out how to do this takes a while though. I did it with this line of code:  "param_named_auto myLightPos light_position 0" when I call the vertex shader in my material file. "param_named_auto" means that you're grabbing a value that Ogre can automatically get for you (here is the list of ALL the variables it can give you http://www.ogre3d.org/docs/manual/manual_23.html#Program-Parameter-Specification ). I'm using "light_position" as the automatically named parameter that I want to get. I assign this value to the variable "myLightPos" in the glsl shader, and then tell it I want the position of light 0 (that's why there's a 0 at the end of that line of code. That's the light number).

I also found out how to pass several textures (a maximum of eight, I believe), to the shader. I did it through the material file.

My texture parameters in the shader are called tex0 and tex1. Then I make Ogre get the textures with "int 0" and "int 1". I think the number corresponds to the order the texture was added in. 

I wanted to get normal mapping to work but that took a bit more work and I'm not done yet. According to Dan, I need go pass in tangents and bitangents to the shader to be able to use the normal map I currently have for my spaceship. 

Apparently that ^ is a tangentspace normal map. That means that it's relative to the texture of the UVs of the object, not the object itself. It also means I need tangents to make it work. I never knew the blue normal maps we see are in fact not relative to the object. Apparently objectspace normal maps should have all sorts of different colours. That's neat. 

Game Design 0.8

I've been watching a bit of "Star Wars: The Clone Wars" in my spare time (well, while my hands are busy putting food in my mouth) and it's actually a very good-looking series. The models have a toy-like feel to them and the textures look painted on. I actually love the models and textures.

That's General Grievous in the show. If you look closely, you can see the brushstrokes. 

As you can see everyone has a very cartooney/toy-like feel. But I think this look would work perfectly for a game. If we could make our spaceships resemble this art style, I think our game would look quite good. Note the emblem on Obi Wan's shoulder and the worn look of it. It would be nice is the emblems on our ships were a little worn from battle. We want our game to have a similar feel to this series. 

In our game, you play as the humans (the "Good Guys") in ships that look like they were made on Earth, or by the descendants of humans that lived on Earth. Your ships are worn and your troops are weary, but you must keep fighting. The enemy has many more resources and perhaps slightly more advanced technology that looks sleeker. 

Even though our game is inspired by Star Wars in many ways, we DO NOT want to copy the games or movies in any way. We still want our ships to look original and our logos to be unique and different.

As a side-note, I am very, very glad that two of our next assignments for Game Design actually involve working on our GDW game. I really want the GDW game to be polished and beautiful and have great gameplay. The only way that such a thing can be achieved though, is through a lot of time and effort. Working on separate, Unity games for our assignments takes time away from our space game. They also end up looking half-baked and rushed because two weeks is definitely not enough time to make a great game. If you look at games that have been released and do well, you will see that all of them took quite a long time to complete.

Engines 0.7: Ogre Shaders

UGH ...Ogre is being difficult. I don't know if it's just me but I find its shaders pretty convoluted. And on top of that, for some reason uncommenting the Cg Shader Plugin still has my Ogre log screaming at me, and I quote: "* Supported Shader Profiles: arbfp1 arbvp1 glsl. (Yeah, have fun using cg when you can't! HA!)" Ok, maybe I added in that last bit, but I truly feel like Ogre is holding a grudge against me..or maybe it's just way too early in the morning to be writing a blog. I don't see myself having time to do it later though :/

So GlSL it is then, Ogre. I somehow cobbled together a vertex and fragment shader in that language (it's not that complicated or different than cg. In fact it might be simpler. I'm not sure yet though). Oh, and I forgot to say, the reason I'm working out how to use shaders is that I want to do the "morph animations" question. The one where you have to morph one object into another (there's a bit more to it than that).

Now anyone with half a brain would assume that Ogre would do keyframe, morphing animations for you. But I really don't know if it does. Form what I have found and read, I think you need to keyframe things in Maya and then do some witchcraft and summon demons to write code for you in a mysterious language called XML.. Here's the link if you can figure it out. http://www.ogre3d.org/tikiwiki/tiki-index.php?page=Morph+animation. I saw shaders and though, "oh well if I have to animate stuff through a shader, I might as well just pass vertices in the good 'ol fashioned way and save myself the trouble of learning another language.

How exactly do you make shaders in Ogre though? The answer is "not very easily". So you have a material file, which you apply to an object. That part is straightforward. Then either inside that material file, or in a separate file with the ".program" extension, you write a "shader program". This isn't where you put the shader code itself, this is just a program that passes parameters to the shader program. You also have to call this program in your material's "pass" section, while adding in any parameters that change.

There's an example. It's pretty confusing, but this helped. http://www.ogre3d.org/tikiwiki/tiki-index.php?page=Getting+Started+With+Ogre+CG+Materials&structure=Cookbook The only problem is that it was in cg instead of glsl (and cg is the shader language I know).  Also, a bit of advice: separate your vertex and fragment shaders into different files. Glsl will give you errors of you don't. Here's a look at glsl:

By the way, that's a vertex shader. And gl_Position and gl_Vertex are variables that are built into glsl. gl_Position is the vertex position the program outputs, while gl_Vertex, I'm guessing, is the vertex position put into the shader. Also note that "uniform" is used for variables passed to the shader form Ogre and "varying" is used for variables that will be passed to the fragment program afterwards. 

I guess none of this has actually used anything other than scripts so far. So here's how to pass variables from Ogre: 

Yup...that part is probably the easiest.

So that's what I worked on this weekend (I would've done more but my parents convinced me to go home one last time before the Christmas break and that was kindof a hassle considering how far away I live). There wasn't much time and I'm probably doing morph the complicated way, but hey, at least I now know how to use shaders and can maybe put some into our game someday when I'm not swamped with work and have a few free hours. a

Engines 0.6: GDW Progress

In my game design blog I tried not to talk about programming. No, I saved that for this blog, because to me, Game Design has always been an artistic thing, not something that requires hard numbers and logic and code.  Anyways, our game is starting to look pretty good. I think it's because we have a skybox and particles as well as the beginnings of a HUD.

The particles in our game are Ogre particles. They use a script which is really not hard to use (http://www.ogre3d.org/docs/manual/manual_34.html here's the documentation in case you were looking for it). I tried to write a seek function for our enemy ships but failed horribly. That's ok though. I'm just not the greatest at math and Havok makes things confusing. For some reason if you take the orientation of an object using Ogre, then try to apply that same orientation to another object using Havok it just doesn't work at all. The other object will just face random directions.

So I guess I should talk about what I HAVE done instead of what I haven't. In the past few weeks (I'm not sure if it was the past few weeks. The engines midterm feels like it was last week even though it was this week and time feels all skewed. It's just skewed in a bad way where it feels like there's no time to do anything or work on the game and all I want to do is work on the game and gaaahhhh!!). Anyways, I worked on a "ship" class. This defines an object as a spaceship. Albert suggested we write scripts for our ship attributes, so I implemented that. Scripts make it very easy to change variables and save you compile time because you don't have to recompile your game each time. Speaking of compile time, our game took 2min 47sec to compile. I restarted my computer and the compile time was much more reasonable. I dont know why that happened. But 2 minutes is a looong time. Anyways, the scripts aren't complicated:

health     100
ammo     500
speed     10
amount   5
particlePos1 1.7 0.7 -3.5
particlePos2 -1.7 0.7 -3.5
particleTex particleTexture
particleSysName testParticles
billboardSetName shipBillboards
thrusterTex redThruster
thrusterPicSize 1.6

As you can see, it's just defines the ships' health, speed, the swiftness with which it rotates left and right, the positions of its thrusters of particles and billboards and the textures applied to those particles and billboards. We will also have shield strength.

The ship class has functions to move the ship forward, pitch up or down, and roll left and right. These functions all apply Havok impulses in different direction or orientations. As I said before, we have particles and billboards for the ship thrusters. There are also functions for that.

Our game is really simple so far. It's coming along though. I just wish there was more time to work on it. We could make it so awesome. Sadly, the harder we work, the more work we seem to have thrown at us, cutting the time we can work on the game. I know I shouldn't complain. I still have time to sleep. But it's just a little frustrating knowing that I have to put aside what I want to do (work on the game), for written assignments and things of that sort :C

Game Design 0.7: GDW Progress

I've made some progress on the design of our GDW game this week. There were particles coming out of the thrusters (which I put in before), but I added ambient ones as well as a billboard to make the thruster look better. I also posted before that I would show off our skybox.

Here it is:

You can't see it in this still frame, but some of those white points that look like stars are actually particles zooming past you because you're going fast

I photoshopped the planet into the skybox. The planet was a picture of a rock that I coloured on and added glowing effects to. That is why the terrain looks so realistic

I made the skybox using a program called "spacescape" (http://alexcpeterson.com/spacescape). It actually exports seamless space skyboxes for you. You just need to create and add different layers of noise or stars or billboards. It's pretty cool. I can't take credit for our awesome skybox because I simply followed a tutorial.

You can also see the particle effects on the thrusters. It isn't very difficult to do in Ogre because Ogre has a particle system that you can use (http://www.ogre3d.org/docs/manual/manual_34.html). It just takes a bit of fiddling to make it look the way you want it to.

We will be adding textures to our objects soon. The problem is that I just finished texturing my ship (I think I'm done. I could add more but I'm not sure yet). It's an enemy ship and it's only 800 triangles, which is excellent if we want many enemy fighters in our game. The lower the polycount, the more efficient it is to render.

The rough metal texture of this ship comes from a photo I took of my mother's baking pan. 

That's all I've got for now. I've barely just started working on GDW because I've had to finish ALL the assignments and study for midterms and sit in class and listen. I really hope I can make more time somehow because I would really, really like to work on this game more. I think it has potential and working on it is probably the best part of being in Game Dev :]

Engines 0.5

In the past week I actually started to contribute to our GDW game, Quantum Prime. It felt really good. If I could spend all of my time only working on the game I would much prefer that. Unfortunately, I can't because there are classes to attend and assignments to do.

I didn't do much yet though. I only started a basic "ship" class for our spaceships (Quantum Prime is a space game), but I'm itching to code more now. I really want to be useful to my group and I want our game to be awesome.

Unfortunately I need to take a break from everything and study for midterms for the next few days. It feels weird because I'm not used to memorizing things or having to explain what I know (I'm very bad at explaining things without using the words "um", "stuff" and "things"). Usually, if I don't know something I Google it, look at examples I have been given or my old code, or just derp around till it works. Sometimes I even just rage really hard and ask for help or search more thoroughly for answers than I previously have.

Studying, though, is a completely different beast that I am totally not used to. It does give me a chance, for once, to actually understand why things in programming work instead of just accepting that they work and moving on to the next problem or task. So studying for Engines is actually useful.

Game Design 0.6: Audio Games

So last class we had to make a game that consisted of audio only. No visual cues or physical cues could be used. There is a reason there is no such game that sells well enough for everyone to hear of it (no pun intended). If anyone has made a game that is purely audio-based well then I feel bad for them if they thought it would sell well. I'm not trying to bash people who've tried making audio games. I'm just stating a fact. Think about it, if you had the option of playing a game with the shiniest graphics, realistic normal maps, beautiful landscapes,  terrifying enemies, and sweet weapons, and a game with no graphics at all, which would you chose?

Audio is definitely an important part of a game. Horror games with no audio would not be scary at all. Games like Skyrim, have music that is so good, I actually listen to the theme song when I'm bored sometimes. And what would it be like if your guns didn't make shooting sounds. The game would be bland and you'd always feel like it was missing something important.

Audio is just ONE part of what makes a good game though.

To make a FUN game based solely on sound is a huge challenge. Is the player not allowed to interact with the keyboard? If so, they would have to go through annoying menus (where the AI asks you to reply "yes or no" then misunderstands your yes for a no and you get frustrated and want to take a hammer to it to end its meaningless, annoying existence).

Even if you are allowed to touch the keys, your game choices are limited. The only genre I can think of is a text-based adventure or mystery game, where instead of reading, everything is read to you. There are a set number of options and you press certain keys to select them. Everything is pre-scripted.

A game like this would require some work though. It is not easy to think of a good, exciting, original story. After that all of the sound must be recorded and the engine must be scripted to take into account every possibility. It's not an easy or menial task by any means.

As an aside, this type of game could not be implemented in real life in a classroom setting with students as sound sources in half an hour. A script would have to be written, parts would have to be memorized, and timing would have to be implacable  It would take as much time and skill as organizing a great play, or maybe more because a play's story-line is linear.

Game Design 0.5

For our GDW game we're going for a realistic / Star Wars Battlefront kind of feel (only the space battle part). This entails gathering textures of scratched metal and rocks, which is what I spent last weekend doing. My mother wanted to go hiking in Gatineau Park and we brought the camera along. I took a few pictures of rocks. One of them turned out perfectly for the surface of a rocky planet (I'll post pics after I finish the planet).

There's a village near Carleton Place called Appleton and the rocks downstream of the dam are shaped by the water. I got some good pictures there of rocks too, only it was starting to get dark.

I also took some pictures of metal for our spaceships. Here are some of the better ones:

My mother's baking pan

This is the cover of an old catalytic converter (part of the car exhaust) in our yard. 

I hope these images help you get an idea of the look we're going for. And if we can get all of our art assets in the same style (we're working to fix our mistakes from last year) then our game could look really good. 

The Unity demo we have to make will have some rough textures as well as our models. It will also have basic mechanics. I've seen it and it's starting to look nice. The skybox isn't done though. It needs the aforementioned planet to be added to it. I'm working on that though. 

Also, if anyone needs/wants texture photos like this I can share them on Dropbox - because Game Dev is all about teamwork. 

Engines 0.4 Havok Primitives

So the easy deadline came and went (well almost. I was extended to Monday), and I now have an ok amount of XP. I still need more to be able to write the midterm though.

I feel like we have A LOT of work to do. Havok isn't exactly the easiest thing to figure out. In fact, good luck with that. May the programming gods help you. We all have to wrap the Havok skeletal animation system as a requirement and I think that will be quite hard.

I've done the "Boucing Ball" easy question where we have to make a ball bounce using Havok rigid bodies but not use the hkx and fbx loaders that are included. To do this I had to make a Havok sphere and a hard surface for it to bounce on. Then I had to place an Ogre sphere and plane where the Havok objects were. Havok objects are invisible except, according to Dan, in the "Havok Visual Debugger". I haven't tried using that though.

Now I had my visible objects and collidable objects but nothing was happening because Ogre and Havok don't talk to each-other unless you make them. So even though my sphere had mass and was affected by gravity in Havok, it was just a sphere mesh in Ogre. This was the hard part. I was trying everything to make my sphere move. I had no idea it was moving in Havok because I couldn't see it when I ran my program.

Then Harry, who was also trying to figure out this question, thought "hmm...maybe it's moving but not moving the Ogre object with it". So I hacked it and finally got it to work.

This is what I did:

1. Make Ogre objects (or load them in from Maya as .mesh files) and attach them to nodes. Position them wherever you want, but keep in mind you'll have to move your Havok objects to the same positions.
2. Initialize the Havok World and Havok Scene Manager, then lock the world. (This should be done for you by the project generator but I thought I was initializing the world wrong and spent lots of time re-initializing, just to have to comment all of that out). 
3. Mark the world "forWrite". This allows you to change things in the Havok world. If you don't do this you get errors because the program can't touch anything in the world. 
4. Make an hkpSphereShape object and give it the radius of your Ogre sphere. 
5. Set up the hkpRigidBodyCinfo for the sphere shape. Give it a mass, a shape (the hkpSphereShape you made earlier), friction, and set the motion type as hkpMotion::MOTION_SPHERE_INERTIA. You should also set its position and inertiaTensor (not quite sure what that means, but look at the Havok demos). 
6. Make a rigid body. Yup, all the steps before don't actually give you a rigid body. It's just setting up the attributes of the rigid body.
7. I activated the rigid body too, just to make sure it'll move as soon as my program starts. 
8. Add the rigid body entity to the Havok world.
9. Do steps 4-7 for the plane. I used hkpBoxShape because I don't know how to make a Havok plane. Also, note that giving something a mass of 0 will make it stationary. 
10. Unmark the world "forWrite" so that the program knows you're done writing stuff in the world.
11. Unlock the world (this should also be done for you by the project generator).

So now we have everything we need. The Havok sphere is falling onto the plane and bouncing but you can't see it. To link the positions, I made an hkpVector4 to store the position of the ball rigid body. Then I set the Ogre ball node position to the values stored in the hkpVector4. This is harder than it seems just because Havok is so convoluted. The way you get an x value out of the vector is like this: myVector(0) , or myVector.getSimdAt(0) . Y is at 1, and Z is at 2. 

And that's it. The only thing I have a problem with is WHO THOUGHT IT WAS A GOOD IDEA TO CALL GETTING THE X VALUE "getSimdAt()" ?! 

Game Design 0.4

We're at the stage where we need to start thinking about how we're going to design the levels for our game. Since our game is in space, the level design will have to be different than for a game that has a floor and walls. That doesn't mean we don't need to put effort into designing the level. The player still has obstacles to overcome and a goal to reach.

Space is endless, but the Havok World isn't, as Harry found out the other day. The Havok world space is defined by the .hkx file which you export from Maya. It creates a scene with Havok objects that correspond to each of your object meshes in the scene. When it does this it also limits the world to a size that fits your scene. After you load everything into TwoLoc and make it run successfully, it becomes apparent that if an object exits the Havok world, the program crashes.

Dan Buckstein explained that some games get around this despite having an "open world" by killing the player if he exits the world and re-spawning them in a different location. Take Battlefield 3 for instance; if you get near the edges of the map, you receive a warning to return to the battle and a countdown. In other games there is a winding track and nothingness beyond the track. If you fall off the track then you are re-spawned somewhere on the track before you fall off the Havok World. Those measures were put in place to prevent the game from crashing really hard.

Our game is in space though. We want it to feel vast. I'm not sure how we'll constrain the player. Perhaps we will move everything around the player while he remains static? Perhaps we will place invisible walls that you cannot cross? It would be hard to tell if you are moving or not in space unless you are heading towards other objects (such as spaceships or asteroids) which would be at the center of the world.

The goal of our levels are centered around destroying the enemy mothership while avoiding being destroyed by the enemy fighters. There will also be asteroids that the player must watch out for. We will probably place everything in the middle of the Havok world, so that the only way the player would come near the edges of the world is if he was fooling around with the game and seeing how far away he could go. Still, we must prepare for this. Exiting the world is a game-breaking error. No one is allowed to leave.

Engines 0.3

So this weekend I completed two more homework questions. I feel like I'm almost getting the hang of adding objects and materials now; almost.

For some reason animated textures just don't work. Ogre supports them (or should) but I have tried numerous things to make it work and it just doesn't want to. It should be as simple as adding one line of code into the material file, but nope. And on top of that it doesn't give you any errors. Not one. All of the files are loaded in fine according to the OgreLog.log file so I have no idea what there is left to do. I gave up on that question.

Speaking of the OgreLog file, it proved quite useful when I first tried to load in materials. It tells you the file paths where it searches for .material and texture files. That made me realize that file paths must be absolute or based on environment variables, otherwise they do not work. You know how Visual Studio accepts paths  such as $(ProjectDir) and $(ConfigurationName)? Well Ogre doesn't let you do that as far as I know (or maybe I'm using the wrong keywords).

.material files are cool. You can do all sorts of things in them (searching for how to fix the animated texture, I found quite a lot of documentation on Ogre material files  http://www.ogre3d.org/docs/manual/manual_14.html#Material-Scripts ). You can call Ogre's shaders, and play around with  culling and alpha blending and much more. The only problem is that a lot of Ogre's documentation is not very "noob friendly", meaning that if you're searching for a specific function, you will find what you need, but if you search for the process of doing something which requires many functions, it will be much harder to find.

It doesn't help that sometimes on the Ogre forum, when someone asks a question - for example, how to make a billboard - all of the replies are "check out the documentation. It's easy" and link you to something that looks like this:

Very easy to use documentation for someone who's never made an Ogre billboard

So yeah, it's not always easy to find what you need, but the internet is vast.Somewhere, if you search hard enough, you will find the spinets of code, or clear explanations you need - http://www.ogre3d.org/tikiwiki/tiki-index.php?page=LightsCameraAction#Billboards_and_Materials. Don't expect everything to be easy to find.

*****

On an unrelated note, I remembered this: http://www.youtube.com/watch?v=tguqmbaqNPA at 9:21

Catbert: And Alice, you need more time, but that's only because you spend so much time on your hair and makeup in the morning.
Alice: That's a necessity.
Catbert: Only in your mind.
Alice: You mean, I'm beautiful just the way I am?
Catbert: No, I mean, it's a lost cause. You should put that time to better use!

To put this into perspective, I need to wake up over 2 hours before class starts to get ready in the morning. If I didn't spend time doing my hair and makeup I could probably save myself 30-45min. I know it's a waste of time, but I just can't bring myself to not to do those things in the morning - except maybe during crunch. Actually, even when I've pulled all-nighters I sometimes brought along my hair straightener. There are some things I can't compromise on

Game Design 0.3

*Note: I'll just start organizing all of these posts like this.

So this week we had to make Portal 2 levels. Since we were working on it in our GDW groups, we split up the requirements. I was in charge of making sure that the level had turrets that would be pushed into goo, two different types of gel and a T flip flop (more about this later). Sadly, I had booked a dentist appointment for the day of the presentation (I thought we would be presenting in our tutorial, not in class) and will get no marks for this. Still, that's ok. It's one assignment and, well, I would have lost marks for my group had I spoken in front of the class.

Public speaking is not my forte; nor has it ever been my forte. To give you an idea of just how poorly and awkwardly I express my ideas before a crowd, I shall give you an example. On my report card for grade 6 or 7 or 8 I clearly remember getting a 62% in Drama/Public Speaking, a 56% in Gym and 85-95% in pretty much everything else. But I guess that's why I chose game dev. I thought I would sit in a tiny, enclosed space devoid of windows where I would work all day and not need to interact with other humans except for the ones which I manage to not be awkward around (my friends).

Unfortunately, as every member of Squabble studios pointed out to my friend who said MIGS would not be worth going to due to the exorbitant costs, "You need to know people to get anywhere in the industry". I have also heard this said by many other, more experienced people. If this is the case though, it saddens me, for that means that a man is not judged by the skill with which he manages memory and produces magic from lines of code, but by his ability to socialize with other humans; a skill which is based mainly on talent and does not help in communicating with computers at all. If that is true, then perhaps I should give up trying to become a better programmer and artist, then buy a house somewhere in the country and bake pies all day. I will not give up just yet though, and hope that someone will hire me based on the things that I can do well.

Even though I will not get a mark for the Portal level I made, I still had to make it, which took some time. The thing that caused me the most problems was the "T flip flop". At first I though, wtf is a T flip flop? I searched it on Wikipedia, which showed me diagrams of electrical circuits that were way beyond my knowledge. So I asked my mother (she has a degree in Electrical Engineering. So does my father, but he was harder to get a hold of that day) because I thought that she might know. In fact, she did know.

My T flip flop gate in Portal

A T flip flop consists of one input, one output, and a clock of some sort. Imagine it like a black box with      a button attached to it at one end, and a light bulb, door, insert object here, attached to the other. When the button is pressed, the clock ticks. As the clock ticks, the light bulb, door, or insert object changes state (so if the light is off, it will turn on; if the door is closed it will open) and does so over and over. So each time the clock ticks the light turns off, then back on again then off again. The clock stops when the button is no longer pressed. Everything stops moving and changing when you step off the button. This means is the light was on when you stepped off the button, it will stay on. If it was off, it will stay off. That is a T flip flop gate.

Here is the very helpful picture of it on Wikipedia

Engines 0.2: I Hate Distractions

Ok, so we have our GDW teams all set and our game idea worked out. We have everything we need to get started on making a game. We have so little time and all I want to do is sit there for hours every day working on it. But I can't. I have classes and assignments which don't pertain to GDW and this saddens me a little. It breaks my focus and makes me much less efficient. It also takes time to complete assignments. Precious time I could be putting into working on the game.

Lectures aren't a bad thing. You can learn so much just by listening. I just find that I am much less productive during the school year than during the summer. There were few people in the lab in the summer, giving me a nice, dark, quiet place to work. And there was no reason to leave, so I could stay as long as need be. Walking from class to class, then having to get settled all over again, searching for somewhere ideal to work, and taking time to do assignments slows down our game production.

Another problem is the way my brain works. I keep a list of the things I need to do in a .txt file in my head. Unfortunately, I have to constantly keep it open so that I can see it. This takes away RAM from my daily tasks. The longer the list, the less RAM there is for me to put to use actually doing the work (my mind does not do very well with multi-threading so I have to pretty much just do one task at a time). If I have to focus my attention on 5 different assignments, keep track of when they are all due and what I should be working on, while still remembering to complete ......the Game Engines homework questions, I lose my train of thought (just like I did back there, while writing this sentence).

It would be so nice to methodically take each task and use my entire CPU power to complete it, then delete it from my mental list and move on to the next task. Unfortunately, this is a luxury we do not have. The closest we can get to this is spending all Saturdays and Sundays in front of a computer, working undisturbed.

Our games could be so much better if we just sat and worked on them all day every day. Sadly, we still have much to learn so we have to send most of our time learning how to better make games instead of actually making them.

Game Engines, Summed up by Memebase

Why I Think My Game Idea Sucks

One of my friends posted this http://www.escapistmagazine.com/articles/view/issues/issue_221/6582-Why-Your-Game-Idea-Sucks and I instantly thought "YES! Thank you! Someone actually said this!" Now, I'm not hating on everyone's game ideas, I just think people get too attached to their idea and refuse to start making it until they know it will turn out to be exactly what they want it to be. This causes them to wait, and wait and wait, for the AAA producer and the programming team that made their favorite childhood games to come along and make their game. But this has almost no chance of happening in the real world, and their brilliant game idea never gets made. This is why I've given up on thinking about the best, most innovative, meaningful game I'd want to make. It's just never going to get made.

As our first year Creative Writing professor said "You have to kill your babies". By this,she meant that no matter how great your idea is, it may not be good or plausible in the real world. Think of it this way; even if you are the lead designer at your own studio, your team may not be skilled enough to bring your dream to life. And unless you are a mufti-millionaire you will not be able to afford the best and brightest in the industry.

That's why "If you want something done right, you have to do it yourself". Actually, if you want something done, you have to do it yourself, and while you do that, realize that there are some things you can and cannot do. The best way to make your brilliant game idea into a game is to start making it yourself. Don't wait for the planets to align and floods and plagues to take out the people who are in the job-positions of your dreams. Just get programming and make your game. Then you know for sure that it will get done (if you work till it's done and don't quit). You can even get a small team together to help you if you have the funds. But know that it will not be easy. Know that it may not turn out exactly how you'd dreamed, and learn to accept this.

People see things like "Indie Game, The Movie" and think "oh jeez that sounds hard, but they made it big so I can too". I don't think it works that way though. Take a moment and think about all of the people around you who would like to try to make their own studios and games. Now think of the indie developers in the industry that have made it big. There don't seem to be very many compared to the people that must try to make games. They think "Oh, it's easy and fun. I can totally make millions". There are so many things that could go wrong and so many obstacles one must face to make a good, successful game that gets published and widely distributed. The odds seem incredibly low.

That's why I don't particularly care what games I make for GDW, because all I want to do is make a game. That's why I'm here. It doesn't matter if it's a first person horror game or a maze game or a space shooter. It doesn't matter. Art assets need to be made, levels need to be designed, and most of all, the engine must be programmed and scripted. That's what I'm here for; and I know our game won't turn out perfect.

Engines 0.1

This is my first thought about TwoLoc. 

 

I'll bet Dan and Saad are smirking about it in the Grad Lab. But seriously, I feel like the errors in TwoLoc are much different than anything I'm used to encountering. I'm used to errors in my own logic, bad syntax, and vectors being out of range. Now I run into linker errors, and weird include errors that I have little to no idea how to deal with. 

I have to admit, when we first received the engine I didn't want to touch it. I thought if I would so much as write a comment, everything would explode in my face. TwoLoc is a three-headed beast; one is Ogre, one Havok, and the third is a much larger head, with monstrous arms and legs, that seemed to have absorbed the  other two (please don't take this offensively, I just see it as something that I have to gut so that I may rearrange its innards). Now I've never slayed a three-headed beast, so I didn't really know where to start. Actually, I was completely lost and thought it would take me till the end of the semester just to get one easy question.

Luckily, Harry always finds a way to make me feel like I can do stuff that I never thought I could do. And that's what he did.  He gave me a sword to slay the beast (he convinced me I could do it if I tried), so I started stabbing at it. I stabbed away, and now I almost have a question to show. The Ogre tutorials help a lot too. They tell you where to sab to cause the most damage. 

I feel like at least now I'm not terrified of TwoLoc anymore. And that's a good thing, because there are a lot of questions plus a game to make. 

Bad Design (and Horrible Menus)

I'd like to start by saying sorry for this rant. It's no way to start a blog and I don't even know if it counts towards marks for Game Design or if it's too early for that. It is about design though. About how I hate the new design trends and how they make my life horrible and impossible.

Ok, maybe it's not that bad. But if it takes me more than 10 minutes to figure out how to find my program files then I will get quite frustrated. Unfortunately that's the direction that design seems to be favouring these days. I make myself sound old by remembering the good 'ol days of Windos 95, 98 and XP. Those were much simpler times. Everything you wanted was right there, labelled and organized...in a list....that you could read. Everything had a place in memory and a path that was clearly traced to it. Now, I may be biased because I grew up with these operating systems and know them well, but everything was so linear and straight. You had to dig through folders sometimes, but the search option was always there.

Nowadays everything is pictures and colours. Everyone tries to make things flashier, shinier, "more intuitive" and easier to use but to me it just seems more and more jumbled and bloated and uselessly complicated. Take, for instance, Microsoft Word 2010. The bar at the top is huge, which means I can see less of what I'm typing. Everything on the top bar is pictures! Pictures! I don't read hieroglyphs. I read words. Words make sense to me. A box with squigley lines could be anything. And figuring out what the pictures mean takes far, far longer than reading. And you might say "well I know what the pictures mean so it's easy for me". Yes, you've memorized pictures. Good job. You've also wasted a lot of time and if you don't use Word for a while you'd have to re-learn all of the pictures again. UGH!

The worst menus though, are organized in a table, which makes it so much harder to find something. Is it organized alphabetically horizontally or vertically? Who knows? Maybe it's just randomized and different each time. Because every busy person loves playing that game when you have to match pictures.

Then they made that abomination called Windows 8. As if the Mac OS wasn't hard enough to navigate. I once spent half an hour trying to scan something in the school computer lab because the Mac just saved my files in a random place that I couldn't find. I had no idea what picture to click on for "default file location". That's a pretty abstract concept. I challenge you to draw a picture that describes that to someone.

But I guess this course is teaching us design for games, not operating systems. Games are different. You start a game expecting it to be flashy. You expect to have to explore its intricacies and not know everything right away. No one gets on their computer and thinks "Well, I'm bored. Time to explore the workings of my operating system and find where my word processor ran off to. And maybe I'll sit here and admire the shiny buttons for 10 minutes".

That being said, games should also have interfaces where it's easy to find what you are looking for. No one wants to sit there for hours trying to find how to switch the weapons in their inventory or buy an upgrade for their character. At the same time though, it does look nice if things are flashy as I'm in no rush to put down my game, and besides, it's nice to explore a little sometimes.

One notable problem I've had with games is that I could not figure out the controls. I would press every button on the keyboard and not find what does what (*cough* Limbo *cough*). All games should at least have some sort of place in their menu where they state their controls if they do not teach you how to do things. Also, if the HUD is not very clear, or the inventory is hard to find, their locations and purposes should be stated somewhere or taught interactively.

Interactive tutorial levels are pretty awesome, or at least I think so. I'm glad they take my hand and walk me through everything before they throw me in with all of the pros that have been playing the game non-stop for eons. As long as it's kept short (or optional) for the people who know what they're doing, it helps greatly.

I guess I don't always realize how important design is. It can mean the difference between someone buying your software or not - and the difference between someone buying your game and recommending it to someone or smashing it to pieces in frustration.