Week of Web Development and Directing

This week felt relatively slow since  my time was split between finding time to work on working on the website and working with my boss, David, to film video demonstrations.  The video demos are ways to instruct our future clients and overseas partners in exactly how our hardware works so if they are asked questions during sales meetings they are able to answer them.  They also serve as a good tool on learning how to demo the device in those sales meetings.

I was in charge of filming and editing the video.  David wanted to film the video in one smooth take so I could edit it as fast as possible and have a video ready as soon as possible.  He was surprised that I was able to edit it and have the video ready by Thursday since he was heading to China this weekend and I guess it made his meeting with his partners a bit smoother.  This coming week will be a lot shorter while I will be doing the same mix of web development and video editing tasks again.

It will be shorter since myself and most of the Global Edge crew will be going to Boracay, Philippines!  I am pretty excited because its supposed to have one of the best beaches in the world.  I really hope the weather doesn’t ruin it, since I saw that it might be raining for a bit.  But what I am really excited about is the cliff we will be jumping off into the sea.  Its called Ariel’s Point and its about 50 feet high and compared to the 20 feet waterfall in Luk Wu stream here in Hong Kong that we jumped off, its should be really fun!

Aside from that I have sat down for a Skype meeting with one of David’s daughters who is studying marketing in America and she gave me a few tips on what she didn’t like about the old website that I plan on incorporating into the new one sometime this week.

Here is the Video Demo I worked on this week:

Component Based Engine Architecture

This year we have had a lot of discussion going on about how we would like to go about building our game engine.  With about a week and a month left before its due, most of us have decided to build it using a component based engine architecture.

Basics

This post was helpful for a good 5 min intro to the topic.  Here is pretty much a summary of it:

Generic Engine Architecture

The base concept is rather than having a giant monolithic  class based game structure (above), we want to inherit from a base class that gives everything full functionality.  Imagine the base architecture of Unity.  Everything starts of as a GameObject.  You can add scripts, models, and other functionality to it by dragging items onto it.

The problem with the monolithic class structure is that classes end up having the same functionality and in return things get really messy.  Most games get around this by making a really large base class with lots of functionality while having the subclasses turn functionality on and off.  This becomes a problem when adding new features because items have to be able to coexist with one another.  Since we pretty much add functionality to our game engine the entire year, adding functionality has to be really simple and we don’t want to waste the precious time we have taking one step forward and two steps back.

Say we have three main game items in a component system: a Player, Enemy and Item.

• Player
  • Spatial
  • Rendering
  • KeyboardMover
  • Health
• Enemy
  • Spatial
  • Renderer
  • AIMover
  • Health
• Item
  • Spatial
  • Renderer
  • PhysicsMover

Spatial Component – Allowing it to exist in the world
Renderer Component – Allow objects to be drawn into the screen
Movement Component – We may want to control the player through a keyboard system, enemy through AI and the Item through world physics
Misc Components – We may want some objects behaving different from one another.  Like giving some objects health.

Our component class would look something like

• Component
  • Spatial
  • Renderer
  • Health
  • Mover
    • KeyboardMover
    • AIMover
    • PhysicsMover

Summary

We are currently working on some sort of implementation of this system.  We have split up into 2-3 engine programmers and 1 person working on getting animation to work using a skeletal animation system.  That latter job will most likely be mine, and it shall be quite the interesting job to take on!  I have already done some research with the mesh skinning shader and we have a rigged character to test with.  All thats left is to make a demo that will work.

References:

[1] – https://github.com/shrt/ComponentKit
[2] – https://github.com/PushButtonLabs/PushButtonEngine
[3] – http://stackoverflow.com/questions/1901251/component-based-game-engine-design

Homework Questions!

Its been a while since I have posted about anything to do with this class.  This is because of the shotgun of work being blown my way recently. 3rd year game dev = hardest year yet.  Its hard in the sense that there are not enough hours in a day that allow me to accomplish everything required of me.  So its gotten to the point where some work gets prioritized over others and the rest falls through the cracks.

Ogre

Anyways moving onto Ogre.  Its an amazing engine from what I have seen of it.  The only issue is that it requires a higher level of programming skill to debug.  Last year the errors were solvable through simple debugging methods (stepping through, print statements, etc.).  This year you really have to have a good handle of how your code gets compiled and what it is asking the engine to do.  Which involves using the call stack.  I don’t really know how to use the call stack that well, so this is an EXCELLENT learning opportunity.

Homework Questions

So the easy question deadline got pushed to Monday.  I managed to finish 4 easy questions (1-2. 4-5).

Easy_1 was easy.  The key was understanding how Ogre worked.  Create a Scene node pointer for your entity to attach to.  Create a entity pointer that you attach to a prefab cube and all thats left are the two lights.

Easy_2 was a bit more work.  This question was mostly about understanding the hierarchy of the parent-child relationship of scene nodes.  We know that we have to create 10 separate cubes for the robot arm.  Right away you should think about 10 scene nodes and 1 entities.  But it would be stupid to make them all children of the scene manager.  So you would just make them all children of whatever entity they would be rotating around.  The only problem about only having 10 scene nodes is that the rotations look fairly wonkey.  You need to have rotation joints halfway in between each entity.

Easy_4 was probably the most ‘difficult’.  Since it involved dealing with .material files.  They are still simple however.  Once you figure out how to edit the resource.cfg file to load resources into your game, the next step is the .material file.  Its pretty much a plaintext structure that is easily readable. You just need like 5 lines of code to create your textured material for your ingame object.

scene_blend alpha_blend
lighting off

This goes after pass.  scene_blend does something with the alpha values, and I had to turn the lighting off because I was having an issue with the object turning black for some odd reason (Thanks Kevin! @Iceninja77).

texture leaf.png
filtering trilinear
colour_op_ex source1

This goes after texture_unit.  This pretty much textures your object.

The rest of the code involves making 4 planes rotated at 90, 180, 270 increments textured to look like an imposter and calling the createBillboardSet command to create your billboard.

Easy_5 was probably the one I finished the fastest.  TwoLoc has an interesting dynamic texture class and a base example called BlitTexture something that is a huge help for this.  If you use this as your base project and solve a small error you are worthy to use it!  There is a function randCol(x,y) that can access the data of a pixel on the plane/billboard that you would like your texture to be put on.  You can modify the RGBA values given a row and column point.  So be creative and make something cool!  I was lazy so i just made a few designs using a for loop.  Some people made mini-games, drawing tools and even an etch-sketch!

 

Level Up: Aftermath

Hello!

I am writing this after commuting home from the Level Up convention/award ceremony/event.

It was truly a great and interesting event for a number of reasons.  I did not plan on going until I saw that our Game Design class was cancelled at night.  At this point the only thing stopping me from going was my own laziness.  I tried to grab my other group members to join me, but I only managed to get Kevin.  Probably the best one to bring anyway.

While we never had any intention of showing of our game, or worked on it exclusively for Level Up, as soon as we got there we began debugging.

At this point out game had no sounds, no HUD and an imbalanced game system.  We did not have our blacksmith master menu system that would allow the player to level up their items and complete side quests.  We just had several battles linked by using a little rotating exclamation mark.

We had left with Gary’s group and managed to get to the convention by 3pm, from then till 5pm Kevin and I were debugging.  I was fixing the shader lighting and Kevin was balancing the game to showcase.

We essentially prepared for a huge Q/A session to gather a whole bunch of data.  I wish we had put more effort into getting a HUD into the game. Regardless of the HUD I learned a lot of stuff about the game that I would not have been able to find out through normal testing.

What needed to be fixed

Aside from the obvious points of making the game look prettier by adding higher resolution textures, HUD/GUI and the rest of the shaders.  We noticed that the collision system was a bit wonky and people were having issues with depth perception.  There needed to be a greater collision response for the player since most of the time people were asking “am I even killing this monster?”  Also the AI were updating way to fast and were very difficult.  People were getting cornered and died fairly quickly.  We need to allow the players to exit the battle and upgrade their equipment rather then re-spawning them in the same level.

The great thing was that there were a lot of artsy girls and male programmers along with some gamers who tested our game.  I noticed that some guys were very aggressive and tried to parry and dodge while moving back an attacking.  Many inexperienced gamers just stood there, got surrounded and managed to die.  Granted when Dr. Nacke and Dr. Hogue tested our game they both had issues with the HUD and the obvious problems.

I also noticed that some people were having issues with the camera movement.  We need to slow down the intensity of the camera movement since some people ended up staring down into the ground because the camera acceleration was to fast for people with slower reflexes.  It would be good to have the player adjust the camera acceleration to their preference in the final version.

When people were in the forest area, they would walk around aimlessly and end up having a horde of enemies chase them while they ran backwards and attacked.  The forest area should have regions where only some beasts spawn and they patrol that area.  Many times people spawned and were surprised that a wolf began chasing them.  We need to have better and smoother transitions between levels that give players a safe zone that they can chill back in.  Players need to make the decision to enter a dangerous area and provoke an enemy attack.  Rather then having the AI walk towards you in a line, they should recognise that they are colliding with each other and push away to corner the player.  The AI need more behaviour that will allow for a more robust battle system then just the player running backwards and attacking.

Overall, we need to give the player more and better feedback during gameplay.  We need to place our HUD into the game to tell the player how much stamina and health they have left.  We need sounds to show the location of the enemy, and tell if they are hitting an enemy.  We need to add more AI behaviour instead of endless seeking.

Lessons Learned

We went there with a 2 man team from a group of 6 people.  We went in unprepared with little expectations.  By this time next year, we should have our game completed and use this event to test our game out with a different crowd and have several different versions to test different things.  There were different types of people that played our game and it was evident in the way they played it.

For example:

• Experienced gamers adapted very easily to the WASD controls and managed to survive for a while
• In-experienced gamers got completely destroyed and would have preferred a controller layout with simpler buttons
• Players had to bend down or kneel on the floor and were in a very uncomfortable position playing the game, giving a negative feel to the game already

Next time we should prepare a variety of versions of our game with different control layouts and a proper chair and screen for them to play it on.  Also polish.  Our game needs to be very polished.  By this time everything should be implemented, and we are just performing balance and fun testing.

Is this level to hard? Do we need to increase our collision response? Should you be sprinting faster? Do you need more stamina?  We should be finding the answers to these questions in preparation for the final GameCon.

Final Notes

Overall it was a good event and I did learn a lot.  I got to bond with some fellow classmates from all years of the program.  We debugged and found errors in our game and code.

Some of the attendees offered awesome advice and seeing them play the game and enjoy it regardless of the state it was in really made me happy.  Considering this was an unfinished game, I just wondered how much better it could have been and I deeply regret not preparing a better version for this day.

People were really impressed with just the fact that we built out game from the ground up not using anything.  Some people even had a hard time believing us that we were not outsourcing anything by using external programs like Havok for physics.  This probably made me the most proud to be apart of UOIT Game Development.  That and the fact that one group that was using Unity Toon shading had several members who had no idea how to do edge detection and did not know what the Sobel Operator was.

I am looking forward to going to more of these events in the future and creating better polished games in the near future.  Time to get some sleep. GOOD NIGHT!

Thank your for reading,
– Moose