In the recent week, me and my group have been scrambling to come up with ideas for the assigned prototype. The prototype involves a scripted sequence similar to the scripted beginning of Half Life (on the tram). The scene had to be related to a marriage proposal. It was based on the viral video featuring a live lip dub of Bruno Mars’ “Marry You” song. The following video can be found here:

Overview of our final product:

The final product we produced was based on a neighborhood scene. It was a scripted scene, where a car would travel through the neighborhood streets, similar to the viral video, to eventually reach a church at the end. Along the way there are particle effects added to convey a happy celebratory mood. The song we chose for our scene was Foo Fighter’s “Everlong.”

In this blog post, I will be discussing the aspects which I worked on. A full write up on the prototype can be found at the following link:

The write up was written collectively as a group, each person writing about the role they played in the prototype. Please excuse me if it sounds similar, in regards to the parts I contributed.

How I contributed:

My main role for this prototype was to model the setting for the scene. I originally started off with a city scene, thinking it would be a good idea to have the setting for the scene based on the city streets at night time. I also wanted the streets to spell out “Marry Me?” if the camera zoomed out to a top down view. After modelling a city landscape, it was decided it looked too industrial and cluttered and did not match the mood we were trying to convey for the scene.

Thankfully I did not spend too much time on this original scene, so scrapping the scene was not a huge blow, and in addition to building the original scene, it taught me many things on how to model the scene in my vision (motion paths etc.)

In the end, I decided to approach modelling the scene after a small quiet suburb/neighborhood to give the homely, humble and warm feeling we were trying to get the video to convey.

Here is a snippit/preview on a street level of the scene:

I also wanted to have a significant ending when the scripted car would reach the end. Here I added a church at the end of the streets. At this moment, the camera would pan out to give a top down view on the town, to write out the message of “Marry Me?”

 Here is the top down view of the neighborhood.

My main challenge was making the letters/message on such a large scale that the player/viewer would not realize it was actually spelling out the message. I was aiming for them to think that it was just a series of twisty and straight streets. In the end, from the street level view, I don’t think players notice it is actually a large cursive message.

After I created the overall setting and scene, my other team members pooled together their assets such as particle systems, and it was all scripted together/sewn together to create out final product.


Overall, I was very pleased with the scene I created for our prototype. It conveyed the motions through the setting exactly how I wanted to, much better than the industrial/urban mood the original city idea created.

I’m hoping to have a video of the entire scene up soon! Stay tuned.


Seems I am falling behind on posts for Game Engines! Well here’s another update on my progress in the past couple of hectic days.

As for homework questions in the course goes, last week was a race to program and figure out the process of making a detailed solar planet model for a medium ranked question in the course.

The application had to show accurate planet rotations, orders, moons and when you clicked on the planets it had to show a HUD full of good ol’ info about the planet.

What I learned:

The main goal/purpose of this assignment question was to learn how to parent objects effectively (scene graph) and learn how to use Ogre3D’s ray casting functions.

How it looked:

Here is how my solar planet looked. Yes I know the Sun is too small. But oh well. I’m not an astronomer! I’m a programmer! 


For parenting, it was actually pretty easy. Every planet and moon needed to have it’s own node for the object to be drawn/attached to in addition to being a child node to a node that it would rotate around.

Moons would be parented (be children of) the planet they would orbit, and have their own node for the sphere to be drawn and textured. The planets would be children of the root node, which is the center of the solar system (the Sun).

Now, I made the mistake of making the Sun itself the root node at first. Why is this a problem you may ask? Well you see, if I made any changes in scale, rotation or position to the Sun, it would result in changing the attributes of all of the root node’s children. So if I scaled the Sun bigger, it would make all the other planets bigger too!

So in the end I learned I needed to attach the Sun separately.

Ray Casting:

In order to be able to select an object, I had to learn how to ray cast in Ogre3D. What this is is essentially a ray is shot from the cursor of your mouse into the screen. The cast will give you back whatever object it hits. Thankfully there is a build in iterator which helps you sort out the objects, and essentially find the object that is closest to you, which is what you want, since you want to select that object and not an object behind it.

This is a useful function to learn because it teaches us how to select an object, and discard any information about object selection with objects you do not want.

Midterm Summary/Reflection

This recent Monday, we had our Game Engine Design midterm. So how’d it go?

I believe I did okay. Not the best, but I certainly hope I passed! What would I have changed in preparation for the midterm? Studied more! Read all of the textbook chapters! I was crunched for time and did not read up on all the stuff I should have. After the midterm I started reading, and sure enough the next couple pages covered some questions in the midterm that I didn’t know how to answer!


So a good tip to my fellow students; READ THE TEXTBOOK! It really does help (for the stuff I did manage to read, I managed a great understanding of those concepts)


Also, brush up on your matrix/quaternion math. You should know that stuff all the time. Especially inverses.

This post is a continuation of my original post of ideas: Magic Elves Taking Turns Breaking Rules Chasing Fine Art: Ideas for a Prototype

Sorry for the delayed post for the update on the board game, but it was presented last week and submitted. Here I will elaborate on the original ideas, with rules and concepts for the game.


The world is in ruins in the medieval era, where nations are battling to take over territory and gain an edge on each other. There is one epic wizard in this land; Merlin. In his possession are ancient art pieces that can give it’s wielder unimaginable powers. Merlin, knowing that the nations would be on the hunt for these artifacts, destroys them into several pieces and goes into hiding.

The nations have already heard of these mystical pieces and are on the search for Merlin to gain the power to take over the other nations. The Humans, Elves, Orcs and Unicorns scour the world in an attempt to find Merlin. Occasionally scouts spot the mystical hermit wizard and the nations race to find him and the art pieces.


Collect all pieces of the ancient artwork before the other players do.



  • Turn-based roll of the dice (higher roll wins)
  • Similar rules to Risk
  • Attacker has 2 dice, defender has 2
  • Dice are picked highest-to-lowest
  • After every roll, the player with the lowest roll will lose 1 unit from their territory
  • First player to lose all units in a territory forfeits the territory
  • If there is an art piece being held by the units, the art piece is dropped and forfeited


  • The last player in the turn cycle will draw a card at the end of the cycle
  • Cards have special characteristics which alter the way the game is played, which can also overwrite some of the major game rules
  • Example: One card changes the boundaries of one nation to encompass others (sublimation), another breaks a bridge between two nations (tsunami), etc.


  • Players must collect the art pieces
  • Art pieces are represented in their own deck of cards
  • At the start of a game, a player draws a card from the “art” deck and that card determines where the first art piece is placed
  • When the first art piece is collected, a player draws from the deck and a new art piece is placed on the board
  • Any units on that space where the art piece is found on are immediately destroyed
  • Players have to collect four pieces to win
  • When a player collects an art piece, the art piece is now considered part of a “unit” and other players can steal this unit by defeating it in battle
  • The art piece unit gains a +1 on their roll, as well as any other units on the same square


  • Capture-The-Flag/Turn-Based board game
  • When crossing continents, you must have a squad containing 5 or more units
  • You can only move your units to adjacent territories (or to any territory connected via a bridge)
  • You must have at least 1 unit on a territory to have it considered yours
  • For every territory you acquire, you can move one more unit (get more movement per turn)
    • Ex: If you own 5 countries at the start of your turn, you can move any unit 5 times


The Board and Cards:



Note: It seems I overwrote deleted the final draft of the write up for the games rules. I also submitted the final draft to my TA when presenting the game. Please excuse me if some of the rules seem confusing as I had to write them from an old document+memory. Thanks!

Last week in class we were presented with the concept of an audio only game. As a class we needed to create a physical game for our professor to engage in. It had to be fun, exciting, have rewards, and be based on audio cues only.

We split off into several groups while our professor left the class room, so each group could come up with ideas. Then at the end of brainstorming we all had representatives from each group to go to the front and explain his/her idea. The class as a whole voted on what they thought was best.

In the end we voted for a very simple game, which lead to being a huge mistake; more on that later.

The Game

In a nutshell, what the game we decided on was for the professor to come in blind folded and be guided through a maze in the class room. The students created human maze walls through the classroom and whenever the professor would come too close or in contact with a wall, a beep would be emitted from the student. This would guide the professor through the obstacles in the classroom, to reach the end; the goal.

Here is a simple diagram of the layout. Squiggles represent desks that are obstacles that need to be jumped over; blindfolded. 

The Game: Conclusions

After the game, it proved to be too simple, and lacked any excitement or enjoyment for the play; our professor. It was simply lacking in any reward system for the player and did not entice the player to want to play more. There was no satisfaction in playing the game, or reaching the end. When coming up with the idea, simply reaching the end was “the reward.” This is not a reward. The player simply reached the end and did not gain anything positive from the experience.

We as a class failed to create a good audio based game.

What would I change to the original concept?

The game was missing too many things, or rather it lacked elements to make the game enjoyable. A good way to make the game more challenging and less linear, would to be to add an enemy.

The enemy would start after 10 seconds of the player starting in the maze, which would be signified by a large frightening sound that could have been played from a laptop, to signify something “scary” was coming after the player. This would urge the player to go faster and something negative was coming after him/her. The enemy would be a student who is also blindfolded, but could carry a laptop playing a groaning sound, or they themselves would make a grotesque noise to let the player know where the enemy was and if it was catching up.

The goal would now be for the player to reach the end without encountering the monster/enemy. To add more into the game, some “walls” (students) could have power ups for the player, such as Freeze, which would freeze the monster for a specific amount of time. To find these walls, that student would let out a different audible sound if the player faced that wall (instead of a beep, maybe an obnoxious honk. Or a quack. Something different).

Overall if more “fun elements” were added to the game, I think it would have been more enjoyable and would have not failed so spectacularly.

Moral of the activity:

Some people say to keep things simple, but never simplify things to the point where it no longer serves its original purpose. You can make a simple chair, but cutting off the legs to simplify it won’t make it a better chair; or even a chair for that matter.


Success! Over the end part of September and beginning weeks of October, I have started catching onto how to use Ogre3D and TwoLoc. Contrasting my first blog post for INFR 3110, I really am starting to get the hang of programming with this engine.

The feeling of being able to finally create something of my own is great, and motivates me to strive to learn more and create more complex things. At the end of working furiously, I have come out with 4 products (easy questions) that function as requested!

Easy Question 1:

The first step to programming in TwoLoc was to load a textured model. For this question I leaned towards Ogre3D’s preferred model file type, a .mesh file. I also discovered that after exporting a .mesh of an object, a .material file accompanied it. I also discovered after a long while of tinkering, all names of materials are listed in the material file. After ironing out a few details I was presented with a textured model! Success!

Easy Question 2:

Question 2 was a robot arm! Create a working robot arm with movable portions similar to a real robot arm. This question taught me about creating entities in TwoLoc as well has parenting nodes, offsetting nodes and all sorts of useful things. Oh and keyboard input control!

Question 4:

This question was to create a tree using billboards and impostors. It took a while to do, simply due to confusion on what the question wanted. But the product is a very low poly count tree that can be used in game!

Question 6:

In this question, we had to create a skydome. The skydome also rotates around the world plane with an update that is called where it increments its rotation around. I think it looks pretty neat, and overall was actually pretty simple. Another useful thing that can be applied to this year’s game.


Overall it’s been a pretty hectic month trying to learn and complete these items. But hey it’s part of the learning process. Hopefully things keep on chugging along smoothly!

In last week’s Game Design II lecture, a major topic we discussed during class was reward systems in video games.

What is a reward system you might be wondering? Simply put, it is a system that rewards players in a unique aspect to interest, capture and motivate the player to play further. There were several examples covered in the lecture of the different types of reward systems that are found in today’s games.

In my blog post, I will be more specifically discussing my personal favorite reward systems in some games.

Materialistic Rewards/In-Game Content Rewards

What I mean by this type of reward is in certain games, you unlock certain items. Keep in mind, I consider unlocking items very different from getting rare items in other games. I think there’s a huge difference and preference when it comes to how certain items are actually acquired. What do I mean by this? Well…

When it comes to getting items through finding them in loot in MMORPGs, I’m not as much as a fan. There are reasons why I don’t like this reward system as much as unlocking items. A good example of this is World of WarCraft. Back in the day when I played WoW (dark and endless days in my room), there would always be rare items when doing large quests/raids. These items are randomly dropped and have very low drop rates, and then if you’re in a group you have to either Greed or Need roll for the item. In the end, getting an item is a lot more challenging, and you also never know what you would get.

I believe the core aspect of random loot/rewards for players that I dislike is the fact I don’t know. It is basic instinct of humankind to fear what we do not know; therefore there is a negative stigma of not knowing what lays ahead of you.

Screenshot of the old days of my low level mage from WoW.

On another note, I will now talk about the unlocking item aspect of the materialistic reward system. A good example of this is Battlefield 3. There is a very nice layout on the battlelog online which shows you all the current weapons you have, and how you’re doing in progress of unlocking the next best thing.

Not going to post my gamer tag, but as you can tell I kind of suck haha. But moar guns means moar motivation to get better and play MOAR! 

I enjoy this reward system of new items from Battlefield 3 much more than a random drop aspect of World of WarCraft.

“But wait Calvin! That’s not fair comparing a MMORPG to a FPS! Your argument is irrelevant!”

Actually no, they both involve materials/items a player uses in game. But to support my argument of random drop versus a structured unlock guide, is Team Fortress 2. TF2 has random drops for items as well! And once again I am not a huge fan either.

Overall I find presenting the player with all the potential rewards he/she can reap is a much more effective reward system for players. This will encourage players to “get one more kill” and play a bit longer to unlock another item; versus a player aimlessly playing, quietly praying for a random rare item drop. Anyways enough of my discussion/ranting about reward systems!

What’s your favorite type of reward system?

I’ve been putting off writing this post for a while now, always thinking I’ll do it later but then totally forgetting about it and pushing it further and further back. Well I’m going to write my post now about last weeks adventure during my Game Design II class.

For this class, it was a bit different since it was outdoors. We were lucky enough to do an activity which involved the outdoors, versus being crammed in the small classroom during lectures. This already looked promising.

Next we were assigned our activity, which was, as a group we must create a game which involves a large ball, small ball, and a rope circle. The objective of the game had to be:

  • The small ball had to in a rope circle
  • The team must have the large ball in their possession
  • Cannot be a game that already exists to our knowledge
  • Probably some other details that I forgot

In addition to these core rules, we had to add a bit of a Battlefield twist to it. We had to include “classes” from Battlefield, to our game, and overall had to make their inclusion make sense and have a function to the game.

As our team was discussing possible ideas, I thought of the old idea of planting a bomb, and getting intel/codes for the bomb. So I decided to make a ball game out of this idea and here are the rules and setup as follows:

  • The field resembles a soccer field, where it is rectangular, rope circles placed at ends of the field, and there is a half line
  • The rope circles represent the teams’ headquarters
  • The large ball (Intel) is placed on one side of the half line, and the small ball (Bomb) is placed on the opposite side
  • Teams have 2 players each (we only had 5 players, 1 ref, 4 players)
  • Each team will have 2 classes, Support and Assault
  • The goal for a team is to plant the Bomb into the opposing team’s circle and return to their own HQ with the Intel

Sounds easy enough yea? Well this is where the classes come in to give the game a bit more of a twist. Here is what each class entails:

  • Only Assault is allowed to carry and plant the Bomb
  • Only Support is allowed to carry and take the Intel
  • When in the opposing team’s half of the field, you are allowed to double hand tag the enemy
  • When tagged they must drop the Intel/Bomb if in possession and return to HQ to “respawn”
  • Only Assault is allowed to tag Support and Support to tag Assault

These classes and rules actually changed the game up quite a bit, and indeed did make it a lot more interesting. Players were running for their appropriate balls, and while in enemy territory trying to avoid their opposing class in getting tagged.

Here’s some media from the day’s activity below!

Here’s me trying to draw up some plans and rules for the game. There was a lack of table space outside. Jason looks happy.

Getting Jason to read over the rules to make sure it all makes sense so we can play! I’m holding the pen quite aggressively.

Here is the Hello Kitty Intel ball planted in the middle of the field. Must be of some use right? It’s Hello freaking Kitty.

And a video of the game in action!

Note: I do have permission from Mike Antonakes, the original owner of this media and fellow group member, to use it in my blog post.