Team PacMan - Third(Part 2)&Final Week + Post-Mortem

It's been a long time since I last wrote my blog. It's just been too busy and I got too attached to my current prototype. Now that it's nearly finished. I finally got the time to look back on my last prototype, Crusaders.

First of all, I'm really glad at the fact that the clients actually liked our game, as a game(don't know if this makes any sense =_=!), this really means a lot to our 4 week's work. But there is still a llot of things that could be done but hadn't because of the limit of the time and also because of the fact that this is just a prototype. 
For post-mortem, the team, as always, has some issues. Take communication for instance, although we exchanged a lot of messages and emails, I still got lost track with the other engineer. And we both agree that we should have talked more about the game structure during the second and third week. And our game idea settles fast, maybe too fast (2-3 hours on the first day, we already all agreed on making a 3D Pacman-like castle game), but I'm pretty happy with the outcome though, maybe it's because the idea itself is awesome! ha!

As for myself, there is a lot to improve and talk about, I'll just do a post-mortem and summarize mixed-up here:

Shaders are amazing, it's fantastic to see how a few lines of code could actually change a lot of how the game would look. I actually had big plans on learning and writing the shader of this game during the fall break, but the lame work of laying out all the gems and fixing the models took me more time than I thought and I only had the time to do the point lights using prelighting, which is already a highlight of this game. And this is something definitely worth dig in during Thanksgiving or winter break.

But the main thing I'm gonna talk about here is optimizing. This game is actually the first program that I wrote that actually get a performance hit, which hurts me so bad it actually changes the way I think when I'm programming. Yes, we're all kind of raised by education that we must keep a good programming practice and write efficient code. But it's a total different thing to "know" it than actually facing it. When you go through all your code, adding and cutting logic statement to avoid unnecessary loading, simplifying math calculations and changing structures for memory and time saving just for raising ten frame rates. You kind of become vigilant about this kind of stuff. So now when I start writing anything, I always get these questions stuck in my head: What structure should I use? Is this the best way? What's the prior concern? Is it fit for the possible future use? I'm glad I'm thinking about these stuffs now, although it kind of slows you down at first, but it really makes things easier for you when the project grows big, at least that's what happened in my current prototype. All thanks to this. 

I actually thought a lot about how to optimize this game, and I wrote something about it two weeks ago, I'll just copy and paste it here you want to check it out:
"Recently I have thought a lot of stuffs about optimizing my game. Should I update my frustum culling to triangle accuracy, so that I could use a vertex buffer to draw primitives instead of using draw models, which could be more fast since shaders deal with vertexes directly and it also provide me a way to send vexters to GPU by batches. Also, is it wise to use the same octree for both collision check and graphic culling? Because for many times many things you see shouldn't even be considered for collision check, and load them into the octree are simply a waste of memory. And also, some shapes are too delicate for collision check, like for pillars and railings, sometimes what you need is really just a cuboid or cylinder. I know that sometimes a bounding box or bounding sphere can do the job, but in order to get a smooth collision reacting, you still need to use all the coordinates of those stuff to recreate the triangles to get the normals and plane, which is actually easier to achieve if you just replace all those models in the scene with simple shapes that you think the collision accuracy would be. But to achieve that, the overhead is you need actually two versions of scene models to load and two tree structures to store. But considering the cost of not doing all these, it's actually worth it. And again, for math, right now for all the ghost, I actually determine all the x,z speed by sin and cos of the rotation from the x axis. But for the patrol ghosts, is it really wise to calculate sin and cos for every frame they move? For the visual rotation, I can just add a bool at their rotation point, so the model will only rotate every time they reach the rotation point. Which will reduce a lot of math! 
As for framework, am I using the most efficient data structure? Should I use interface or class for base model? And maybe it's better to use a quad tree for collision check since height value is really not a concern of collision. 
All those questions and stuffs are stick in my head, but right now I really need to consentrate on the HTML5 since that's what my next game will be."

Well, I'm very glad to be able to work on this prototype, it really gives me a chance to have a glimpse and have a "dry-run" on most sides of 3D game programming. It's ironic that the more I learn, the more I find out that I don't know anything. There are still a lot of things for me to dig in, and time is indeed a luxury here.

BTW, writing blog like this is really suffering, hard to read and time consuming, I'm gonna try a different approach from now on.

-Max

Team PacMan - Third Week&Fall Break

These two weeks are really tough. Thanks to the fall break, I really got the chance to move this game forward, instead of just leaving it as a rough prototype. I'll break it down into four parts:

1. Shaders:

I was planning to dig into shaders these two weeks but many other works (the other three parts below) came in and I only had enough time to deal with lighting shaders, which is a core mechanic in this game that I really care about. In order to have gems in the hall to guide your path, you have to make the gems shine up the whole area, which is achieved by point lights, a lot of point lights. Since each gem has a point light, this kind amount of point light would kill the performance because the renderer would recalculate the whole scene for each new spot light added in if you are using a simple light shader. After searching a lot of tutorials, I found and used a prelighting renderer, which use a normal and depth shader to output these two values from the models in the scene, then use these two values as an input to draw a light map using a lot of sphere models (the number depends on how many point lights you have), and finally use the light map to draw the scene. So in this case, you don't have to do any math for lighting if your scene is not changed, which really speeds up the game a lot. I also added a blood-red fog effect into the scene, which is really easy (All you have to do is change the pixel shader, add a amount of fog color to the output color, the amount is determined by the distance of the object from the fog start point.). And this is what the game looks right now:

 

2. Models and Textures:

I think I don't have to address how important graphics is to 3D games, that's why I spent more than half a week fixing, adding the models and attach textures to them. I don't know if it's a Maya to 3DsMax thing, every time I load Nathan's model into 3DsMax, all the normals of the polys are really messed up, which takes a lot of time to fix. And in order to add more castle feelings to the scene, I added a throne and a bunch of banners in. I also changed the sword model since the last one was too simple and copy-paste a few half walls Nathan made (to form a maze) between the pillars according to the design we had originally in a few sections to make the game a little bit more challenging.

But the hard part is texturing. In order to have a dark-medieval theme, you have to be really careful to choose the textures. It can't be to bright or it will destroy the feeling, but it also can't be too dark cause it will reduce the dignified bearing of the throne hall when it's hard to see which will also make the game hard to play. This kind of textures are hard to find on the internet and I'm really not good at making fancy textures myself. Tiling has also become a issue cause many ploys have irregular shapes and they make textures looking really bad.  

(to be continued...)

Team PacMan - Second Week

There are a lot of stuffs going on this week, and I didn't remember to write the blog till now.

So last week I spent half of the time putting the octree into the code for collision optimizing, which is not necessary because our 3D scene is not big enough to cause performance issues but I figured it would be a good practice to do so. The principle is simple enough and there are many resources on the internet to research on. The hard part is how to merge that structure into our current code structure:

The structure before I merge the octree

As you see, in order to put in the octree, I have to get rid of all the collision check from the UpdatePhysics() function and merge them as part of the octree function. And since all the different classes has different collision objects(some are bounding boxes, some are using bounding sphere, some are formed by triangles), I have to create a new data structure (in my case, an entity class) to store all this collision entities and pass it to the octree. And since the octree is using bounding box to check which child each entity stays in, I have to write two new functions to check the collision between bounding box and triangles, bounding box and bounding boxes, as all the previous collision checks are through the player and the player is using a bounding sphere. But that was not even the hardest part yet, after finishing most of the code, I started to face a major problem: whether to put the player entity into the octree or not?

Well obviously I got two options. The first one is to add the player as one entity of the octree, and for collision check, we go through at least a branch of the octree every frame and get the all the leaves the player entity resides in (the player entity may reside in multiple leaves because it may intersect with several child space). After that, check collision with all the other leaves with the same parent. It sounds good, but the problem is, the player is moving, you also have to update the player entity in the octree for every frame and even re-struct it after the player is moving from one child space to another, during which, you have to go through at least one branch of the octree, again. The second one is to treat the player entity as an outside object and load it into the octree every frame. Then you calculate which leaves the player entity is in and check collision with entities in those leaves. This also means to go through at least one branch of the octree for once each frame and also a few bounding box collision check because you have to check the boundary of the space to decide which child are you in, so the number of checks are actually depending on how deep your tree is. Both way doesn't seem efficient enough for me, but I have to make the choice as I can't think of a better way to do it. So instead of doing a octree go through one more time, I decided to do a few more collision checks because collision checks between bounding boxes are not that expensive.

Normally, you would assume that's the end of it. And the world went dark after I ran the program only to find out the player is falling through the ground (I add a gravity -- constant falling speed -- to the player so he will fall if there is no collision with the terrain). And so there started the endless painful circle of debugging, which actually took most of the time since the coding only took like a few hours. First I got rid of the gravity and found out some collision worked. That's when thought the problem might be the partition process, I started to change the codes that handling big triangles (the triangle of the ground is big since it is flat) and began to keep track of the ground triangle in the octree, but nothing worked. I got so frustrated and desperate that I started to draw the flows of the octree to find out what part did I miss:

Part of The Octree Flow

It's actually during this process did I realize maybe my collision check code for partitioning wasn't working. I didn't think about the fact that the triangle may be so big that it might encircle the bounding box, which was actually bypassing my box-triangle check. And yea, that's the problem.

The rest of that week is mostly adding new game mechanics, there are two small challenges. One is to move a mesh of the model without moving the model, which is really easy when you figure out how to get the name of the mesh; another one is the physics reaction of the player when he collided with some special terrain like ramps and quicksand, as sometimes the behavior of the player was really weird when he collide with more than one triangle. I ended up with filtering some of the triangles that the player collided and using some really simple math equations to give the player a constant speed, since the player's speed could be really slow after multiple projection on the plane. Here is some screenshots of the new features (all triggered by triggers) I added in:

Door Closing

Sinking in quicksand 

Spike-wall is coming!

 At the end of last week, our artist sent us the model of the throne hall, I tried to add them in and found out most of the normals of the triangles in the scene are inverted (this took me a lot of time to debug as I first thought the problem was the collision detection). Which was making me nuts since most of my physics collision reactions were based on the direction of the normals, as I mentioned on the last blog and this kind of destroys my collision system. I talked with a few person and tried to find out a more generic way to ignore the direction of the normals, but nothing worked well. I ended up with manually flipped all the normals in 3dsMax by myself (It needs to bedone anyway since most of the textures are also inside-out) and got this to work. I also added a rear view camera, which is really simple, just add a new camera facing the opposite direction and draw everything twice.

Throne hall with rear view camera

Moving next to shaders and I really should sleep at this point...

Team PacMan - First Week

Team:
Producer: Zeph
Artist: Nathan
Engineer: Yuntao (Owen)
Engineer: Max (me)

New project, new team!

This time we are creating a 3D game for a lab in the university of utah. 

(Quoting Zeph)Our client is a physical therapist working with a project called Treadport. Treadport is pretty much a giant treadmill with three, eight foot screens placed in front and to the sides to help people with recovering spinal injuries learn how to walk again. The technology pretty much allows the patient to walk on the treadmill while being harnessed in so the person can walk through a virtual world on the screens. This helps them recover better as well as keeps the patient motivated to keep wanting to come back to their physical therapy.

This is kind of  a challenge since I literally have no 3D game programming experience before, but considering I had no idea what MOAI is a month ago and we still made a pretty nice game, I'm pretty confident that this is not a big deal either. And the fact is things turned out just fine.

As we're using the SCRUM process this month, it's perfect for a different programming approach which I mentioned last week that I want to try. So I discussed the framework with Owen (which is important because we didn't do that on our last prototype and everyone is very vague about what they should do), divided the work and went "solo". Since I'm on a pretty tight schedule, I won't write much detail on the framework for now. Since the simulation is the most important thing, I want to spend most of my time working on improving the graphics. And this means I have to finish most of the game logic this week, thank god I know a few things about modeling, otherwise I would have stuck. Right now this is what I have for the first week :D

First Person View

Terrain geometry collision detection

The collision detection system is nearly completed, and I've successfully detected and responded the player's collision with ground, static wall, ramp, pillar, and simple objects like ghosts and swords. For the terrain geometry, I'm using the triangle-ray check and using this equation to determine the direction of the player's velocity:(Thanks to Jon, he really shows me some direction for this)

Velocity = Velocity - Vector3.Multiply(normal, Vector3.Dot(Velocity, normal));  

This just simply project the player's velocity on the plane of the triangle. No big deal. As for other objects, since it's too expensive to do the triangle-ray check, I'm using AABB to determine collision with ghosts and other collecting stuff. And it works pretty well for now. I won't put much detail about what I did each day cause I did so much stuff this week that I've already lost count : P

There are still a few tiny things for the game logic and I'll try to finish them at the first half of next week. Jon also mentioned to use an octree or a 3D uniform grid for partitioning the terrain polys so I can do less collision check each frame. That's really something I could dig in if I have extra time.

So much for this week, going sleep now~

-Max

             

Promo's Adventure (Or Monte's Quest?)-- Post-Mortem

Finally! We did it!

We were literally in a battle against time for the first half of this week. We were so efficient that we forged a "pipeline" that successfully lead us to finish the game in time.

The Pipeline

When I look back now, I still can't believe how could we made a game from this:

Early last week

To this in just a week:

Screenshot1

Screenshot2

I'm so glad that in my first prototype in EAE:MGS, I have such a awesome team! (Andrew the Producer, Vaibhav the Co-engineer and Nathan the artist.) Although the process was tough, but we had our fun. We laughed at our mistakes and jokes so many times that I almost lost count. 

Now, for the post-mortem. Although we finished the game at last, but I think we could have done it a few days earlier. And yes, there are a few things that could have done better, as we discussed in the meeting on Wednesday:
1. We should have started the level-design as soon as we finished the first-stage prototype (which is in the first week);
2. We should consider the art factor at the beginning and work out the solution at the second week during which period we were so exciting adding new features to the sandbox that we wouldn't even gonna use.

On the programming part, I'm still a little confused which approach is better, divide the work and do it on your own, or just work on the same stuff together? 

For the first two weeks I was using the first method, things went pretty well and I was able to finish the first-stage prototype and add a few functions myself. But as a team, it is a little vague about how we divide the work, and merging the code also takes many time. However, the good side is  we can concentrate and often that's when we make progress. And face it, this is how it works in the industry.

And for the last two weeks, I was working with Vaibhav most of the time and that also went very well. Things went pretty smooth, we made a lot of progress and most importantly, we finished the game! No more merging the code, so we didn't have to read and understand each other's code. The program became crystal clear as we all knew what we put into the code. The downside is one of us stuck, the team stuck. And it is kind of hard to get into the "zone" when someone is sitting beside you typing, or talking. But it is a good way to learn from each other, that's why we are here, aren't we?

Anyway, there is still time to figure it out. We're going to have a another prototype tomorrow and this time it is gonna be C# and XNA. I can't wait to get started.

-Max

Promo's Adventure--Week Three

This week is kind of rough.

We have finished most of our work, the skeleton of the game is out there and we can even play the skeleton on the Android now. But we're still waiting for art element of the game. As I mentioned before, our artist has a full-time job in Avalanche. He is a awesome guy but his time for the project is very limited.  It's kind of frustrated but this is what it means to be a team. And I still believe we can finish our game in time.

Anyway, this is what I did this week:
1. Finished the UI layer and implanted Andrew's menu image into the game.
2. With the help of Vaibhav, finished the coin collecting system.
3. Build the moai-untz.exe from the moai source code and get the sound work.
4. Set up the Android development environment and make the game playable on Android device.

What could have done better:
We should probably consider the time factor in the beginning and do the level-design a little bit earlier. In that way we can leave Nathan more time to finish the art.

There is still a afternoon and a night left this week. I believe we can do this.

-Max 

Promo's Adventure--Week Two

Exhausting, but also exciting. That's what I would say about this week.

Why exhausting? Well, my goal for this week is to be completely focused and finish most of the engineering part of this game. But with all that class assignments, personal stuffs and all the other distractions, "completely focused" becomes a luxury. Things got so mixed up that I even forgot about my TB test on the Tuesday. Everyday there are new problems coming up. And it's funny and torturing to see how you make a twist here and it affects somewhere else of the program. One thing I learned about this week is that your work is not actually done or hasn't even really begun before you have any solid level design. But here comes the exciting part, by the time I'm writing this, we actually finished most of the functions required in the level design. Everybody is making a progress and I think we could have the game done by the next week.

Now, here is what I did this week:

Day1 - Set the player's rotation fixed so that he can't roll over now, figured out how the collision detection works, added a smoke object that would push the player in the sky, added a few platforms. Changed the background and the figure of the player so that it would actually look like a cheese. Added colors to the whole scene so it would look a little bit presentable on the class (And actually it went pretty well that day).

Day2 - Think about what to do next and what features to add, find out I can't do anything without a preliminary level design.

Day3 - Met with the team and agreed on a level-design for the tutorial level.

Day4 - Had some problems to match the physics world to the terrain and found out a torturing way to get it done.

Day5 - Started working on some features with Vaibhav to fit the level design

Weekend - Finished the speed booster and the smoke area, added a animation layer of the boost-jump and smoke-collect for the player. Merged the code Vaibhav and I wrote, and now we had a rough scene to play-test on.

What could have done better:

I should manage the time better, cause now it's just a total chaos. Maybe I should work out a schedule or something.

What's next?

What's left is the layers of the scene that we talked about, the score system, a animation to the ingredient when the player gets it and a parameter to track the score, the interface and the menu of the game, and a trigger for the end of the tutorial level. 

I can't wait to see our final prototype.

 

Promo's Adventure--Week One

When it comes to designing and creating a game, there is nothing more important than teamwork. That's why I'm so glad that I'm in this kick-ass team! We have Andrew the Producer -- the main source of game ideas, who keeps the team on track and knows a hell lot about games; we have Nathan the Artist -- an amazing guy whose artwork defines what we're making and what we'll be making; and Vaibhav the Engineer -- a passionate dude who shows some good programming habits and always willing to contribute. As for me, I'm just a game geek who has, absorbs ideas and tries everything to make them happen. Everyone is highly motivated and I can find passion everywhere in this development process!

Anyway, this is what I did on this week:
Day 1 - Met the group and discussed about the game;
Day 2 - Went through the Lua syntax and MOAI SDK library, ran most of the samples in the SDK and exchanged ideas and possible approaches about the game through email;
Day 3 - Set up a simple scene with the character running a simple walking animation in a gravity world using Box2D. Presented it to the team and discussed about what to do next. Talked with Vaibhav about a different approach of "moving" the character; (I set the background rolling backward so that it would seem that the player was moving forward. It seems to be a clever move at that time and it is actually how some of the cartoons and games do to make the moving work. But we gave up that approach later that day because it would a tremendous amount of work to move everything in the scene backward so that the play could "seem" moving forward.)
Day 4 - Made a to-do list. Set the camera tracing the character instead of moving the background backward. Gave the player an initial speed and set its friction to zero.
Day 5 - Met with the team, talked about a few ideas regarding the game. Discussed with Vaibhav about collision detection (which is vital to our next step), figured out a few things he and I could each work on.
Weekend - Set a constraint on the character so that when it is not on the ground, it can't jump again. Add a jump animation layer to the character.

Things are going much better than what I expected. I was worried at first that I didn't know anything about Lua or MOAI SDK and the game would be hard to get started. But once I started working on it, it wasn't that hard after all. Our progress is relatively fast, however, it's still a long way from "rapid prototyping" , but we're getting there.

What could have been done better:
1.More communication, not just through email, this could make some work easier in so many ways;
2.Find a balance between designing and programming, all the programming serves to the final design, not the other way around;
3.Sleep more~~, problems are way easier to solve when the mind is in a clear state.

What's next?
There are still some problems of collision detection that need to figure out. And once we've done that, we could start working on the smoke (object that push the player up), the ingredients score system,  the level layout(jump on the platform, speed control on the hill, make sure the player don't roll over), the file system(save&load) and of course, the UI. I'm also thinking about add different layers to the background and foreground to add more details to the scene and make the screen more "3-D" and active. There are still a lot of work to do.

Things are shaping up well and let's keep it that way.