Monthly Archives: October 2014

Game Engineering Assignment 06

Controls

Box: W – Positive Z; S – Negative Z; A – Negative X; D – Positive X; Q – Positive Y; Z – Negative Y; R – Rotate in Positive X; H – Rotate in Positive Y; T – Rotate in Positive Z; V – Rotate in Negative X; F – Rotate In Negative Y; G – Rotate in Negative Z

Camera:  I – Positive Y; K – Negative Y; J – Negative X; L – Positive X; U – Positive Z; M – Negative Z; Insert – Rotate in Positive X; Delete – Rotate in Negative X; Right Arrow – Rotate in Positive Y; Left Arrow – Rotate in Negative Y; Up Arrow – Rotate in Positive Z; Down Arrow – Rotate in Negative Z

Abstract

The project has been updated with new builders inside the tools.  There are no visual changes.  The file structure now includes precompiled shaders.  The reasons for compiling at build time instead of run-time is for speed and reliability.  The program gains speed since clock cycles can be devoted to other tasks than compiling the shader.  The program gains reliability since build errors will before run-time helping to ensure the end-user does not end up with broken software.

Aims

The aim of the sixth assignment was to develop more build related tools to make the build process more efficient and robust.  Efficiency has been gained since shader compilation now happens at build time allowing more power for other tasks.  Robustness was gained by building a structure for builders that allows more than one builder to run a process with input from a human readable file.  Human readable files provide a means for none programmers to change the project without neccesarily needing the aid of an engineer.

Implementation

I built a Lua file structure for loading shaders.  Using an example from John-Paul I made modifications to the generic builder to specify the file extension in the arguments of the file.  The generic builder does a direct copy of data, but needs to know the extension of the file.  There is likely a programmatic solution to the problem, but for now users need to express the extension of the file.

The builders to this point are the Shader Builder, Mesh Builder and Generic Builder.  The Shader Builder compiles shader files that have been placed in the assets folder and added to the list.  The Mesh Builder is a work in progress and will compile mesh data to a binary file helping to streamline asset creation.  Lastly, the Generic Builder copies files directly with no modification.

Organization

My Lua file specification for sending assets to the asset builder employs a human readable format similar to the one employed by John-Paul.  I wanted to be able to change extensions, so I kept the extensions.  I extended the generic builder to require the file extension as an argument.  I will be looking for a programmatic way to handle extensions.

Here is the structure of the asset build list Lua file.

–[[
This file lists every asset to build
]]

return
{
— Shader Programs
{
builder = “ShaderBuilder.exe”,
extensions =
{
source = “hlsl”,
target = “shd”,
},
assets =
{
— Vertex shader programs
{
name = “vertexShader”,
arguments = { “vertex” },
},
— Fragment shader programs
{
name = “fragmentShader”,
arguments = { “fragment” },
},
},
},
— Meshes
{
builder = “MeshBuilder.exe”,
extensions =
{
source = “mesh.lua”,
target = “mesh”,
},
assets =
{
{
name = “cube”,
},
{
name = “floor”,
},
},
},
— Generic Assets
— (That just get copied as-is rather than built)
{
builder = “GenericBuilder.exe”,
extensions =
{
source = “txt”,
target = “txt”,
},
assets =
{
{
name = “material”,
arguments = { source = “lua” }
},
},
},
}

There are dangers to the file format.  The file runs the risk of getting long.  Ultimately developing a tool to manipulate the file without text will be necessary.  The design is programmer friendly, but will get unwieldy for non-programmers.

Issues

I had an issue with loading the shader binary data.  I thought it needed to be loaded into ID3DXBuffer somehow.  Saumya pointed out that the data was just binary data and could be used directly through a DWORD*.  John-Paul added that any pointer to raw data would work including DWORD* or void*.  I have worked with memory directly, but for some reason I thought it needed to be in a special struct like ID3DXBuffer.  I am grateful for the responsiveness of the engineers in the course.

Time Estimate

Given that fall break was during the assignment the workload wasn’t bad.  The problems were minor and light.  I do estimate I was within my 12 hour estimate for coursework from the class.  I am going to try to get the mesh loader done early so I can spend more time working on IGF related projects.

Activity Time Spent
Implementing New Builder Information 4 hours
Architecting Lua Reader for New Asset List 2 hours
Adding Shader Loading to Game Engine 2 hours
Write up 1 hour
Total 9 hours

Roller News

I am now back to working on Roller.  I will get tasks done on Hostile Territory, but I am not in a high enough position to change the design.  Instead of spending time working on lone wolf projects to try and save the game, I have decided to use my energy to get Roller into IGF.  I will give both games the time they need.

I showed Roller off at the playtest.  The game has some major flaws.  Creating a new mode needs to be streamlined.  The menu needs art.  The collisions need to be elastic.  I did receive a complement about the scope of the game.  The game also has a clear goal with falling off being something to avoid.  I am excited to make the game amazing and will continue to bring it in for testing.

Hostile Territory; Long Time No News

September was a whirlwind.  I will start as far back as I remember.  There have been a lot of engineering related changes.  I am frustrated with the engineers on my team.  I feel a lot of changes are inefficient and unwarranted.  I will explore how we are wasting time.

For the month of September I was nominated to work on a character controller.  I put together a character controller with wall walking that I was continuing to tune.  The problem was that the controller was not in the game.  At the same time another engineer was working on updating the architecture of the game.  The two tasks overlapped, so the work was replicated.  In the end we took the controller developed in tandem with the architecture changes since the code base would be more similar.

Overall the controller and architecture update was a failure.  We lost weeks of work making the same thing we had during the first few weeks as far as what the user sees.  The only advantage we have at this point is that the architecture might be easier to maintain.  The problem is that the architecture updater feels obligated to curate committed code.  I have been making efforts to work with the curator because we have no time to argue.  We have already lost enough time with overlapping work and rebuilding the project.  The engineering team spends more time on semantics than actually getting work done.

Rob committed some art that made the game look much better.  I think the cave level is amazing.   Maybe it is a giant worm?  Maybe we will be digested if we shoot the walls too many times?  I have a screenshot of the first person build.  Going through the code base it looks like the temporary flag I put in place for first person mode has been subverted, so I can only run the build in first person.  There is a lack of communication on the engineering team as well.  It appears the mesh was removed from the player so it is in third person, but the player doesn’t show up.  This appears to be hack around code that was already in place serving as another testament of our engineering teams inefficiency.

Last Friday we had a cohort wide playtest.  I have a review for each game.  I will now go over the problems for each game after playtesting.

“Premonition” was easily best in show.  The game mechanics are coming together.  I would give a warning that they are dangerously close to becoming Sonic without the polish.  The goals are simply to run in a direction indicated by green markers which means without green markers the game falls apart since the direction to the goal is never indicated.  The game can be played without using the reveal mechanic, but a time incentive might provide the benefit needed to fix that issue.  A lot of time is spent on exploration, but the gameplay is trying to push the character through as fast as possible.  I would slow the game down and add deeper puzzles requiring the premonition mechanic.  Overall, the showing was great and your team is at a good point to start balancing.

“All is Dust” is a visually stunning game with a lack of gameplay.  The game is about being in corn the entire time, so most of the visuals are missed since the screen is filled with green.  The reason the player is forced into the corn is because crows can’t hit you while in the corn.  The benefit to being outside the corn is too little for it to make sense.  The goal of the game is not clear since the only direction is head to the farmhouse.  There is too much focus on narrative that the game doesn’t provide directly.  The scarecrow attacks the player indirectly with crows, but the player doesn’t associate the two.  The crows are only there to drive the player into the corn.  The mannequin game has become the corn game.

“Hostile Territory” had a mixed showing.  Some people understood the game with minimal explanation.  Other people didn’t get it at all.  I think the audience that got it were console first person shooter aficionados.  There were some large problems during the showing with Hostile Territory.  The standout problem was jumping resulted in a crash to desktop.  My guess is that it was a last minute “fix” that wasn’t tested until the public showing.  I made a similar mistake at my first programming job.  Mistakes like that embarrass the entire company.  The second standout issue was the lack of an intuitive goal.  Health seemed like an afterthought.  Players were not noticing health at all.  Watching the game seemed like the understood goal was shoot stuff until the game ends.

“Make a man thinketh” didn’t even show up.  I am scared for the team since they lack a build at this point.  I hope they have enough code base to pull it off.  My guess is that the producer to skilled worker ratio is to great.  I hope the two engineers and one artist can pull off something like the game “Make a man thinketh” deserves to be in the limited amount of time they have.

The portal looking things at the end of the tube confused players.  I heard a lot of people trying to get in the portal.  Ultimately that art needs changed.

The control scheme is difficult.  If players are used to inverted controls moving the camera is impossible.

On the design front I noticed a lot of issues.  The question, “why can I move?”, is still coming up.  The goals of the game i.e. shoot the other player or shoot the walls to claim territory are juxtaposed in a non-sensible fashion.  A question left unanswered in the gameplay is “why am I shooting the other player?”.  Health seems like an afterthought and players didn’t notice it.  I found the game is best played in place while jumping into the air and turning.  The game also lacks strategy.  There are no combinations the player is aiming toward.  The player just holds the trigger down until the game ends which is still to hard to determine without knowing the design intimately.

Production is serving as design on the team, but has failed to address the issues above.  With these issues in mind I have two suggestions.  First, choose shooting or moving.  If the game has both find a real reason for both.  The game is about painting the walls.  Make the game about painting the walls with a single mechanic to facilitate that goal.  Make sure the goal is very concrete and intuitive.  In a single sentence someone should know the goal and potential strategies.  Picture two people sitting on a couch.  They have never played the game.  Do they understand they need to kill each other or paint the walls?  Do they understand both?  Watching the playtest I can firmly state that the state of the current design

Second, make the game intuitive with a single mechanic before making half a dozen mechanics.  If the game doesn’t make sense with one mechanic throwing more at it doesn’t make it make more sense.  We need to play our game to make sure it makes sense.  We need to listen to everyone playing our game and figure out what makes sense.  We do not have to pander to every voice of dissent, but if a child or person that doesn’t necessarily play first person shooters picks up the game and can’t figure it out we have an issue.  If the audience is console based first person shooter players with a high Call of Duty kill to death ratio then maybe we hit the nail on the head with our design.  My guess is that the aiming and mechanic are too casual for hardcore first person shooter players.  I would rather play Battlefield or Natural Selection.

With all those statements I think Hostile Territory has mountains of potential.  I didn’t join this team after leaving Premonition because it was the easy out.  I believe this game can and should be amazing.  The problems we are having however are efficiency related.  We have the same game that we had at the beginning of the semester.  The game doesn’t make sense and will require a lot of work to fix.  The teams moral is down due to repeated work and too much oversight.  As far as engineering is concerned if we don’t meet the curators goals for semantics our work is removed.  Eight engineers and only three are making contributions due to fascist oversight.  I was on-board with curating code and building a common architecture until I saw the implementation.  Curating is great until it hampers productivity.

Game Engineering 2 Assignment 05

Controls

Box: W – Positive Z; S – Negative Z; A – Negative X; D – Positive X; Q – Positive Y; Z – Negative Y; R – Rotate in Positive X; H – Rotate in Positive Y; T – Rotate in Positive Z; V – Rotate in Negative X; F – Rotate In Negative Y; G – Rotate in Negative Z

 

Camera:  I – Positive Y; K – Negative Y; J – Negative X; L – Positive X; U – Positive Z; M – Negative Z; Insert – Rotate in Positive X; Delete – Rotate in Negative X; Right Arrow – Rotate in Positive Y; Left Arrow – Rotate in Negative Y; Up Arrow – Rotate in Positive Z; Down Arrow – Rotate in Negative Z

Abstract

The project has been updated such that there are two meshes.  The first mesh is a cube of varied color.  The second mesh is a solid color plane below the cube.  The idea is the plane below the cube will show distance in Z well.  The camera is a new addition as well.  The project is now rendering in 3D including 3D movement.

Aims

The aim of the fifth assignment was to provide instruction in moving from 2D to 3D.  The move tested my architecture by being a forceful hand toward separating out data associated with meshes, materials and cameras.  The assignment also allowed me to understand debugging shaders using PIX.  I also learned about moving objects between spaces.  The space transitions were model => world => view => screen.

Implementation

I built a system that separates mesh, material and camera.  I encapsulated my shader loading code and material file loading code.  My guess is that future assignments will be moving away from loading shaders directly from file path, so the sooner I can get the shader encapsulated the better.   I am allowing definition of meshes from outside the mesh class.  I still need to be able to make graphics and actor changes from the game.  I will be working on Engine and Game separation if I find spare time.

Screen Shots

Debugging information using PIX for a Vertex Shader.  The model has been moved to world space and is now being moved into the view.  The fifth assignment required moving from Model => World => View  => Screen spaces.
Debugging information using PIX for a Vertex Shader. The model has been moved to world space and is now being moved into the view. The fifth assignment required moving from Model => World => View => Screen spaces.
The new colorful cube is at the rear of the gray plane.
The new colorful cube is at the rear of the gray plane.

Organization

I finally made separate classes for the material loader, material, mesh, camera, fragment and vertex shader.  I made adding meshes something that is done a layer above the mesh class.  I am going to continue to extend the classes so that Game can define actors with meshes or cameras.

Issues

I had a registry issue that didn’t allow me to use PIX.  I fixed the issue by modifying my registry.  I made a list of steps to fix the issue.  The steps are slightly informal and may be ambiguous, so please let me know and I will try to fix them.

1)  If you are getting an error saying something like “need to modify registry” and you say okay, but it says it can’t change your registry then your installation of DirectX and Direct3D are currently using TrustedInstaller permissions.
2)  Open regedit by pressing the start button and in the search bar typing regedit.
3)  Navigate to registry path “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Direct3D”.
4)  Right click on the thing that looks like a folder.
5)  In the resulting menu click permissions.  Permissions is the second to last option.
6)  Click on Administrators and try to give Administrator “Full Control” by checking the allow box and then Apply.  If you get an error continue to the next step.
7)  You need a bigger hammer.  Press the “Advanced” button.
8)  A menu should pop up.  Click on the owner tab.
9)  Owner is probably TrustedInstallers.  Make the owner Administrators.  Highlight Administrators and click apply.  The name should change.
10)  Hit the okay button to leave the Advanced modal Window.
11)  Now give Administrators Full Control by selecting the check box.
12)  Go back to PIX and try to allow it to change the registry again.
13) If that fails, go back to start and enter into the search bar “directx control panel”.  Find the directx control panel tool.
14)  In DirectX Control Panel select “Direct3D 9” tab.
15)  Click “Enable Shader Debugging” and hit apply.
16)  Restart DirectX Control Panel and make sure the checkbox is checked for “Enable Shader Debugging”.
17)  That’s all I have for fixing the issue.  Enjoy!

Next Steps

OBTAIN A BETTER SEPARATION BETWEEN GAME AND ENGINE (Like using caps makes it more important or something).  Continue to abstract the graphics engine.  Make primitive types for cubes, quads and triangles for faster assembly.

Time Estimate

The workload was tolerable.  Much better than last week.  The class was warned that this assignment would be telling if we like graphics or not.  I like graphics.  Also, 12 hours is about where I want to be on assignments.

Activity Time Spent
Encapsulating Graphics Classes 5 hours
Implementing 3D Graphics 3 hours
Debugging 3 hours
Write up 1 hour
Total 12 hours