P4 Post Mortem

Prototype 4 was an interesting one to work on. We were able to work in a larger group and we had an engine to work with. However we also had no client (other than our teacher) and a lot of work to do for other classes.
I made a prototype of my vision of the game, which I had been thinking about for some time, over the first weekend. Not sure how that turned out since the other programmers didn't seem to be able to wrok well with the already made system. Although it seems like that is what id going to happen a lot in the industry. You aren't often going to make something from scratch, but instead take an existing system and add a feature to it. However I may try to leave more of the easy parts of a game for other people to get their feet wet with it. Because it makes sense it would be hard to start with making the new feature to the game instead of the basic, how do i move a box around part.
Next time I get into a lead position I will want someone else to deal with the people, and making sure they are doing work. While i can help with the technical how to get it to work. But i am not good with actually getting people to do work. I also felt bad leaving the class too many times being the lead.

Wroking with an engine

I really shouldn't have spent some much time working on the prototype this weekend. But it was quite a lot of fun. The biggest thing that I saw through using an engine was that we need more artists. An engine is made by programmers so that non programmers could make a game (not the whole thing but most of it). For example an artist or designer could make the particle system of the energy ball that the user fires. Without an engine a programmer would need to make that particle effect in code, but with the engine it is all buttons and values. The big thing that made me notice it was that i suck at making things look good. I was able to make everything mechanically work, but balancing and the visuals are not things I am very good at.
Since we don't have many artists and are going to make a game. The producers really need to learn to use the engine and be able to do basic things in it (like change values, change the map, and add in game objects). This isn't just because of our lack of artists even, if the producers want to be game designers they need to be able to use an engine anyway.

a late post-mortem

This last project was the most successful in terms of development. We had a more defined process for development that mimicked the stages of development of a full game. Our pre-development stage lasted three days. it started with us talking out ideas on Monday. Then on Wednesday we talked some more and had a physical prototype (or whiteboard prototype). The difference was the physical prototype which was extremely helpful. It helped with two problems. One was it solved some simple problems we had with our development ideas that we did not notice until we saw them. With that it more fully developed the ideas out and gave us what the actual game would do. So instead of saying you can have a conversation with an npc, we decided one buttons for the answers. Also that the npc has his/her response show over their head and you have a certain amount of time to click one of the response buttons. The other problem that the prototype helped with was everyone being on the same page. A problem I have had in other groups was someone develops a feature and it isn't what I was expecting, or the other way around. This problem wasn't solved, but overall being able to see the game run and go through all the player options in front of the whole group gave everyone a good understanding of the game.
The other good thing about this prototype was that we decided from the start to have a working game at the start of the third week. This gave us a chance to look at the game and see what was fun and what wasn't. At this point we decided what needed to be in and what didn't. Also what would make the game more fun. Then we spent that last week doing that one iteration off of our initial game.

man i don't like blogging

we finally did a bit of playtesting (kinda since it wasn't with anyone else) and I think it went fairly well. I have learned a lot from doing the prototypes, the biggest thing being that we need to work and plan together. Doing the physical prototype at the start of the project i think helped everyone get on the same page about how the game will play and how the components will work together. And this first iteration I thnk was also helpful to do. It took a lot of time and could have been more useful, but I still think it was worth it.
It allowed us as a group to see the game and comment on what we need done. I feel like we probably spent a bit too much time on specifics of what we want in the game and less on the fun of the game. We did talk about how we think we can make the game fun a bit. So we do have an idea on what to iterate to find the fun, but I felt it was more vague than I had hoped. So maybe we could have spent more of that time on what would make this fun and less on specific components to implement. Although we needed to discuss those things I think they could have been discussed offline between just the programmer of it and the designer. Although this would take out the rest of the group from the design of that component.
Overall I am happy I have finally iterated on a game at least once (or in the process of the first iteration after the creation of the game). I also feel like we could do this iteration process better, and that even just this one try will allow us to do better the next time.

Using a texture for data

For coloring the world I was putting the color value into the vertex. then in the pixel shader i would multiple the color by that color percent. this worked, however it depended on the size of the triangle and even more importantly it required changing of vertex data. So I had a dynamic vertex buffer and was setting data to it each frame. However this became a problem when the grass was added as it had 17 vertices and 84 thousand objects.
So after reading an article about GPU particle systems from Jon, i realized I could use a texture to hold the color value of that area. The texture would be like a grid over the world such that every spot on the world points to a pixel in the texture (which holds a float of its color value). I can calculate that location in the pixel shader (or vertex shader for the grass) by (position.X - minWorldPosition.X) / worldSize.X. Then i can do the same for the Z axis. I do not consider the Y axis for this, although i could use a 3D texture if i wanted to include the Y axis.
The nice thing about this is to change it i do a draw call and the GPU handles it (which is very optimed for exactly this). I have a circle in a vertex buffer which is what i actually do the draw call on. I set a scale and translation matrix for that circle in the shader so the circle will be centered to where i want it and the size i want. I wrote the circle's vertex positions in screen space (which is really texture space) so i only needed to scale and translation, not project.
This would set all of the values on that circle to the color percent. However i also wanted a gradient. So I used the Z value of the vertex position (of the circle's vertices). I wasn't using the Z value because i was drawing right to a texture of floats, aka i didn't have a depth buffer and so wasn't doing any depth testing. I set the center of the circle to a Z value of 1 and the outside edges to 0. Then when the pixel shader got that value it was between 1 and 0 for how far out it is from the center. Thus i can set it darker or lighter according to how close it is to the center.
Then for lighting the world i used an alpha blending of Max. Where it would take the larger value between the value i was setting from the draw call and the value that was already on the texture. And for darkening i used a Min alpha blending.

Overall this helped the efficiency of this tremendously. Although the grass itself still needed more optimization (such as cpu visibility culling). But i learned a lot about shaders doing this process and any time i need to pass a lot of dynamic data to a shader i will first look into using a texture.

Change in philosophy

This weekend was interesting for making the game. we had a working version of the game but it was very simple and did not feel like a game. The giant just walked around and the lanterns were simple. However Sagar is working on the giants and Jon is working on the lanterns. So i decided to take on atmosphere of the game instead of gameplay mechanics. To do this i made grass that moves by wind and snow.
The grass was interesting to make, at first i made it without it moving. but grass that does not waver at all looks strange and not like grass. So I made it bend. However i made it bend away from the player so the the wind is coming out from the player. However when an object is bending away from you it isn't easy to tell what it is doing because the only real change you get is that it gets shorter. So the grass looks like it is just getting shorter and taller. Also i have them all oscillate at the same time which is also not how grass works. Wind as it goes through makes the grass bend in some local areas and not bend in others. So i need to implement the bending of the grass using a sine wave that will move through the area. Overall it was good because i am challenging myself in making both the particle system of the snow and the grass.

Starting with a new project

This is an extremely interesting project. For the second time we have a client that does not have anywhere near a set idea of what they want. For this client they may not even want a game. I think they would be happy with even just an interesting virtual world without game objectives in it. But being left with very open options could provide for very interesting ideas from the groups. Overall the project is awesome because of the technology we get to work with. We are going to be the only four groups developing games for this technology. Also the project is grant funded, which means we have a good chance at continuing work for this after the prototype ends. People more easily give grant money out than their own money from my experience.
The other part of the project is the team I am working with. I remember taking note of Jon when we came into the game design class as he seemed to really know what he was talking about. It is still my dear wish to have him on the project team I am on for the really game project. I had also wanted to work with Sagar because he seemed intelligent and inquisitive in regards to game programming. He had come up to me a few times in the past weeks to ask questions, which shows he isn't just here to get through it. So I get a group with two engineers whom I wanted to work with during this prototyping projects course. Then Andrew I had already had a few good conversations with and he really seems to know technology quiet well.
Although the one downside to a team this god is that we have a hard time coming up with an idea for a game. But hopefully they figure something out, all the ideas we have had are good ideas. And any game idea we come up with I think will turn out well as long as we keep it within scope.

Post Mortem

The project went well overall. I was able to learn some interesting things about game developement and just working on a project in a team. The main thing that I learned from doing this project was that we need to not try to do too much in the last part of the project (in crunch time). Trying to add so many things right near the end ended up making them not very productive. If we had chosen one thing to work on then i think we could have put that one thing into the game and done it well. However trying to doing three to four things for the game in the last few days ended up hurting our productivity for those last days.
Another important thing is that I learned further the importance of a version control system. Even if we don't use a program for it, we should set an exact way we are going to handle version control.

One other thing is that the other engineer did not get involved in the project until alter into it. I am not exactly sure how to make sure we are both working on the project, but at least i will make a consorted effort to have both of us working on the project early.

Third Week

This week was good, which is needed because it is the last week of development.
I was able to load in the level after some time. I had to go back into the fbx loading and bring in the rotation and scaling of the objects. Then when loading them have moai do the rotation and scaling.
I just made a separate collision object for each piece of cheese instead of doing something automatically. For the collision object i figured out I could just take the aabb info from it instead of the geometry. Then for collision detection i just did a point vs aabb. So the game has collision detection and still runs smoothly. I was also able to load in animations. Although i did it in a very inefficient way by having each frame of the animation put in a different picture, then just flipping through the different pictures. This makes the game load about 17 mb into memory but it still runs quickly.
I ran into some strange problems when doing animation stuff though. The game would just crash, at the same point every time, without an error or any reason i could discern. Then i would add a print statement above where it crashed and it would work. So i have a few print statements which i think is slowing down the processing long enough for the data to actually load.

Awesome work by someone to get sound to work, apparently it was just linking directX to that project and then compiling it. But for a bit of work during the final week it looks like we may put sound into the game, at least some. Although he said there is a delay from when you play in the game to when you start hearing it. So that would make it so we can't do a sound by reaction, like every time they hit a piece of cheese. But we can at least have background music.

second week

Second week got a lot done. Was able to get a level parsed from fbx and loaded into the game.
Figaured out that if you have the unform World_Transform then MOAI will put the objects world transform into that variable in the shader. So i am able to have one piece of geometry copied around the level. Still don't have the ability to run a character through the track or to pick up cheese (or have cheese in the level).
I tried to work on sound but it was strange. The guide said you link directX to the project and then compile. However it was able to compile without directX linked, which means to me that something isn't set for it to try to include sound or I just have the wrong project.

next week I'll start to really make a game, Damean said he will get me a level and i'll then work on loading that in and doing collision detection. Then I can start working on features like scoring, menus, animations.

First Week

Exciting first week of classes. First time I have been happy to go to school do class work.  Two of my three classes are programming and both are very challenging, so I am very excited about working on both of them. The game design class will be fine if we can get into a significantly better room (like the lab).

Working with MOAI has been most of the work done this week. The game we decided on is going to be 3D, however MOAI only recently added 3D capabilities, and they are still underdeveloped and under-documented. There are no tutorials for doing anything in 3D. However after a lot of digging I was able to find a sample that was in 3D, and understand how it works thanks to game engineering 2. However their shaders seem very basic.

I cannot figure out how to set a shader's uniform variable differently for each object. I can set the uniform, but I cannot tell MOAI when to render an object. I need to set the variable, render one object, then change the variable and render another object and so on. So since it seems that MOAI lacks the capability to explicitly render an object (everything is just added to a big list and all rendered at once), I will not be able to have objects in object space. All of them will have to be in world space. This means that every object will have to have its own mesh and place in the vertex/index buffers. So if we have 1000 pieces of cheese, there will be a 1000 of them in the vertex buffer, instead of one that we just move to a 1000 places.

So it looks like we will be able to make the game, although if I hadn't taken game engineering 2 I don't know if someone else would be able to do the 3D. However I am very concerned about if it will be too much processing or memory for the capabilities of a smart-phone (specifically the less smart smart-phones). But we will see, and maybe if we run into low FPS problems we can look into cool tricks to improve it.