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.