Web Dev Update

So the website was completed and it is now live and available at : http://www.dnetsolution.com/

Earlier this week I said I would post at post mortem of sorts about my progress with developing this website since it was one of my main and largest tasks to do over this summer in comparison to the other things I have done.

I shall go into detail of each page individually:

Home Page

Home Page
Home Page

The old home page had a lot of unneeded info on it and it made it a bit difficult to look at to understand exactly what DNET Solution is.  For my homepage I decided to strip it away and follow a really minimal approach to everything.

Home Page 2
Home Page 2

For the rest of the homepage I highlighted the main product which was the Supermedia where DNet makes its main profit from.  For the footer, I also kept it simple by having a simple and sweet ‘about us’ statement and a few outgoing links to other DNet portals.

About Page

About Page
About Page

The about page defaulted to the Contact us subpage because I felt that it had the most important information to help a client reach DNET and a form to send us any email really quickly so the person would not have to load up their email.

Our Story is a small subpage with a bit of  a company blurb, nothing too fancy.  Gallery has a few pictures of DNet products and a nice lightbox display that fades the entire screen when you click each image as it opens up in full screen.

Also note that the subpages do not need to be loaded separately.  They were preloaded to make browsing faster since they all technically exist on the same page.

Product Page

Product Page
Product Page

This page was really hard to do since the old version was super clunky.  I decided to stick with my minimal approach and remove a lot of hindrances and highlight all the products at the top with a collage, then have each product section at the bottom in an accordion that the user can click and interact with.  Rather then loading another page for each, I just placed each product neatly hidden in each button.

Product page, Accordian
Product page, Accordion

The accordion works really nicely to hide each product neatly into the buttons and it allows for a very fast way to view each product. When you click on the other “Specification” button you are able to download the a data sheet for each product.

Download Page

Download Page
Download Page

I didn’t want to keep this page, But I ended up having to since my boss was adamant about having a page to send his clients to, so they may download important documents about our products.

News Page

NEWS Page
NEWS Page

I made this page entirely out of embedding a tumblr blog that I set up so that my boss did not have to keep updating the website when he wanted to make a change to the news section.  It feeds info from a DNET tumblr page and it auto updates with every new post.  It is a lot easier to use tumblr then to update a website, which is why I chose to do it this way.

Quote Page

Quote Page
Quote Page

Another really simple page that just allows a user to enter data into a form so that an email will be sent to the sales team to approach them.

 

Aside from that that is pretty much the website I built in about a week and a half.

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!