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.