Engineering Two Assignment 2

Assignment 2 Download!

So this week, we replaced our asset-building-pipeline that used to run on C++ code and changed it over to use LUA. So what do we gain by writing it in LUA instead of just using code? If someone adds a new asset to the game, they don’t need to know how to navigate Visual Studio or know code or anything to add it into a big list of assets that need to be built. Also, LUA is neat because you don’t need to compile the code every time you make a change, which can save a HUGE amount of time if you’re working on a project that takes minutes to build.

So the first thing I did was fix a few problems that I had from last week, namely changing which assets were being built in Debug mode. Apparently I didn’t check that :/ It was a simple macro that I had fixed (and even mentioned in the previous post), but I had only made the change to Release…Whoops… Since I knew what the problem was, it didn’t take too long to fix it. I also removed the solutions from the AssetBuilder projects. I had moved them over when I imported the project, and I forgot to delete all the extra stuff, so now that’s gone.

Adding color to the triangle wasn’t too difficult either. We basically just changed the colors that we pass in to the shaders from white to whatever else. In my case, I chose orange, purple, and green – because they’re awesome. So after you pass in the colors to DirectX, it passes it through a vertex shader which determines where/what color is going to each vertex. This then gets passed to the fragment shader, which blends the colors between the vertices. It is worth noting that the assignment asked for “Your program draws a triangle with three different colors at each vertex,” which is just silly. I don’t imagine you could have three different colors per vertex. 🙂

Adding LUA into my project was a HUGE hassle. And not because importing a project is hard. It seems like 75% of my time is dealing with Visual Studio and trying to finangle it into doing what I want. Apparently, VS is a bit upset that I don’t have my SolutionMacros and DefaultLocations property pages in the EngineeringTwo\breeden_mark\EngineeringTwo\Code folder. I have it one down, in the Game folder. In the property pages, it recognizes the ones in the Game folder. However, if I don’t have those property pages in the Code folder, I can’t import any projects. If I add in the property pages, import the projects, then delete the property pages, there’s no problem…Until I restart VS. Then it says that it can’t load up the projects. I checked the difference in the two files in KDiff to see if the property pages were altered whilst importing the LUA projects, but they remained the same. So I’m unsure of how to fix this (I’m going to try and fix it in the next two days, but if anyone has any suggestions…). I eventually gave up on it so I could move forward.

After LUA was in, the pipeline swap wasn’t too bad. Filling in the code where necessary with LUA calls was pretty easy. A lua_State gets passed in to the C++ function from the lua side of things. Then you make calls to retrieve any parameters you need from the lua_State. This feels a lot like LUA, and a lot less like C++, so you kind of have to go on faith (and have a lot of error checking in place) that the LUA function gave you everything you need. Then you can manipulate that data however you please. If you need to return values to the LUA function, you need to push it back on to the lua_State, along with the type, and then on the LUA side of things, it handles it the same way you did when you received it – with a lot of faith. I was thinking about ways you could improve the interaction between the two languages. You might want to create an interface that handles the checking and everything for you. So instead of saying lua_isstring, you could create a class that holds the lua object and then you could request what you need from the wrapper. Of course, in this assignment we didn’t mess around much with LUA objects, so maybe it’d be easier to pass an object in to C++…but then you’d have to retrieve values based on their name. That might be an interest thing to do…As I’m typing this, I realize that this is probably what Lua++ did, which we used last year.

What took me the most amount of time was setting up the debugging environment. My code was having the hardest time finding the ScriptDir, which I felt was RIGHT THERE. I ended up throwing that macro around a couple places. It turns out that the AssetBuilder required the macros from the Game debugging, like where the AuthoredAssets was. It said it was missing ScriptDir, but it was actually missing a different macro… Took me a long time to figure out exactly what was going on. Bleaugh. Anyways, it’s done.

Notes: Should you use more than one SolutionMacro and DefaultLocations? I feel like unless you have one for each project, you might run in to issues if you want to just run one of them. Or if you need to just build one. Jamie said I had extra property pages, but the ones I saw were for the other projects, so I don’t feel like they are extra so much as specialized. However, I imagine the above issue – not finding ScriptDir or the like, would have not been an issue had they all shared the same pages.

Pix Writeup:
Pix4Writeup

In the Events window, you can see the functions being called to DirectX, so if you choose one that is making a draw call, information will show up in the Details page. It will then show what mesh is being drawn, how it’s being interpreted and moved about, as well as what vertices are being passed to the GPU.

Obligatory Triange Picture:
TrianglePicture

Time Spent:
Fixing problems from last time: 30 Minutes
Adding color to the triangle: 30 Minutes
Adding LUA to the project: 1.5 Hours
Swapping the Asset Building Pipeline: 2.5 Hours
WriteUp: 35 Minutes

Weeks 1-3 Projects

The first three weeks of projects class went by really quickly, and I have to say that I’m pretty impressed at the speed at which my group is progressing. We had laid out a timeline to meet the IGF deadline, and the first week was just making sure all the planning was done and the theme was decided on. We managed to pump that out by the end of the first day. By the end of the first week, we had a basic layout of two of the levels designed on paper.

The second week, we had built the levels in Unity, and started adding details. The field level of the game was having some problems, however. We had the corn on the field, and when you move through it, the corn parts like you expect it to, which is awesome. I have to say that walking through the corn fields felt really good. So what problems did the outside have? Well, we didn’t know what to DO outside. I mean walking was fun and all, but that gets boring after about 30 seconds if you don’t have a task to do…You’re kind of just trundling along. The mannequin scarecrow worked basically like it used to, but with so much open space, it was pretty easy to avoid it. So the AI for the scarecrow needs some work. We also have crows flying around. Which is SOOO cool. I have to say that Jinghui did a really cool job on it.

The third week we started playing around with new concepts to do outside. Inside is starting to look really cool as well. The layout of the house is a bit cramped, so we may need to stretch it out. We also are playing around with the idea of making it more of a “you’re going insane” horror feel, which may allow us to make a house that isn’t reasonable for the timeperiod, or even basic house layouts. By the end of the week, I decide that I like the idea of taking elements from a previous game (If Button Pressed), and applying them to the current horror game. Things like object permanence, teleportation, etc are going to be tested and we’ll see how we feel about it. We also came up with another idea: an invisible monster that parts corn as it moves through it. This is similar to Amnesia’s water monster. This might be cool to play around with. We received some feedback from some competitions that we entered and they said they liked the game, however the mechanic of looking at something and stopping it was done recently and they feel like they couldn’t put through a game that was that similar. Understandable, but that means that our scarecrow can’t be the only monster. Or the mechanic may need to be cut entirely. We are playing with different AI modes for the scarecrow to see what we like.

On Tuesday, I will attempt to get a playable version of the game and post it here for people to try. No Oculus will be required. Hopefully :p

Engineering Two Assignment 1

Assignment 1 Download

This assignment was mostly setting up the initial project. The coolest part about it was setting up the solution macros. It’s really cool to set up a macro and all the extra stuff that usually clogs up my folders gets stashed away so I don’t have to see it. It’s really nice for cleaner code. Setting up a property sheet is a great way to keep common macros (such as creating a bin, temp, intermediate, game, etc) to reuse in multiple projects.

As for the code, I decided to change Graphics into a class, and made it static (kind of like a singleton, but I haven’t actually written those, so maybe in the future I’ll convert it). That way, no matter where I am in the code, I can make sure to call the correct Graphics code and write to the correct window. I spent a lot of time moving files around due to the requirements of the assignment, and I can see why all the code is organized in a code folder. However, I wish there was an easier way to move files around after they’ve been created by Visual Studio. After you move a file, in the file properties in VS, there’s a spot for “Relative Path,” which you just need to change to match the new location. However, I spent a lot of time trying to figure that out. I’m pretty sure that recreating the solution took the bulk of my time.

When creating a Windows program, you need to use a lot of fancy Windows functions to create the window, which you pass to the Graphics code so it knows which window to draw in. I opted for my Windows to initialize everything and then pass it along to the game to pass the handle to the Graphics code. In the case of building to multiple platforms, I can see that having the game initialize everything, because then the game can decide which platform it is on and how it needs to handle it. However, if you do it the way I did, it seems like it may run into issues with multiple platforms. I would essentially need to create a new start routine for each platform and potentially duplicate a lot of code. The advantage I saw in the way I did it was that I could take care of all the Windows stuff, and then forget about it and not have to worry too much about specific windows calls after that point. (I’m not saying this is a great way to do it, just stating how I’ve deluded myself into believing it…)

I started to write a Shape class and began putting the triangle code into it, but thought we might not stick with purely triangles, and I wanted to see where we’d go before charging down a path. However, after class today, and talking about using Triangle lists, I’m not entirely sure what the best approach might be. I’ll have to sit on it for a bit.

I did receive help from an email that Swapp had sent out involving including d3dx9.lib, which is what I had forgotten. I added d3d9.lib, but not the other and had made the same mistake. It probably saved me a lot of time and I’m grateful someone had figured it out by the time I had got to it.

I also received help from Dayna’s email about debugging. I knew I had seen some stuff in the assignment about how to debug the program without access to the data folder. That pointed me in the right direction to make a quick fix.

Time taken:
Git setup – 1 Hour
Building the solution with all the extra settings – 1.5 – 2 Hours
Getting the graphics stuff set up – 1 Hour (I already had DirectX installed, so that saved a lot of time. Last time took me forever…)
Fixing a few more things – 30 Minutes
Write-up and webpage setup – 1 Hour
Fixing an error with release .exe – 1 Hour

Spring Break Programming Extravaganza

Mannequin is moving forward for now, and the only road blocks that we were running into involved the mannequins using dynamic pathfinding. Unity’s NavMesh system worked great for the prototype with prebuilt levels, however it falls short, if not impossible to use in the long run. Over spring break, my goal was to create a pathfinding algorithm that will take the place of the NavMesh system. However, this also involved creating a room generator. So the video below is two-fold. It shows off the random-room generation, as well as the pathfinding that we can now apply to the mannequins. Check out the video for an explanation on how the algorithm decides to place rooms. It also describes the basics of how the pathfinding works.

Room Generator and Pathfinding!

Also worth noting is John’s video that includes the actual gameplay, with what we already have, including the Oculus Rift and sneak/sprint mechanics! Find that here!

New Semester

We finished out Tesla’s Touch last semester pretty strong, I think if we put just a little more time into it, then the touch functionality we were driving for would be there. I recently reinstalled Windows on my computer, so I lost the program I was using to record my gameplay videos. I’m trying to find a replacement, and as soon as I do, the release version of Tesla’s Touch will be uploaded to YouTube.

The first three weeks of class have been spent coming up with ideas for a thesis game. The two we have narrowed down to and will start developing are Mannequin and Agoraphobia. Mannequin is a horror survival game where all the enemies are mannequins and only move while you are not looking at them. I’ve been told this is just like the Weeping Angels from Dr. Who, so I suppose I need to watch that. The big pull for this game is that we want to use the Oculus Rift and we want the game to adapt to how the player acts in the game. We are going to be using players’ reactions, such as head movement or reactions to sounds to adjust the gameplay and tailor it to the player. Hopefully this will make the game scarier, and a little more intimate with the player.

The other group is working on a game addressing agoraphobia, an anxiety disorder that revolves around open spaces or crowds. I haven’t looked too much into this one, and the idea sounds good, but I’m not sure how it is going to work quite yet. Well, I’ll update this once Tesla’s Touch’s release video gets uploaded.

EDIT: Release video for Tesla’s Touch now available!

Coming up on The End

The semester is almost over and Tesla’s Touch is almost done. We have 16 levels done currently, along with music and sound effects. The 4 puzzles I had from the previous video have now been expanded. We wanted to guide players through, and make the puzzles really easy initially. This allows the players to figure out the puzzles on their own and they feel clever. It also allows us to put a lot of levels in really quickly without exhausting our ideas. The motors work now, and rotate and slip and slide, but they still need a little work. I think that we can get to 20 levels easily by release (Thursday), and have it polished a lot more before then. Oh! We also have particle effects for shorts, which are pretty cool.

Want to check out the latest video? Go here!

First look at Tesla’s Touch!

Ok, so I made up a video of our first look at Tesla’s Touch, finally with some art work added in. I was tired of seeing my programmer place-holder cubes. I’m excited to see this Tesla-Punk theme in full swing. The first look can be found here.

Talking about programming stuffs: I ran into an issue for a minute because I delete and redraw the lightning every frame. It was really lagging at first, so I tried to only update the lightning every third frame, then every sixth, then every tenth. Needless to say, it looked terrible, but I was trying to figure out what was bogging my code down and running so slowly. Then I realized that I kept hitting an error every tenth lightning chain created (I was trying to create a “Lightning0” object, but it should have been “Lightning1” through “Lightning10”). So after removing that error, the code flows really smoothly, no framerate issues and no terrible looking lightning. I was initially worried that drawing every frame would still cause performance issues, but since we don’t have any enemy AI or anything else to worry about, we can use the resources. We’ll see how a table handles it, so we may need to adjust in the future. Another issue with lightning redrawing every frame- may cause seizures? I don’t know if that’s likely, but might be something we look into.

We have the first 4 levels made, and the rest should be pretty easy now that the hard programming parts are taken care of. The rest of the levels will be drag-and-droppable, with the exception of motor objects, which need to be individually coded to each level, but are ultimately the same every time. We already have the domain for Tesla’s Touch, as well as the name reserved in the Windows 8 store, so our producers have been on top of the ball getting that all sorted out(I really didn’t want to mess with that stuff).

Final note: updated this blog so it isn’t quite so hard to read. Hopefully this page isn’t quite so horrible on smaller resolutions.

ZAP!

We got new teams again this week, and I have not worked with anyone on my team yet. I’m excited, because everyone seems like very talented individuals. We had to come up with an idea for a game that is planned to be published on the Windows 8 store at the end of the semester (3 weeks away). I came up with the initial concept of our game, which uses the touch screen capabilities in Windows tablets. A lot of games don’t use multiple touch, which is really a waste of the cool technology. If you can only touch one thing at a time, why not use a mouse? Our idea is an electricity based game that also has a “finger Twister” feel about it. On the left side of the screen, there’s an electrical source (like a lightning rod or something), and the electricity will jump to your fingers when you press down on a location near the source. You can then press down more fingers to jump the charge further. Ultimately, it’s a puzzle game where you need to get the electricity to the other side of the screen to power a device without grounding it out. I’m super excited about this.

One thing worth noting is our use of Unity. I would have rather used C++ and DirectX, but given the time restraint, I think that we’d be using most of our time finagling the language, rather than creating a prototype. Unity is really good for creating a quick and dirty game, despite losing some control over what is happening. The other thing happening on the project is that we HAVE to develop on a Windows 8 device using Visual Studio 2013 to be able to release to the Windows store. At my lab computer, I have a virtual box ready and set up, but at home, I don’t have access to that, so I’ll be spending much more time in the lab than in previous projects. Bleaugh. Despite this, I think we can do it! 😀

Post Mortem for If(Button_Pressed)

You can see the final run through of our game here.

We showed off our game on Thursday, and had Tony narrate my journey as a button presser as I demoed the recursive rooms, as well as the light puzzles that are now implemented.  I’m really happy with our group, and we made a really awesome game.  I think this is the best game I’ve made in the class so far.  It was really different from the other games that I have made, which are ultimately, endless AI games.  Both the Fudge Shop and the Space Invaders were just procedural skill games.  Button was a game that had one play through, and that’s why it took so much time.  Instead of making an algorithm for how space invaders worked and interacted with the world, we needed to sculpt levels that players could truly enjoy, even if it was only one time through.

Thoughts on Unity: it makes for a great tool to make fast prototypes,  but I found that I couldn’t get certain things to work without hacking it.  I don’t know the specifics of what happens under the hood to be able to manipulate it quite the way I want to, but it certainly makes model/animation/sound really easy to do.  I also didn’t like the lack of precision on certain things.  I learned how to work around those issues later, but I felt like a few of the things I did were particularly hacky.

The presentation went really well, the professors really liked it, and even went so far as to call it “gold.”  They encouraged us to pursue the project either as a thesis game or just furthering the game on our own time.  I’m really proud of this game and of our team.  I think we did a lot of cool things, and I look forward to working with them again in the future.  Once again, if you’ve missed out on my new YouTube channel, you can find it here.

YouTube Portfolio LIVE!

I added videos to my YouTube channel to allow potential employers to check out my games live, rather than reading my excerpts from the blog.  It can be found here or up in the header at any point under my name.  I have the three prototyping games there, as well as a personal project I did about a year ago.  Super excited to show this off, I might be showing more and more videos in my blog now that this is established.