I Lied and Zombie Bowling!

I lied; I changed our prototype three game to a zombie bowling game instead of the radioactive baby game. I needed to spend more time coding the GDW so I decided to do the zombie bowling game since I already had a vision of how I was going to code it.

The features that make this game unique is how the zombies act as bowling pins but they approach the bowler (player) and jump (like the famous Chinese zombie Jiang Shi) which gives them a chance to hop over a bowling ball.

http://www.chine-informations.com/forum/images/cache/29086_022120.jpg

The zombie bowling game takes place in a dark setting. There is a creepy zombie baby (made by our talented artist, Tuo Xiao aka. Stone) that spawns the zombie pins. The zombies continuously spawn and the spawn rate increases over time. The bowler is limited to one bowling ball per second, this way they don’t spam bowling balls. To bowl, the player must click and drag in the direction of where the player wants the bowling ball to go.

I designed it so it’s easy to pick up and play, anyone can play it, you just hit the start button and then click, drag and release towards the direction you want the bowling ball to go. It would work perfectly for the iPhone or iPad.

Here’s a screen shot of the game

PS: I used cylinders  as the zombie pins because we didn't have a model for the zombies. :)

Prototype 3!

As for our prototype 3 assignment we had to create a game based on a game idea in a given list. We choose the idea where the player carries a radioactive baby in a pitch black environment and the baby would act as our torch. Rocking the baby will intensify their glow.

To make this idea into a game, we are going to have coloured paths and the player must be on the correct coloured path based on the baby’s glowing colour. The player must make it through the paths and to the finish in order to win. I’m still trying to think of more ideas to make it fit well together. I need to design it so the game would be easy to begin yet challenging and fun. The style needs to work otherwise it would look like another amateur game project.

I’ve added a few more features into our GDW game. There’s 2 weeks left to work on our game and I’ve been working on the game, the engine for our game is complete and I’ve been adding game play features. Since I’m the only programmer, there isn’t much time left to complete this game and I will be working full-on. It would be quick to add features now that the engine is done.

PS: Posted this before class in the middle of the night! Doesn't count as late!! LOL

A* Lag and Group Disagreement

I haven’t posted in a while but here’s the update of how I’m doing. As I said before I’m the sole programmer in the group so I have been designing the programming structure and programming a lot and have done a lot of problem solving. I decided to do A* for our game since our game is a top down shooter and there will be waves of enemies closing in on the player and his elite military squad. The game has some dead ends and it will be difficult for steering-behaviours to steer around the dead ends. We also want the enemies’ movement to constantly moving towards the player cleverly (thus it will need the shortest route).

I had an disagreement with a fellow group mate as he kept telling me to use steering behaviours and not A* because he thinks A* is wrong and out dated, but with my horrible explanation skills I had a hard time explaining to him that Steering behaviours wouldn’t take the most efficient route to the target and steering behaviours may get stuck in dead ends or go the wrong way in in our type of map. The enemies need a path generator to get out of those situations and a good enemy script would use both steering behaviour and a path generator. Unfortunately this disagreement caused some delay in the production of our game and the group’s motivation had been damaged.

Even Starcraft uses it (images taken from http://www.teamliquid.net/forum/viewmessage.php?topic_id=132171):

Anyway, I dug out my A* code I coded last year in second year and threw it in the game and it worked beautifully. Only problem was, since our game has waves of enemies (I coded it to have a maximum of 100 at a time), the game started lagging whenever the enemies needed to generate a new path. I thought for a while and I came up with a solution (which I haven’t coded in yet since I’m coding in other features for our game) which was to multithread the A* path generator. This way, when there are delays when generating a series of paths for a series of monsters it wouldn’t affect the other elements of the game.

Here’s a screen shot of my year 2 A* program:

PS: I just wanted to say, another fix I thought of would be to use swarm AI and steering behaviours to avoid obsticals and then use A* for the lead unit in the swarm, the rest are following the lead this way I don't need to keep generating A* paths but I wouldn't be using this because of time and it doesn't fit our style of game play, the enemies should swarm together as a group, instead individually move towards the player and his squad.

A game for a 35 year old canadian men.

For the group's prototype 2 assignment I decided to create a demolition game with a wrecking ball.

After some research I found that the average age of gamers are around the mid-thirties and the most common game genre is common games that are easy to pick up and play. It makes sense because there are several types of gamers; Casual gamers, Mid-core gamers, hardcore gamers, pro gamers, etc. Research shows that the older gamers (30ish+) tend to be the more of the casual gamers.

Our prototype is called “Building Smasher” and I made it very simple yet challenging. I tried to make it a casual, simple yet challenging and appealing to the average 35 year old Canadian guy. The player only uses the arrow keys to move the wrecking ball crane. It can take a while to master the maneuvering of the wrecking ball because of the rope/chain.

Destruction is proven to be a guy’s thing so that’s why I chose to do the wrecking ball.

The player wins and progresses to the next level when they demolish the building to a curtain height before the time runs out. What makes the further levels harder is the reduced time and increased building size. The player’s control over the wrecking ball is the key to success in this game.

Prototype 1 = Mechanics of Space Invaders in Unity!

I forgot to mention about my First prototype. Last week, We are supposed to create a fan remake of an classic Atari-2600-type game from the given list:

a. Defender, http://en.wikipedia.org/wiki/Defender_%28arcade_game%29

b. Crazy Climber, http://en.wikipedia.org/wiki/Crazy_Climber

c. Galaxian, http://en.wikipedia.org/wiki/Galaxian

d. Space Invaders, http://en.wikipedia.org/wiki/Space_Invaders

e. Xenophobe, http://en.wikipedia.org/wiki/Xenophobe_%28video_game%29

f. Slot Racers, http://en.wikipedia.org/wiki/Slot_Racers

g. Fishing Derby, http://en.wikipedia.org/wiki/Fishing_Derby

h. Wizard of Wor, http://en.wikipedia.org/wiki/Wizard_of_Wor

i. Centipede, http://en.wikipedia.org/wiki/Centipede_%28video_game%29

I chose to do Space Invaders since I could quickly visualise a clear and organized way to code the game. The game would require all the features in the orginal, these features are:

-Player Shooting

-Enemy Shooting

-UFO

-Lives

-Score keeping and increment value based on enemy type.

-Player Movement

-Enemy Movement (moving down after a unit reaches the left or right boarder)

-Lost when no lives are left
-Lose when enemies reach a certain depth towards the player

-Destructible Barriers

-Enemy removal after being hit by bullet

-Removal of player lives when they are hit by an enemy bullet

Here’s a screenshot:

As for our group game, I’m the sole programmer since no one else in the group has strong programming skills and in the end I’ll just waste more time fixing people’s code then doing something else more productive on the game.

I‘ve set up all the code base for our game and they are mainly header file for game objects that will be used, such as enemy, player, ally, bullets, game managers etc.

Magic the Gathering - Assignment

For our assignment we were to create 3 simple magic cards and explain how we calculated the stats on the card.

Four Legged Spider Pack: +2 for colour, +2 for colourless, +1 for base. Total of 5 points.

 Fire Master: -1 for being a red card, +2 for colour, +4 for colourless, +1 for base, +1 for using more than 5 mana. Total of 7 points.

Mind Controller: +2 for colour, +3 for colourless, +1 for base. Total of 6 points.

Summon Night: swordcraft Story (GBA)

Summon Night: Swordcraft Story is a member of a famous Japanese RPG series, "Summon Night". This game plays on GBA platform.

Here's a graph of all the resources in the game that effect the game play and have some sort of equation to it. When I started linking all the elements together the graph got more complex. I found that Health is the central resource, everything evolves around it.

Ingenious!

We played the award-winning German board game called Ingenious. Here are my thoughts on this game:

Things I liked about this game:

-Simple

-Special game for single player

-Up to 4 players, good for family or group of friends

-Lots of freedom on placement which would involve more thinking/strategy from the players rather than luck such as rolling a dice in other games (though it does involve some luck when drawing pieces)

-6 pieces only, so they have just enough to use which would require thinking verses having too many which wouldn’t require much thinking if you have the piece for everything.

-Loser is the player with the lowest score for any colour (makes players value certain colours over others more)

-Can see other player’s score board, helps you develop a strategy

Things I disliked about this game:


 -Rule where youngest player must go first and then go clock-wise (unbalanced)

-Additional rules for single player (which can’t be helped but doesn’t have the same feel as multiplayer).

-Swapping Tiles rule if they hold no tile for the lowest score they can swap out their hand for a new hand at the end of the turn.

-Rule where the board games bigger as the number of player’s increase. I prefer to just let the player’s choose their game size freely.

-Average game time for two players is too short for me

Things I Would of Changed:

-Rule where the youngest player must go first. If the players were to play more than one round it would make the game imbalanced since the that player (the youngest) would always go first. Instead randomized the first player (ex. using a dice, assuming cost isn’t a factor)

-Allow the players to choose game size. I might want the game to last longer so might want to choose the bigger size board. Leave the choice to the player and have recommendations for the board sizes based on the rules they have now.

  
What do you guys thing about the changes?
Do you guys agree that it would make the game better?

3 Day Programming & Plan for Next Semester

Before you start reading, I completely accept the fact I screwed up lol. This talks about my point of view on our group's screw up for our game.

3 Day Programming

So I've been programming our game requirements the three days before the presentation and used the base code that we've worked on in the Engine Design Lab which already had the camera and physics and many other features an engine would have. I know the requirements are pretty easy except the Skeletal animation to get done. I only received code from our business guy in the group for the shaders & Xbox 360 Controller in our game (I forgot to mention that in the presentation when I said I did all the programming in 3 days lol). This affected me significantly because what I thought was done from the other programmers wasn't done, they came to me during the 3 day programming period and said "they don't know how to do it" and they didn't bother to learn how so I had to code their parts. Thus my three day coding period wasn't enough to do both my part and their parts so we didn't 100% of the requirements done.

Personal and Valid Reasons I Was Unable to Program Earlier

- Didn't get the level scene graph to work with until the last few days (I was still getting art from them the day of the presentation) and our game-code is based heavily on the level design and how you encounter with it, I would be happy with place-holder models to work with. It's not like a top-down shooter where I can start programming the AI and way points and etc. without the need for graphics. I later realized the lead artist wasn't doing the work either since he was waiting on the other artists to give him their parts (which he didn't get until very very late, He also got models on the day of the presentation) and he was responsible for the scene graph.
- Wasn't interested in our game, I had a different vision for the game than the designers. No motivation to do it, would only do it for the requirements since that's what's being marked.
- Programmers except me and the business guy didn't know how to do it and aren't willing to learn which annoyed the hell out of me.
-The votes for this type of game outweighed the others and the sadly the majority of the voters that voted for this are the freeloaders.

Everyone in our group was at fault.


Plan for Next Semester

- Since everyone else said they don't mind what the next game type is I'm going to pick something I enjoy programming (just for this group, programmers don't usually pick what they want to make) which is AI, we are going to do a Top-Down shooter next semester.
- Kick out all the freeloaders
- I'm going to do all the programming and I'm going to start early because I love coding Top-Down Shooters. once we kick out all the freeloaders our group wouldn't have any other coders except the business guy but I want him to focus on his parts.
- We are going to keep the group up-to-date with everyone's part, so the graphics people will know how the programmer (me) is doing and vice versa. We will comunicate about our division needs so we become more synchronized.
- Weekly group meetings
- Early place holder models even though this isn't going to be like our last game where it matters significantly.

Conclusion

So everyone in our group (except the deadweights/freeloaders) had the ablility to do it and make a good game but our team coordination was really poor so we paid the hefty price, having a crappy game.

Cram Week Begins! Quick update post

So there's one week left and we don't have much complete. There's a lot of models in our group Dropbox folder but there's a lot that aren't complete. There's not enough for us to code for the game and they aren't placed in the scene yet for our game from our graphics and designer people. I alerted all the programmers to just stop waiting for the graphics and just code all the requirements even though it may be not related to our game. A handful of the requirements are similar if not the same to the previous year's requirements so I have a lot of my previous code for our previous game that I can use. The only requirement that got me thinking, and sounds troublesome is the Animated Characters requirement where we have to perform skeletal animation in the game. I will look into that once I have everything complete.

Wrong about the midterm

So I got my midterm back today and I failed. I didn't explain in detail about a lot of the questions and gave a really brief description so I only got part marks. I blew the last two questions completely which was a total of 20 marks and I only got 3 of the 20 marks.

As for our gdw game I've started programming the base and it's really easy to do things in this engine and I understand how this engine works. I'll be coding everyday now for at least 3-4 hours and when it gets closer to the end it will be much longer and then eventually straight coding. I have already got a lot of the features in such as states for player/game/items/etc, camera types, physics, movement, heart beat indicator (used to determine the monster distance), and some other small base features. I'm currently working on the particle system which shouldn't take long, several hours/no more than a day.

The other guys have added in the xbox360 controller features in and I assigned some one else to do the GUI.

The designers and artists are on a roll, designing is complete and they are working on art. Much of the art is complete but there's still a lot to do.

Such a stressful week

I've finally finished all the midterms and assignments for this week and I've slept in and feel great. I've had 4 assignments and 2 midterms in the span of three days (Monday - Wednesday). I've pulled 3 straight all nighters which is a new record ahead of the Great Canadian Appathon which was two days. I"m gonna celebrate hard haha and do nothing today! Well except this blog post since I must do it.

As for the engine, now that I actually started to use the engine, I've learned how it works (very similar to some engines I've used before so it doesn't take me long to do something). I've already finished the camera movement and function from the homework assignments and I'm going to start coding the core features and structure for our game (which is really late to start, I want to beat my 3 all-nighter record).

For our Engine Design midterm, for once Professor Dr. Hogue gives us an easy midterm. Well actually I don't want to say it's easy because if I didn't do well on it I'll have a bad impression lol (to Dr. Hogue if you're reading this). Though it was easy, I know I didn't do as well as I could of on it since I didn't explain in detail for many questions but I still understood the questions.

Design Completed

Some concept art from our design/art people:

All the design for our game is completed. Now it's my turn to figure out how to use the game engine (which is late) which shouldn't take me that long since I've used many engines before (not saying all engines work the same way) and I've looked at the structure of this engine and it seems to be pretty easy to pick up.

update

I started to setup the genre-specific code in wildmagic for our game. I also played around with wildmagic to see what I could do with it. I'm trying to learn how to use all the features such as shaders.

Our designers have been working a lot on the game and the concept art looks good (I would show some but I don't have any) and the levels are creative and we believe it will truly make the player think about how to beat the level.

Third week update (Late)

Sorry for this late post but I was so busy the previous week and I forgot about the blog temporarily.

Last week I competed in the Great Canadian Appathon 2 so I had no sleep for two days straight and then I had four assignments due in the same week right after the appathon.

I think our team did really well in GDA2 we had me (third year game dev. and previously worked for a game developing company) as a programmer, and three 3rd year networking students (one is also worked at the same game development company), one was also a programmer, another was a artist, and the last person did the game design. Our game was programmed in Flash CS5 since we only had 2 days to build the game and it had the ability to export into a ipa (iphone) app file. Our game came out pretty well, we think we made the top 25 (hoping we hear a response tomorrow) but I don't think we made the top 12 (to get a prize) since there is a lot of talented game developers in the contest and our game wasn't our best and the coding was rushed and messy. We are sure we'll do better next time though. :)

As for the GDW3 game there has only been more late designing going on. I really like the new idea the designers thought about in the game though I question if it's achievable in such a short time.

Major changes to our game and team

New Story/Game

Our game had our game name changed to "The 8th Day" to fit our new game which has 8 levels (one level = one day). Our story is about you and how you are chasing someone/something who you believe would lead you the way out of the haunted factory you are working in yet you are also running away from what you believe is a ghost haunting you from the past.

The first day, everything is really bright and the character is well in shape but throughout the days they vision would get grayer and grayer until it is completely gray-scale on the 8th day. The character's condition and physical shape get's worst and worst through out the day (giving the illusion the character is going crazy).

The player must solve a puzzle for each level on time in-order to survive the level and get out of the room and catch up to the person/thing he's chasing. The puzzles consist of random ordinary objects you find in rooms, you can combine objects to create a new object and use it to do things.

On the 8th day, the player finally catches up with the person he's chasing and the person tries to kill you, in the act of self-defense you kill him. You realize the person you killed was another you who was supposed to make it to the 9th day and then the ghost that's been chasing you was actually you from the 7th day. Because you killed another "you" you ended the repetition.


Team Changes
Our previous Audio-Design/Developer was pulled out of GDW 3 so we had to get a replacement. We got a new sub-programmer. I'll be making him assemble each level with the functions I will create for him to use.

Our New Game!

For our third year game we are planning to do a 3D first-person survival/puzzle game!

Here's a general discription of the game:



John Wriggleston is a mechanic working in a food factory. Last week there was an incident that killed four people at the factory. Little does John know he is the one that got them killed. One night working late at the factory repairing a piece of machinery in the basement John starts to hear spooky noises. The ghosts of the four people who died are coming to get their revenge! John must do everything he can to survive and escape.In order to excape, the player must solve a series of puzzles to delay the ghosts before they find you and get their vengeance.

The REAL Final Update

I wanted to show the final version of Illuminated before I stop posting here.

I fixed a few bugs a couple days ago. All but one bug have been fixed in this version and it runs very smoothly. Well I'm done working on this game, going to make something much better next year. Too bad this version isn't the one that was submitted to get marked.

Illuminated Trailer Version 2:

Thanks to everyone that worked on the game:

 

Well guess this is my last post. Thanks everyone! See ya!

Final Update + First Trailer

The game has been going very well, I have got most of the graphics to program in. I'm very happy with the graphics for the game, though it would be nice to have more graphics and to have gotten them earlier.

I ended up not using any code except for the fmod code from the assistant programmers. It was my mistake not monitor them more thoroughly and also not giving them a detailed expectations document. I ended up redoing some of the sub-programs and I didn't use some other ones.

The audio guy and I ended up doing the in-game HUD since there were some issues with the previous HUD.

There is still more work to do for the game. Only the requirements and a few other goodies have been completed for submission. For the presentation we are going to add a lot more features to it make it look nice. I'm going to be adding in glowing, and other special effects to make the game look more professional. I will also include more elements to the game play, such as more power-ups. There's only two more days to go!! I can do it!!

EARLY TRAILER (2 vs 2)

PS: The trailer is outdated now lol

Success but still not satisfied...

The game is looking very good and apparently, according to other groups, other GDW games don't have proper physics and linear algebra. Knowing that I have spent a lot of time on those parts and getting them done, I'm very proud that our game may be one of the few groups with proper/realistic linear algebra and physics.

I've loaded in some media items and the game looks and feels much better than before. Now we got cool looking graphics and sweet 3D sound. Still there are more media items coming (yes!). They are easy for me to code in and they make the game look ten times better.

I can finally spend time on coding in goodies such as more cool power-ups, special effects, more cut-scenes, etc.

I'm still not satisfied because there is much more I want to add to the game like real glowing, bump mapping and a bunch of cool features but there isn't enough time. The game is below my expectations but I'll still keep adding more to it but judging by the time left we have to submit this project; it wouldn't be enough time to add all the elements I want in the game.

Here's some screenshots of the game so far. I'm still waiting on our group slug to send me the HUD and menu for the game. That's why they are missing from the screenshots.