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.

Post 28 - Stress? What's that?

I am delirious. Sincerely.

I am beside myself with joy and fear. We have started messing around in the Unreal 4 Engine, and it has been a nightmare of beauty navigating it.

It is such a simple visual structure, to generate blueprints for knowledge and game structure, that our producers could change and alter simple game code, without writing ANY code at all. This is all fine and dandy for them...But as for writing our own code, that is another beast.

We have separated goals for each team-member when it comes to coding. I was given the task of altering the third-person player controller, and implement code to fire projectiles. Seems simple...But things are not as they seem.

We had a lecture remove about two and a half hours from our work time. After that I was downloading the new implementation of Visual Studio 2013. While that was just finishing downloading I was asked to attend a group design meeting, which side-tracked our base game mechanics. I asked the group why we were just sitting around talking about it, and why no one has built a paper prototype and play-tested it, but talking continued. I explained my concerns and issues with the current state of the way design was going, and they agreed.

I went back to coding after this meeting and class had ended. Off to do actual full-time job work, and then off to the last class of the day. I feel as if our classes don't provide us time to work, but provide us "pretend time to work". The program has made me a believer that the actual program is about playing dress-up, but not actually purchasing clothing. It's a bizarre analogy, but that's all I can think of to describe it.
---
As for the last day of the week, I determined that lack of tutorials for a game engine release is frustrating, annoying, and exciting. It is like exploring unknown territory...But when you have a limited amount of time to build a game, you don't want to be exploring the unknown, you just need answers to simple questions so you can fix the current problems you are having.

I digress.

We discussed briefly as engineers that we may need to go back to Unity if our game is still stuck in its current state. We are going to discuss this further during the week and will make a final decision then.

Back to work!

Post 27 - Can't Sleep Games Will Eat Me

You read it in the title, and it was true.

I attended the 2014 Game Developers Conference (GDC) and it was amazing! The number of booths to visit, people to talk to and interactions with other industry groups were astounding.

I was able to attend a two day game design workshop specifically headed by Marc Leblanc. It was an intense hands-on event, involving group discussion, analysis of theme and mechanics, and critique. It was focused on the Mechanics-Design-Aesthetics (MDA) game design approach. We iterated on the base game mechanics of Sissy-Fight 3000, focusing on how the games is viewed as a system, in terms of its mechanics, dynamics, and aesthetics. We discussed what worked, and what didn't work. We discussed if it was fun, and if that fun helped meet the theme of the game. It was wonderful!

And that was just part of Day 1!!!

I'm not going to describe every piece of each day, but GDC was worth the trip. I met many people looking for jobs, internships, long-term game veterans, start-ups, and general software developers. Hell, I even met the Space-X team who builds reusable rockets, and how they are trying to go to Mars.

---

As with this trip, I have lost lots of sleep and focus. I'm tired, and beat up mentally and emotionally. It was a great trip, but everyone knows that "vacations" are a lot of work. With this being true, then "work vacations" are double, if not triple, the total amount of work.

We came back to our group discussions on the game engine to focus on for our Master Thesis Game: Hostile Territory. During this discussion everyone was very interested if we could make the character run up walls in the Unreal 4 Engine. I spent over an hour at the Unreal booth at GDC discussing with one of their head engineers, and he explained that with the three-dimensional nav-meshes, as they are currently built, it would be very difficult to do this. If we had five engineers and a few months, we might find a way to get it working.

I explained this hardship to the group, so gravity/wall walking is not the main focus right now. There was much discussion as to how the game is changing in design. Lots of "talking" occurred, but not a lot of "testing" occurred. I explained about the design workshop I attended at GDC, and if we are going to change anything, we should playtest it. This includes not just code, but paper-prototypes.

And that was the week back from GDC. More to come!