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.