Alpha demo

For today, I added the flee state of the AI as well as a damage system into the game so that each ship can take a certain amount of damage. This ties into the flee state because we check for a certain amount of health to make enemy run away. During this flee state, enemies will slowly regenerate health. Once a certain health level has been reached, the enemy will go back into the explore state to look for the player ship.

In class, we showed our alpha version of the game and today, marks the end of our first semester of work.

Second to last class of semester

For today, I created a basic framework for the AI system. Our AI is a state machine that transitions from state to state given a certain criteria. For example, an enemy in the chase state would transition to the flee/evade state when its health reaches a certain hp. For this sprint and the remaining two days, we will focus on creating the high level parts of the AI system. This will give the enemy basic functions such as exploring space by itself for example. Eventually we'll expand on this so that we have a think and react AI system where the high level will perform the thinking and base on what the enemy observes, will react in more sophisticated manners such as deciding the best maneuver to use when fleeing from the player or chasing the player. For the upcoming thursday, I will continue to add to the basic framework and try to help James with adding the final touches for the demo on Thursday.

Task for final sprint of the semester assigned

So in class we talked about how to split up the remaining tasks we had to have by next thursday. Most notably, we discussed how to split up AI so that we can all work on it without it being too dependent on each other. On the highest level, we have divided AI up into three parts, chase state, evade state, explore state. James and I will be working on the chase state. This chase state deals with chasing the enemy as well as the AI on how to attack the player as well.

Home stretch

We have 10 days left to get our game to a playable state. What we have to really focus on now for this last week is to add AI into the game. As of right now, there is no AI in the game at all. We've also gone ahead and cut down quite a bit of features. This includes adding branching storylines for multiple factions, hangar to store multiple ships and ultimately, keep the game more arcade like. The schedule is a bit tight considering we all have other final projects we have to finish but it looks like we will be able to get everything in by next Thursday. We decided to go on a week and a half week sprint and so James will be assigning us new tasks.

Tuesday Class Canceled

The University canceled all classes after 2pm on tuesday so we did not have a stand up meeting. Last time, we decided to try one week sprints instead and my current progress is as follows. I was assigned the task of implementing a radar system and its gui and I have completed this task. Since the design of the radar was not made explicitly, I initially worked on a top down view style of the radar. During the weekend, I talked with some of the members who thought the radar would simply show the enemies located at the front half of the ship. This means that the bottom of the radar would be the bottom of the player ship, etc. I began working on this system but soon found it to be much more complicated. The problem is how to actually define when an object is below or to the right of me? Essentially all axis, x,y,and z, determines the position each at different situations. My initial reaction to this implementation was simply confusion. It seems really strange to me to have a radar keep track of simply just objects in front. I need to ultimately talk to the team again so we can finalize the design of the radar. However, as mentioned by James, we need to have some type of radar in by the end of this semester, and if we decide to go a different route, then we can change it and consider it as the polish portion of our development cycle. I think we might be meeting on Saturday and hopefully, we can finalize all the tasks we need to get what we want as our playable demo

Beginning of our last sprint to playable demo!

For today, I continued to add onto the collision detection. Since new types of weapons and objects are added, I've been adding onto the collision detection so the new objects can have interaction between other objects. When I first implemented the collision detection, we simply had a list of entities and from that list, I specifically only had asteroids. As more objects were created and I went from a naive implementation to a more optimized collision detection separating our space into 8 distinct quadrants, I began building individual lists for types of objects. Space objects would be in its own list, ships would be in its own list, pods, and now lasers. These lists improve on performance since I don't have to iterate over everything since all objects derive from entities, but rather, loop over the list of ships and pods if I wanted to check if any pods collided with any ships. So for this sprint, I began creating code for the laser list and its behaviors against other types of objects. For the next time, I have been assigned new tasks for the new sprints, My tasks are implementing a backend system to transform object's 3D location into a 2D format, and with that 2D format, I can then translate that location relative to the playership and display it in a radar.

Close to the end of sprint #2

For today, I've optimized the collision detection code by splitting our 3D space into regions and create lists that would keep track of the current objects in those regions. By doing so, the number of iterations the collision detection would have to do decreases dramatically especially when there are large number of objects. Instead of performing useless checks with objects that are opposite of the 3D space, only objects within a certain region in space can check against each other. In addition, if objects are in the same region, I perform another optimization to make sure that objects are within a certain distance of one another before continuing on with the check. For space objects for example, I would allow 2 objects to have a maximum distance of 512. If the distance is outside of that 512, no collision checks will be performed. Eventually, after we have models with numerous meshes available to us, each model would have a large bounding sphere that would encircle the model with smaller bounding spheres for the actual collision detection. The large bounding sphere will allow us to do a simple check to make sure the bounding spheres are indeed intersecting before we do the meat of the collision which will require us to loop through all the smaller bounding spheres to make sure there is indeed a collision. I also edited the camera a bit so that the camera is not created within the player but by the level. Because we can now use locators to define create tags for our model, we can simply create locators for the camera position for a specific ship and then assign the camera to the locator we want. For the remainder of the sprint, I plan to help the others finish their task and I will also take a look into the pod having difficulties firing at their designated position.

Another sprint update and the process of reviewing games

Today in class, we went over how to review games and some of the key ideas that were discussed includes 1) Determine our target audience 2) Write about function and avoid opinions and personal bias. As our target audience will be developers like ourselves, the main focus in our review would be bugs that we have discovered and gameplay concepts that still need improvement, polish that would help create a better overall gaming experience.

For the sprint, I continued to add on to the basic collision framework such that all our objects will interact with each other in some way. For example, pods will "explode" when they collide with other objects. Currently, without any particle effects, pods and the objects they collide with will simply disappear. But when space objects collide into each other, they will "deflect" off of each other and go their own separate ways. I still need to add more math algorithms to make collision more natural however, I've completed all my tasks in that a basic collision system is now in place. One major problem that I will continuously be working on is the optimization of this collision system. Even with around 300 objects, framerate drops due to the large amount of checking. As for next time, I will continue to polish existing code and help any others who has yet to complete their tasks.

Progress of Second Sprint

For Tuesday's class, I was able to implement a basic framework for the collision of objects. For our purposes, when we debug the program, I also render the bounding spheres so we can tell when we are colliding into objects. Conveniently, XNA actually automatically create bounding spheres for each mesh of our model. By using these meshes, no extra code will be required to build bounding spheres. However, since a bounding sphere encapsulates a mesh, a single model will require numerous meshes for bounding spheres to be accurate. Therefore, each model will be split into smaller meshes such as a mesh that contains a wing, a mesh containing the body of the spaceship, etc. Next time I intend to generalize the collision framework so that collision between any objects will be applied. Since the last time, James found out that artists can put locators onto certain bone areas and name them. These locators can be accessed through xna and will make our ideas of attaching pods much easier. We can give locator for where to attach cameras, where to place pods, where to emit engine particles, where to shoot weapons, etc. We are also applying these locators into our level design. We can use these locators to place mission specific objects and certain story triggers. As a result, we can use maya as a level editor. Each level will be represented as a model which contains a series of locators which the programmers will use to place mission objects. This is solve our previous concern of hardcoding every single level.

End of 1st Sprint

We're at the end of our 1st sprint and I was able to complete and do more than what I was assigned. My task was to get the player's movement implemented correctly and I helped create the gamescreen and the tutorial level so the player ship would be displayed. I also added the camera with a spring like effect to it as well as randomly generated asteroids.

As for today's class, all three groups showed their current progress, talked about what didn't work in our first sprint, and our impression on how our first sprint went. For the standup meeting today, I was able to create randomly generated asteroids since last time, and since we begin our next sprint, I will wait for my task to be assigned.

After class a few of the programmers met up and discussed ideas on what we'd like to accomplish in this upcoming sprint and some of the suggestions were to get the collision working between objects, figure out a efficient way to display a skybox without any notable rough edges that may show the faces of the box.

Tuesday progress

In class today, we learned that we will have to share our current progress with the rest of the class next time. Except for that news, my group went down to the computer lab to work on our project and spent some productive time refining our game concept. We discussed in detail what our ideas were regarding customization and decided to have a formal vote next time to finalize the customizing details.

For today's sprint, since the last time we met, Pace and I got the Game Screen and the tutorial level working such that the game will load tutorial level successfully and be able display and update all the ingame objects. I was able to complete my sprint task of getting the player's movement completed and also finished the camera so that the camera will trail the player. In addition, the camera will use a "zooming out" effect to show that the ship is accelerating, and then zooms back in when the ship is no longer accelerating. For the next time, I intend to help the others who still need to finish their work and polish and clean up the existing code to ensure it stays readable. So far, I have no impediments

Thursday Oct 28

For today, I added player ship and camera classes. Since my sprint's task is to perfect the player's movement, I've begun adding code to the player ship class. There are currently no impediments and by next time, I should have the player ship movement completed.

As for what happened in class today, we did not have a lecture and so our group continued to work on the project. For us programmers, we were able to get together, look at the way the current framework of our game is built, and edit it to make it more flexible and efficient. We also discussed future impediments we may encounter such as optimizing the content manager such that we can minimize the amount of resource and power needed for the xbox360 to load and run our game.

Tuesday Update

For this week's stand up meeting, I set up and began adding some classes into the repository. I organized the code and tried to set up a format that everyone can follow and makes reading each other's code much easier to read. I added a .doc changelog that may be updated when an individual commits a new revision into the repository. For the next time, I will be working on the user ship update movement such that the user will move to its correct position and velocity has been given.

During our discussion today, we've decided to actually start out at XNA 3.1 and wait until next semester before we convert to XNA 4.0.

Thursday sprint goal

Today our group talked about some core classes we need to start building our core game engine. This includes having screen manager class to manage the state our our game, and receiving and passing inputs along to the correct object. We also discussed creating an entity object which is the parent of all our objects. We created a inheritance structure to ensure flexibility and that all objects are organized correctly in terms of their functions. For example, we would have collidable or non collidable classes from which a space ship for example would inherit from the collidable. For stand up meeting today, since all the tasks are still not fully partitioned, I have gone ahead and set up my microsoft visual studios with the new xna 4.0 and I've also installed and set up the repository so I can begin coding. For the next time, I plan to start on and finish what I will be assigned to do.

Tuesday After fall break

So Chase Dickerson from last year's urban space squirrel came in to talk about the level editor he made last year as well as some challenges and speed bumps the team encountered. For our stand up meeting, we actually did not have much to talk about since we did not assign any tasks during fall break. However, we divided up the task for this coming sprint on tuesday, and James will finish splitting up the tasks up next meeting time. I have also downloaded the new xna 4.0, and installed it on my machine.

Finalizing Product Backlog

On thursday, we finalized what we must include in our release as well as what needs to be accomplished by the first sprint. For the artists, they need to have some space ships and sky boxes complete. They will also need to settle on an overall theme for the game. As for the programmer side, we need to implement all of the major mechanics that make up a space ship game. Physics to simulate movement, fluid controls, and a user interface. The work will be split up by James and once he finalizes the task for the programmers, I will be able to start on my sprint.

First day of product backlog planning

On Tuesday, we began producing our entire product backlog. This includes all features that we would like in our game. An example would be having a economy and customizable space ships in our game. Next, we trimmed down and created a log of what our user should see in our game. An example for our game would be a tutorial, a space ship load out screen that allows user to change pod types and upgrade ships. Next class, we will be trimming our backlog down to parts of the game that needs to be in our initial release.

Final games decided

Gravity shift, creep commando, and space fighter are the three games that made it through the student and panel voting. We met with the new members to our team and began discussing the final vision of our game.

Pitch Day

We presented our pitch in front of a judge panel today and received mixed results. Overall, the judges liked our idea and utilizing pods which sets our game apart from other 3d space games. One of the judge mentioned the use of momentum to sling the pods might be problematic because it does not allow users to see the actual slinging of the pod. Another point made was that since our pod is the hook of our game, we need to showcase/focus more on it.

Practice Pitch Over

We presented our demo today but there are a few things we still need to finish before tuesday. Most of it will come from Charlie and post production videos. James and I will add some more ships and decrease the amount of asteroids in our demo. We will also add various ships to provide a more diverse feel

Sept 21, pitch practice

We started our pitch practices today. Our presentation is actually on thursday and we still have some things we need to finish so the gameplay demo looks more polished. I've added enemies on flight paths but one problem I came across is how to rotate the enemy ships properly so they face the direction they are flying to. There are some new code concepts(Quaternions in particular) that's hindering us, and so James and I have agreed to focus on fixing this problem first and then finish fixing the smaller things later.

Prototype progress

For today, we began discussing what our presentation entailed and finalized what must be in the demo. We determined a playable demo and a video will be incorporated into our presentation. As for the tasks, I will be adding thrust to the spaceship, add flightpaths to an enemy ship, and adding health to our objects.

Prototyping continued

For today, we worked on our prototype. We discussed and wrote down ideas and features we still need to incorporate into the prototype to really sell the game. Items we still need to add include explosions, sounds, asteroid and ship models, enemy ships. For starters, James will work on the explosions, I will work on the sounds, and Charlie will continue to work with the models. On thursday, we will take a look at our progress and decide the next steps.

Goal and Theme - Rapid Prototyping

Today in class we discussed rapid prototyping and simply focus on one core aspect of our game that sets our game apart from all the other games. For our space fighter game, our theme is a 3D space fighter and the goal is simply use your ship to outmanuever and destroy the opposing targets.

Down to 9 games

So in class today, we narrowed down to 9 games and I have been placed on the team of space fighter game with James Brinkerhoff and Charlie Mimnaugh. We also began discussing the prototype of the game. The space fighter game is a 3d dog fighting game, and so part of our prototype will involve getting the player and the enemy in a dog fight chase. We've also decided to add some space debris into the environment. The first thing James and I have decided to do is actually start refreshing xna, its 3d components and putting a space fighter into the prototype. Charlie will be the one creating the model.

EAE capstone progress

Hello,

So for the last week, I made my game pitch and also voted on my top 10. I pitched a game called Arena of Heroes. It is a blend of Defense of the ancients and castle crashers. The game takes the strategy elements from Dota and adds it to the action of Castle Crashers.
The goal of each game is to help your team defeat the opponent team. Victory is reached when the tower of the opposing team is destroyed or the kill counter of the opposing team is destroyed. Players earn points based on their performance and can spend those points on more characters, costume skins, etc. The link is the following: Game Pitch

Captains of DarkTide Massive Multiplayer Online Role Playing Game

I am currently an intern at Silverlode Interactives. Here I helped implement the player to player trade system which allows a user to trade their items to another user. As all code belongs to the company, I cannot upload anything that belongs to them. The current project is still in pre-beta stage. However, I can provide a link to the main site.

Captains of DarkTide

University of Utah Psychology Research - Discrete Dynamic Systems

This next post provides a link to what I am currently working on for Professor Tom Malloy at the University of Utah Psychology Department.

E42_Network_Builder

E42 is a simulation tool for creating Boolean Discrete Dynamic Systems consisting of N nodes, each of which has K inputs. My version incorporates Network Builder which allows the user to create various types of networks and perform simulations to them.

Level Editor C#

The following link contains the release build to a level editor created in C#. The purpose of this level editor is to serve as a generic tool to be used for 2D platform games. The program features undo/redo, properties of objects, different layers of a level, as well as saving/loading through xml

Level Editor

Flash Projects

This is one my more current side projects. It is to teach beginning japanese learners the characters of basic japanese. The program is designed to be a quiz type project. Programmed by Felix Lau(me), Art assets by Tuyet.

Hiragana Learning

This next project is a simple shooter designed with a toy-like art style. Pressing the space bar will drop bombs and left clicking the mouse will shoot missles. The point of the game is to simply survive and get the highest score possible

Toy War Plane

This last project is one of my earlier projects. It is connect four, each player takes a turn to drop their checker and whoever gets four in a row(diagonally,horizontally,vertically) wins.

Connect Four

Project Greeeen C#

Hello,

This post contains videos of my final project from Spring 2009. The game is called Greeeen and it is programmed by me(Felix Lau), Sigmund Chow, Chris Dillard, Jeremy Heintz.

I am responsible for implementing the HUD/interface, monsters(includes drops from monsters), boss fight, and portions to the title screen. This project was created using Agile Scrum process.

The gameplay consists of the user choosing the right color to shoot. Using the mouse scroll or numbers 1-4 on the keyboard, you may switch between the different colors and if you hit a monster with the corresponding color, they will be damaged.

Part 1:


Part 2: