Final week before final presentation

I added quite a bit of work this past week. They include finishing maze generation with some loops in the maze, add a monster ai that will move in the map and will also run towards the player when the player presses the compass button. I added several new models, a skybox, new snowy ground, as well as a menu system. I am partly complete with the haptic controller as well. The movement works correctly using the controller and I just need to fix the haptic tug direction so that it is relative to the player's heading. I plan to replace our current gray planes with more christmas like walls that brandon made. Hopefully I will have that by Saturday when I go into the lab to finish up haptic controls.

Blog update

For the prototype with Sienna Entertainment, we actually went a different route after discussing it with Roger. In the end, we came up with a simon says type game where a series of clothes are shown with the girl trying them on to notify user which clothes to pick. Then the player will then be prompted to enter the same combination and as the player advances through rounds, they will unlock new costumes and such. For my part, I implemented the core gameplay and menu system interaction as well as the win and lose states. The lose state will ask whether the player wants to try again or not. If the player selects the no option, they will be taken back to the main menu. I also added various sound effects and background music into the game. I also helped with some animation effects such as the clothing item scaling up and attaching to the girl character.

For the final prototype, we are working in XNA again with the addition of haptic feedback. Our prototype will be a mouse and cat type chase game through a maze and we'll be using a Christmas theme for the game. Since the controller contains 2 haptic sensors (one on each analog stick), we will use one sensor to direct the player to the goal while the other will notify where the monster is coming from. For this prototype, what I've done is setup the project, created the player/camera movements and about 90% finished with the randomly generated maze portion of the project. I say 90% because currently the maze contains no loops and we've decided we need loops to allow the player to have multiple ways to reaching a goal. I think the next major thing will be for me to implement the Ai system for the monster which needs a certain visual range, perhaps need to remember where it's gone, and be notified of where the player is when the player decides to use the sensors.

Current weekly progress report

For this week, I simply continued learning unity and continued to work on the main hud system of the prototype. I was unable to import textures and so for this week I was able to get a series of quads to show up which would represent all the different clothing items and also implemented a sliding page scroll the player can use to scroll through the pages. Since the main hud system is now complete, I can proceed to tie the hud to apply the different clothes to alexandra herself.

Sprint 1...last week

So my team decided to work on a game prototype for a mobile software company called Story Chimes. Their apps focus on stories for children from 2 - 10 year olds. In their presentation, they had 4 different ips they want to have prototyped and since there were only 4 teams for this project, each team took a separate ip to work on. Our ip was about an 8 year old named Alexandra. Due to the background story of Alexandra and her supposed dream of becoming a super model, we went with a dress up game which involves dressing up correctly as fast as possible. This ip was quite difficult to generate game ideas for mainly because we simply do not know what 8 year old girls are like. We came up with several ideas including dress up and taking care of a pet and ultimately, the Story Chime guys seed to really like the idea of dressing up and so for the entire week, we tried to create a game based around dressing up and struggled with it. A dress up app can be seen merely as a toy and so through numerous discussions back and forth, we think we've found a way to gamify the idea. Essentially the game will show a particular combination of a hat, a top, and a shirt. The player must remember this combination and is then taken to a dress up scene where the player must place the correct combination on Alexandra.

End of prototype 2

It's been a couple week since I've last posted. Last week we had fall break and the week before was the end of our sprint 1 for prototype 2. I had created a bomb timer that showed the amount of time a player has to complete the puzzle. I also merged both what Derek and I had done up to that pint to reach a playable state. I had the game immediately exit whether the player won or lose and simply logged a "Win!" or "Fail!" string during the exit. Nothing too significant happened leading up to fall break mainly because the art lagged behind our current progress.

During evaluation for our first sprint, the professors talked about the bomb actually feeling out of place because our theme were circuits. So instead of using a bomb with a burning wick as the timer, during fall break, I put in the art for the stick of dynamite with a digital timer showing the player how much time was left. We also had a new layout which I had put in and made sure the positioning of objects now align with the new layout.

I also implemented the different states of the game where the fail state would cause an explosion effect, an incorrect answer would deduct a certain amount of time as a penalty, and for a correct answer, I displayed the amount of points the player had earned. For the point system, I went with the amount of time a player spent solving the puzzle as a scaling percentage for the max amount of points. I then used the number of tries as a scalar that subtracts from the score. So for example, if you had scored 500 points but it took you 2 incorrect tries before solving the problem, your final score would be 500 - 2*50 = 400 points.

In terms of UI, I reformatted the layout of the information display and made text larger, a brighter color, and also put in the systems to display the current game state such as the amount of current in the circuit, and lose/win/time penalty strings.

Lastly, I added the new main menu images and created the credits screen. Since I had work all day Tuesday, Derek finished whatever else that needed to be done for Wednesday's presentation.

Prototype status

So for this week, I've integrated all the separate logic systems together so we've got a working game. This includes putting the inventory, game board, bomb timer graphic, UI layout. We're are still missing quite a bit of art but for now, I've got a single level completed where the user have to fight against the timer and by putting the resistor in the correct location, the bomb is stopped and the player wins. As programmers, the next thing we can do is simply build more levels until we get art from the artist to do anything art related.

second prototype start of sprint 1

For this week, I've integrated the game board and inventory system. I've created a menu screen which transitions to the first level of the game. The game allow players to click on items in the inventory and place them on the board. For the remaining half of the sprint, we (the programmers) will need to create the display system so we can notify players what they are hovering over with the mouse. The other thing we'll need to do is to put in the art for the game when it's ready and show the animation of the circuit.

Presentation week/postmortem

We presented our prototype this week and I think we did quite well. The MVP for our team was definitely brandon. He took over all the art since Dave was not able to complete his tasks and since he has technical knowledge with power game factory as well, he was able to put the art in to test the animation. Due to my work schedule, Brandon ended up putting in the finishing touches of our prototype by himself the day before formal presentation.

On another note, our next prototype will be a game aimed at freshmen Mechanical Engineering students with the XNA framework. I have already started a basic code base so that when we start on Monday, we can start create interface components and game logic immediately.
My current code base include a base component class which contains a 2D sprite, position, draw order which will be stored in a screen object. A screen manager will contain all the necessary screen and uses a push pop mechanic such that the last screen added will be considered the active screen. The active screen is the only screen updated and drawn during each update.

Week 2 of 3 for prototype project 1!

For this week, I worked on finishing up the boss system for the prototype. The final system involves a Simon Says game play mechanic in which the boss of the game yells out a message at which point it is your job to damage the object the boss is referring to. This cycles through until you've done enough damage to the objects which will also destroy the boss. The next item I will be working on will be to help put all the art together into our prototype for Monday's pre-presentaiton.

Week 1 sprint

We have officially started our sprint this week.
For the projects class, I've created the five weapons in the game, three of them(lead pipe, guitar, coffee launcher) belong to the player while the remaining two(pc load paper, notes) belong to enemies. Because we decided to implement a boss system, I had to restructure the stress meter system so that the meter turns off when the boss battle begins. I've also started the boss battle sequence and will finish it next week. The boss sequence involves the player shooting a variety of objects in a pattern.

Start of year 1 Master's Studio

I'm starting the master's program and will be using this blog for the blogging assignments for Projects class

For the first week, we separated into groups to make prototypes using Power Game Factory.
I am in a group with Dave, Spencer, Brandon, Kameron.
For this first prototype, we had to make a game based on a serious / real life concept such as surviving in the wilds, pollution, difficulty of locating a job, etc. Ours will deal with stress management.

Power Game Factory is a fairly limited engine designed for ease of use. It's definitely geared towards the non technical people since there is absolutely no programming required. The engine's strong point is its focus on 2d platform shooter type games and that is what our game will be. Our game play involves of the player shooting different types of weapons that represents ways to deal with stress. The enemies will be stressed people and turns into a more relaxed version when "killed".

For this past week, I implemented the stress meter system where the user's stress level will continuously decrease. For the next week, I will be working on the different weapons in game.

Tuesday lecture

For tuesday, I had finished the progression and collision detection of weak points for the space station. I also started an easy to use message system so people could simply give the message manager the string they want to display and perform basic functions to them. For next time I will continue to finalize the space station and namely the spawning of enemy ships and making sure there are no performance issues when ported to the xbox. I'm currently waiting for the model to have the appropriate information so I can spawn the enemies.

For Thursday March 17...

A few people from the industry as well as faculty members from the U came to playtest our game and gave us feedback. Most of our problems tend to be user interface related and mainly attributed to not giving enough information to the player about the current state of the world. Some ideas include a message system to provide hints, notifying what players need to do in arcade mode, etc.

As for my work...I'm still mainly bottlenecked by not having fully finished models but game logic wise, I'm quite far along. I am at the point where the space station simply needs to put some turrets(already implemented for capital ships) and some explosion effects when a certain part of the space station is destroyed. As of right now I need to add the moving animation of the lower core to reveal the main weakpoint once the two rings of the space station are destroyed.

Tuesday's status

For tuesday I continued to help fix some of the bugs and made some gameplay tweaks. Most importantly, I got the restart functionality to work. For next time, I've notified the team that I'll be studying for a midterm so I will not be able to get any significant fixes done. I do plan to have the space station done as soon as possible, and I'm aiming for next Wednesday or Thursday, possibly sooner if I don't run into any major problems. Our game is submitted on App Hub on tuesday and we hope to get another revision up either next tuesday or once the space station is in the game.

As for lecture, Roger went over what he learned during his visit to GDC and gave us advice on how to fully maximize the experience if we are to visit GDC. We were also told that there will be panelists on Thursday to give us advice on our game.

submission week

I've been helping with the completion of the arcade mode the past week. It is now a lot more polished and ready to be submitted by tuesday. The Space Station model is still not fully ready and will be left out of the first submission. For the remaining days until submission, I will continue to add polish and try to fix obvious bugs that we encounter. All the bosses are working like they should and transitions correctly.

Close to submission

I've been working on the space station logic still and had to go through several iterations of the implementation. One of the problem I noticed after my first implementation was whether or not the boss fight would be fun. Our initial plan was simply to have a space station with various rings around it which can be shot off and a core point will be exposes. Upon destroying the core point, the boss is defeated. The problem with this is that it poses nearly no challenge to the player especially since the previous cap ships required more thinking and strategy. So now the station is planned so that a shield will encapsulate the space station and the user must disable it temporarily and shoot the rings of the space station and its core down. The outer ring must be destroyed first, followed by the inner ring, and then the core point. The shield will reactivate after a certain point and will push the player back out of the shield region. I'm also impeded in testing the space station in actual in game environment because the models for the different parts are still not completed.

beta cont.

I've been working on the code for the space station and have a lot of the structure complete. I am still waiting for the modelers to finish creating the model and texture it. Once that is complete, I'll be able to test and make sure the space station is working correctly and that the bounding spheres are in the correct location and uses the correct size.

Beta start

On tuesday, alpha phase is done and we move onto beta phase. I've assigned tasks for everyone for this beta phase which contains polish, tweaking, and getting things on the evil list checked off. One of my goal is to test the ai boss fights and I plan to have a couple people fully dedicated on getting those balanced.

1 week to beta

I've been adding more functionality for the capital ship and started creating a basic structure for the space station. For this final sprint I will be working somewhat closely with Pace,Jason,and Wilson to get the turrets on the capitalship and the space station, and also get the capital ship working like it's suppose to for arcade mode. For today's lecture, we simply worked on our project and established how the arcade mode will work. Arcade mode consists of 4 rounds, each with 3 phases. After the 4th round, the game repeats itself but the enemies are now more difficult. The first phase consists of enemies spawning and attacking you for a set period of time at which point you can stock up on pods, gain points, etc. The next phase will allow the capital ship to spawn and spawn enemies for you to kill. The third phase will require the player to use their special pods to kill the boss.

Final sprint to beta

I got the capital ship drawing and performing collision detection. This upcoming sprint I will help finish the arcade mode which includes adding more functionality to the capital ship class so that we can accommodate all the features of arcade mode.

Close To Beta

I've been adding space debris and capital ships into the game. Logic wise, everything is ready for the space debris and the capital ships. However, with the new graphics system. I am having troubles getting the objects to draw. By the end of this sprint, the capital ships and space debris WILL be working for arcade mode. I am also assigning tasks for next week's sprint which will focus on finishing arcade mode up which means Ai for the bosses, turrets, getting the death animation and high score to work in arcade mode. We will also focus on adding any remaining polish that is necessary prior to our beta release.

New week of tasks

We are very close to the entire completion of survival mode. Daniel is tying all the loose ends to the end scenario of survival mode in which the player dies, transitions to some sort of game over sequence and then proceed to a high score screen. I've assigned tasks for everyone and if everyone completes their task, we'll be projected to finish in 2 weeks! I have continued to add optimization to our collision code and testing it on the xbox 360 to strike a balance between accurate collisions and not cause slow down in the frame rate. I profiled our current project and I am happy to say that we have done a wonderful job at keeping our code optimized. We predicted the collision would most likely be the most computational heavy portion of our project and we were correct. However, it only takes about 6% of the actual execution time to run. This means most of the work are being done by things we have no control over such as the xna framework. We have also decided to cap the max number of enemy ships at around 15. We reasoned that by the time 15 enemies have spawned, there is no chance for you to survive. Deploying on the xbox, I got absolutely no slow downs with 15 enemy ships all shooting lasers at the player. Our next task now is to implement a mesh to mesh collision system with the larger objects such as giant asteroids and boss ships. Spatial hash is dependent on the fact that your position is separated so only other entities that share similar position as you will be considered for collision. At the same time, the algorithm is efficient because we can ignore alot of empty space. With giant ships, they could take over hundreds of grids in which case, collision becomes very slow since we are looping through so much junk again. Therefore, we will first use a boundinsphere to perform a preprocess step to weed out all units that are too far. Then we can take all the entities that are being considered and perform mesh to mesh collision with the giant object. My primary concern is the amount of slowdown that this mesh to mesh algorithm might cause, but with enough optimization, I believe it should not cause any major problems.

Planning and Coding

So Pace and I got together and looked through the collision code to optimize the system. Having two people looking through the implementation turned out to be much more efficient in this case because we could discuss optimization techniques/ideas and get an opinion on whether it'll work, or the kind of problem the change could create. We deployed on system to the xbox and perform a stress test to find that with grid dimensions of 1000, we were able to fix 150 enemies before serious slow downs. We'll continue to optimize this since a dimension of 1000 is quite inefficient for our system. The spatial hash system is very dependent on the grid size because it separates ships into grids and only perform collision test on objects within the same grid. Hence a 1000 by 1000 by 1000 grid can fit a lot of enemies which would make the collision system very inefficient. I've broken down all our remaining tasks and we should reach beta within 3 weeks. I think if all goes well, we can complete what we wanted in our beta within 2 weeks and spend 1 week to add some back log stuff that we want initially. Perhaps different types of player ships, or a versus mode.

Another week, another sprint

As a group, there are still some things we need to do to finish porting but we are essentially back at our masters studio demo stage. I've assigned tasks to everyone which primarily include polishing, optimizing, and getting the game on xbox to run smoothly. I am still working on the collision detection and will have Pace work with me to finalize it for this week.

XNA 4.0 conversion continued

So our entire group is still working on converting to 4.0 and we're making progress. The majority of the team have finished porting over. For this class period, I've been adding more to the collision detection system and will continue to do so most likely even after the sprint ends. This is simply because I will most likely need to do numerous stress tests to find the optimal solution for the collision detection. I have also begun planning out and assigning tasks for the next sprint. I think the primary goal for this upcoming sprint will to get what we have now to not crash on the xbox 360, begin to assign someone on dealing with the evil list, and then polish what we have working now. Interestingly, it seems like the amount we spend going from 0% complete to about 80% complete takes as much time as going from 80% to 100%. That last bit takes a lot of work because we have to balance gameplay, visually make the game look nice, and make the game feel fluid.

For my task, I've had to spend alot of time with the collision system. I am currently applying a spatial hash which splits up the worldspace into tiny cubes. We can then represent each cube with an id in which our hash consists of the id of the cube and contains a list of all the objects in that cube. By doing this, we then perform collision detection against objects in their own cube space. This cuts down and eliminate collision checks against objects which may reside in a very faraway point.

New sprint

For this sprint, we will be focused entirely on conversion to 4.0 Each person will be responsible for porting what they have been working on. For Pace, he'll be porting the pod system, James will be fixing the lasers and porting the AI, Wilson and Jason will be working on the screens and then improving it to fit our game modes, CP will be working on a scoreboard system, and I will be focused on retooling the collision detection system. For the past week, I've simply gone through our code and manually port over the project. This has taken a surprisingly long amount of time because of changes made to xna as well as making the code more robust this time around.

Presentation to Masters Students

Today is we finalized a playable demo for the masters students to play test. We were able to make quite a bit of progress this past few days and I am ecstatic to say that we are close to having a fully playable game mode. Currently it is mostly complete but should be finished in the next couple of weeks. For today, I continue to convert our project to xna 4.0 while cleaning up code and doing some optimization at the same time. It's taken a surprising amount of time but doing this have definitely made the code look simpler and gives everything much more structure. Because we have just been adding functionality, many variables and methods were never thought of until a particular function had to be added. Now that we have a better sense, the restructure has made our code much more robust. By next time, I plan to continue to work on the conversion to xna 4.0 as well as getting the next sprint started. My plan is to get everyone to work on different parts of the code and convert it to 4.0

Start of first spring sprint

I am now the scrum master for the team. Professor Kessler and Altizer decided it would be best to split up the tech lead/scrum master role so that I am now the scrum master and James will be the tech lead. I've continue converting our project to the xna 4.0 version of it while cleaning up some of the code during the conversion. I've assigned tasks to all of our programmers and have notified charlie to assign tasks for the art group. Our priority for this sprint is to finalize all core code such as battle mechanics as well as converting most/all core game code into XNA 4.0. Primarily we are finalizing and fixing bugs that we've found to create a good playable game by tuesday as well as finish our 4.0 conversion as soon as possible so there will be no down time when everyone else need to switch from the old project to the new one.

Spring Semester

Heading towards the end, we are projecting about 6-8 more weeks of beta phase. We have been continually stripping down more and more of the original game. As of now, we are going to end the mission select concept and only add a survival mode where waves of enemies swarm and the player strives to get a high score. I have also began the conversion to 4.0 while cleaning up some of the code we have implemented but never used.