Engineering II - Assignment 4 - Add Color Modifier and Other Constants

Assignment 4 - Add Color Modifier and Other Constants

ZIP Link

Assignment4.zip

Write-Up

The basics of this assignment were to alter the vertex shader to alter the color value across the entire object, in this case a rectangle. The default values are a gray-scale rectangle, with different gray values at each vertex.

Then we were to check for user input via the keyboard, and move the rectangle around the screen.

Finally, we were to include a generic builder (GenericBuilder) builder project, which will simplify future projects for building different assets.

Technical Write-Up

So, I was able to edit the current code and get it to draw a gray-scale rectangle correctly. The values for doing this involve editing the Material file including a section for constants. I included mine as shown below:

 I initially was going to use the g_colorModifier in a table of constants. I had trouble trying to push and pop values from the table when reading it using lua functions. I had to comment it out to get it to work. I will work on this for future iterations, as I did not provide myself with enough time to complete this assignment.

The g_colorModifier is table of values that holds an amount for the amount of red, green, and blue to be used for the pixels on the gray-scale triangle. This color modifier that is being checked for allows multiple materials to be saved with different color values. This will modify the color for the vertexShader of the item with that material being included on it. Multiple objects/entities could contain different materials, and be altered depending on their vertex shader, fragment shader, and now by constant values such as a color modifier.

Here are a couple of images showing the different colors on the rectangle.

The second step in this process was to include code that would check for user input, and update the position of the rectangle object. I started the project using the material to hold the position and velocity of the object, but this was incorrect according to our assignment. We were not to hold the position values for the object in the material. The material shouldn't worry about it's position in the world.

I did not complete this step, as I did not provide myself with enough time. I will complete this in future iterations, and here is how I will do it. I will create an Entity object which stores the position and velocity values. This entity will store a material, containing all of the information it needs to draw itself. This will include the shader paths and constants needed. The Entity will also hold a value for it's "mesh" which holds all of locations of vertices to be drawn for itself.

There will be timer and input classes to detect the player inputs, and move appropriate rates with respect to the timer. It will be checked on the Game project's update call altering the Entity's position. With this position being altered, you will have to add this offset to the vertex values, causing the object's vertices to be altered when they are drawn to the screen.

The third item we were to complete was adding in a GenericBuilder. I did not provide myself enough time to complete this section. From what I understand, this section will allow us to implement new projects for new assets quicker, with less hassle. It will allow you to copy the new asset type from the source to the target assets location. The templated generic class is used to be called in a virtual 'Build' function, to be re-written for that new builder class.

Realized Learning Moments

I didn't realize I would be stuck in the section looking for the material constants for the vertex shader. The example was well explained on the site, but I did not understand where these elements were being used in prior code.

I did not provide myself enough time to finish this assignment. I need to prepare more time for this and the future assignments.

Time Used

Reading: 2 hours
Write-Up: 0.5 hour
Technical Write-Up: 0.5 hour
Coding: 2  hours

Post 33 - Apparently There Are Concerns

Our group had the professors review our game content, try out our new build and provide feedback.

The feedback was similar to prior feedback. "Where's the fun?" "Does the player make any interesting choices while playing?" "The controls don't make me want to play it."

So, we are working again.

I don't think there is much more to add. We have scheduled meetings on Fridays, and about half to three-quarter of the total engineers show up.

We worked on a new character controller, weapon switching inputs, and character model animations.

The game feels like it is coming together better, but it doesn't feel fun yet. I would like to work with our lead game designer on expanding our ideas for the game, and finding the fun in it.

He did bring up the good point that we don't have enough of a game to really decide what fun is there. I think we will continue to spin our wheels until enough of the base game is done to try more, and then experiment.

We are still prototyping a game that is due in three to four weeks. We should have been done prototyping last Spring.

We have received comments that we need to create a working environment that is infectious, and has other people want to be completing materials for the game. While I think this is a good idea, I don't think it is a feasible one. I don't think the majority of the people on our team want to work on it. That's what it feels like with tasks taking multiple weeks to complete, and no one taking on new tasks.

My rant is done for this week.

Engineering II - Post 3 - Draw Colorful Rectangle - Use LUA Tables and Materials

Assignment 3 - Draw Colorful Rectangle - Use LUA Tables and Materials

ZIP Link

Assignment3.zip

Write-Up

This assignment was labeled as "draw colorful rectangle on a black background." I am kidding a bit here, as there is more involvement than that.

We determined it takes two triangles to create a rectangle, so we used two triangles to create a rectangle, requiring us a to alter our code to include that for our triangle list and such.

We are now also going to use a Material file to load our vertex and fragment shaders. This will be explained in more detail in the Technical Write-Up.

This will also require using LUA tables to access our shader information. More of that described below.

Technical Write-Up

So, I was able to edit the current code and get it to draw a rectangle correctly.

The rectangle above is represented by four vertices which are being stored as four points. These points are shown in the image below. Each value, except (0,0), is being represented as a dot for its color as well.

The points are creating locations for the rectangle to be drawn.

The PIX software image below shows the points being drawn above.

It lists under the Events tab in the DrawIndexedPrimitive, that it is using triangles, using four vertices, and drawing two primitives (triangles). The Mesh tab and PreVS tab shows A view of what the triangle looks like, and lists the position of each vertex used.

 The rendering process requires the index of vertices, and these values are passed to the vertex and fragment shaders. These shaders are used via  material file, ".LUA", which is shown below. The ".MAT" was causing problems when I initially tried it. I may change it back for later builds.

The file format is set to be human readable, and has many comments to describe each section. It creates a Lua table which stores the vertex and fragment shaders paths. These are then used to create the material used for rendering via graphics code.

Please note, my Lua table uses specific names to find the vertex shader and fragment shader. If a new file is used, you may have define the variables being searched for as "vertexShader" and "fragmentShader".

Realized Learning Moments

When testing the project "UsingTables_inC"it wouldn't run properly. It took a long time for me to alternate the Debugging code to run out of "GameDir" not "ProjectDir". That fixed a few hours of feeling stupid, and let me review the actual code and follow it in Debug mode.

I was very confused by the location/access of this material file. It had to exist in the Authored Assets Directory, but be transferred to the Built Assets Directory. This would allow them to be accessible by the executable file. This would be included with the shader files. Trying to wrap my head around this concept didn't initially make sense.

The correct include method for both the LuaLib and it's .HPP file were difficult. Google searches helped fix the issue, for a library to use another library.

As far as the code that had to be edited for accessing the Lua Table of shader information, I used the accessing string format example, and it had a weird scoping issue. I had to place brackets around the function call, which fixed it. I will be looking into changing this back as well.

Time Used

Reading: 4 hours
Write-Up: 1 hour
Technical Write-Up: 2 hour
Coding: 5  hours (Ran into errors while testing example code - I included this as "Coding")

Post 32 - Closer the Deadline Comes

We had some issues with the team communicating with one another. I'm not sure that is going to change, so we are changing how we handle working together in class.

We are going to meet every Friday out of class for the engineers to work with each other.

In class, the professors will come play our game, give suggestions, and ask who is working on what piece. If their task isn't completed by the next class period, it will be cut. Another person can work on the task if it needs to be in he game, otherwise it is just going to be removed.

I think this will help increase communication or let people handle their grade on their own time.

I have a personal attachment to the game failing. I think none of us want it to fail, but I don't want it to fail, as I feel that's a sign of the team failing. I spoke with the professors and they explained that this is something I am just going to have to get used to.

I know that we want to work fast and simple to fail quickly, in that we want to find the best/fun thing quickly. I just didn't expect it that the overall product could be a failure. I feel if it is, that's a sign of the team failing. This is the part I'm struggling with.

So, all we will be doing now is getting the current iteration polished for the IGF submission. It will have great looking models, lighting, particle effects, etc. If we have time, we can work on iterating gameplay and making it more fun.

Engineering II - Post 2 - Draw Colorful Triangle - Add LUA Script - Add Altered Build Assets

Assignment 2 - Draw Colorful Triangle - Add LUA Script - Add Altered Build Assets

ZIP Link

Assignment2.zip

Write-Up

This assignment was labeled as "draw colorful triangle on a black background." And a little bit more. We were to also utilize a LUA script with our content for building assets, rather than just using function calls in that code.

We only had to alter the triangle vertices and have color values interpolate between the positions. The triangle is made of three vertices and if a given color value is used at a vertex, it will interpolate between the colors between the vertices.

After this we were required to use a given LUA script to run all of the asset building process.

Technical Write-Up

So, I was able to edit the triangle and get it to draw correctly.

After the triangle was confirmed working I used the PIX program to look into function calls while rendering. PIX captures the function calls during one frame of rendering.

In the Events tab, the highlighted function call is called "DrawPrimitive" and takes in the parameter of a "TriangleList". The list contains the number of vertices that are stored for each triangle. If two triangles were drawn, then you would be storing six vertices in the TriangleList. The method is specifically being used to draw a triangle as the primitive object.

In the PrevS tab of the Details window, it shows the vertices, the positions, and the color values stored for each. This allows you to confirm that your code is being drawn and distributed correctly.

The Mesh tab also showed the viewport for the image.

After his rendering occurred, we needed to review the existing code in the new AssetBuilder project and confirm missing sections that needed to use the given LUA script (BuildAssets.lua). These calls had to be correct for both exiting functions properly, and making sure that it found the correct source path from the given LUA state.

Realized Learning Moments

I found an incorrect hard-coded path for my Engine code in additional dependencies. I changed it to "..\Tools\Engine\" and it was then confirmed working on any computer looking for this path.

The PIX image was interesting to run, and I didn't realize that this was automatically included with DirectX.

I had initially used the incorrect LUA files as sources for code, and had to redistribute the correct files. It was completely me being blind to which file I was attempting to use.

I felt that the "DoesFileExist" function contained the entire calls needed in the missing code sections to call the correct LUA functions from BuildAssets.lua file.

I feel that I could have learned more with a discussion on how these are called in the lecture, but we focused a lot on the triangle, vertices, etc., even more.

Time Used

Reading: 7 hours
Write-Up: 1 hour
Technical Write-Up: 1 hour
Coding: 3  hours

Post 31 - Lateral Movement can be Dangerous

Design may have taken a lateral step. We are currently dealing with suggestions made by the faculty while playing our game.

We received information suggesting to have us try possible new mechanics, that will make it different. We were also told that the game doesn't provide any progression, meaning that you never know if you are winning or losing.

This lead to a long discussion suggesting different UI elements to inform the players of the current state of territory control.

We had a brief discussion about how difficult it would be to build AI for the minion characters, and this is currently not going to be changed. The minions have always represented AI, and that is what they will be for our IGF build.

I think my team is capable of creating a game that is fun to play. I'm not sure currently that the game is going to feel significantly different than other games, or even that it really has to be different.

I think we need to redesign and start fresh, or accept where we are at and just build.

Who knows what next week will bring. We'll see soon.

I have managed to get a schedule set up for the Engineering tasks, and we are trying to clear out all tasks we need to complete.

Now, we are going to have to play catch-up to finish tasks that needed to be finished this past week, but are currently working in the build. My next task is to update the XBox 360 gamepad inputs and make sure that everything is mapped correctly to commands that can be called and we don't have to hard-code values. We never should have to.

Here we go.

Engineering II - Post 1 - Visual Studio Setup - Draw Triangle

Assignment 1 - Setup/Triangle

ZIP Link

Assignment1.zip

Write-Up

This assignment was labeled as "Setup the project, and have it draw a white triangle on a black background." This statement was true, but I bet you didn't notice the subtlety there. I didn't. The key words not recognize as significant were "Setup the project...". These three words took more work and effort than I had anticipated.

Confirming that you have outputs, command lines, correct values, property sheets ordered correctly, and then reviewing that you were correct in order took about 4 hours. This included reading and re-reading documentation. I learned quite a lot from this task.

I also had a technical issue, slightly unrelated to the assignment. I wasn't initially included on the email list and wasn't receiving the questions that others were having. This issue has now been fixed.

Technical Write-Up

 After the initial set-up of all of the projects, we were to re-architect the graphics section of the code, which may require some re-architecture the code that generated windows. I realized after reviewing the graphics code that I had very little understanding of what was going on here.

I reviewed projects in the past that used a simple three-dimensional renderer, and how it was set up with respect to game code. The renderer existed inside of the engine that handled physics, collision, etc. I decided to separate the graphics and windows code into an alternate static library called 'Engine'. Once this was separated, I was able to freely call the static functions within graphics and windows.

For the future, I will be isolating the graphics section of the code further, because it currently relies on calling two functions within the graphics code, and if possible I don't want it to rely on it at all.

Realized Learning Moments

Having a .PDB and .ILK file is okay in your $(BinDir). I would have realized this sooner if the mailing list was available sooner. I have now learned that this can be removed from the build by altering the properties in Linker>Debugging>General>EnableIncremental>Linking>"No", and also the GenerateDebugInfo>"No". If you do remove the incremental linking, you can have warnings indicated through EDITANDCONTINUE, which is a build property allowing you to alter code while debugging, and still have it run. I may be removing this later in the semester.

Using DirectX can also be a hassle. If I didn't include the D3DX9.lib, it wouldn't recognize the d3dx9shader.h, while I thought it would have access by including only the D3D9.lib.

Finally, using Git caused one issue near the end of this assignment. That issue was having it not recognize the SSH Public Key. I am new to Git, and finding the Public Key, as well as the SHA key caused some some time-issues.

Time Used

Reading: 4 hours
Write-Up: 1 hour
Technical Write-Up: 1 hour
Coding: 1 hour

Post 30 - Next Step...s

We have stepped forward greatly...And realized how many more steps we have to take.

Primarily, the key information we realized was hat the Game Designer (Rody) had a different view of the game, as did the rest of the team.

We spent a good portion of time focusing on the character controller, especially the character movement, and camera movement. This is more complicated than it sounds, and I won't go into details here.

As with confirming everyone had tasks to complete and work on for the weekend, we had individual meetings with the professors (Jose and Ryan) about individual tasks.

I haven't written any code for the class, and it feels odd. I know that I have to help manage team members and confirm tasks are getting done, but the lead producer should be able to do this without me.

So, I have been working strongly with Ron to confirm that code is committed and working together. It is going more smoothly than the prior week.

As for current tasks, I am focusing on making sure ALL of the engineers understand Rody's vision.

That's vague, but we are running low on time and need to have communication at our top notch.

Now to engineering!

Post 29 - All that you can be!

YES!

The semester is back on and I have had a wonderful time with an internship at Rockwell Collins over this Summer. I will now continue the internship during the Fall semester, while continuing engineering courses and working on our team's thesis project.

This blog will be changing slightly.

I will break down some of the classes I am currently taking, and what I am working on in those courses, so there may be multiple posts each week with a different focus in each.

This post will be focusing on the current thesis project and what state the game is in.

The game: HOSTILE TERRITORY

The initial pitch involved a typical versus shooter match, one versus one, with the environment in slightly chaotic state; shifting and changing while they play.

The team had three engineers working on code over the summer. This included myself, Ron Romero, and Saumya Mukul. We found that Unreal 4's engine code was unfriendly, and that trying to commit this much code wasn't working between the three of us. We determined that the structure isn't prepared enough for our team to build everything together, and as a team we officially decided to focus on Unity, rather than Unreal Engine 4.

We rebuilt the game in two days, and it is pretty much back up to speed. We are going to focus on a new build due each week, with the possibility of two builds being completed each week. This will give us a more testing time and let us finish the 'fun' in the game faster.

I am currently acting Lead Engineer, speaking with each engineer, confirming their tasks and what could be limiting them.

Ron Romero is compiling the code together, and explaining to me any issues he is running into. We have pulled a few engineers together while working on the code, because some of it was unfriendly, or unusable. The code wasn't isolated to it's own code, and needed to be.

Currently this week, we have broken down the tasks to each member. I'm not going to post the tasks here, as I don't believe this is needed.

The current build is:

1 vs 1
Split Screen
XBOX 360 Gamepad Controls
Each Player will fire their gun at the rotating environment in a given time limit, and whomever has the most territory in that time limit wins!

These are our current requirements by Thursday. The character controls are the most important focus for us, and we have a dedicated team working on these to be perfect, as well as Networking for our future builds.

We had game designer Andrew Witts come review our game and give suggestions. This helped us create a framework to fix, and that is what we are working on. Andrew was a great help to us finding some issues we had, and we greatly appreciate his help!

Keep an eye out for it! More updates to come.