Thursday, January 31, 2013

Graphics Write-Up #3

This week was considerably easier than the past weeks.  There were a few stumbling points however.  This was the largest one:


{ 0, 0, D3DDECLTYPE_FLOAT3, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_POSITION, 0 },
{ 0, 12, D3DDECLTYPE_FLOAT3, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_NORMAL, 0 },
{ 0, 24, D3DDECLTYPE_FLOAT2, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_TEXCOORD, 0 },
{ 0, 32, D3DDECLTYPE_D3DCOLOR, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_COLOR, 0 },


In the end, COLOR had to be moved to the end since I wasn't sure how large it was and thus how much to offset the next data by.  (In retrospect, calling sizeof on the type would have worked too).  The light itself was working after implementing it like the camera, although it felt like it wasn't actually moving.  Changing the increments from 1 to 10 helped improve that though, which makes sense since the light needs to change a lot for it to have a noticeable impact.

The only other stumbling block was setting up the UVs.  I initially did it with 0,0 at the bottom left and it looked horrible and you couldn't tell what the texture was supposed to be.  I messed around with the UVs for a while trying to figure out what was going on, but then Shrly explained that in DirectX the origin is actually the upper left.

Another slightly odd issue was attempting to call a variable in the FragmentShader texture.  For some reason that just doesn't work.

I love that the light isn't actually lighting things up, but instead darkening things.  It's like an anti-light!

Camera is still on WASD and the Cube is on the arrow keys.
Light Controls:
I - Up
J - Left
K - Down
L - Right



P.S.  In case it isn't obvious from our almost identical write-ups, Jason and I worked together on this assignment (as with previous ones).

Wednesday, January 30, 2013

Vinyl v2.0

Yesterday we spent the majority of class time going over exactly what we want Vinyl to feel like.  We know that we want a heavy emphasis on flow, with the ultimate objective being that the player loses track of time as they experience their music through our game.  A big source of inspiration for us was Super Hexagon since it does an excellent job of doing this.

As a result we've changed our gameplay slightly, mostly focusing on a single gameplay experience as opposed to previously when we were planning on having vinyl, strings, drums, and brass sections.  Now the game is entirely based in the groove of a record we're going to represent with a half-pipe.  The player will control an avatar by moving them left and right (for dodging purposes) in addition to controlling their speed (seeking to maintain an optimal speed so that the song plays neither too fast nor too slow).

If the character is running down the bottom of the pipe then the sound is balanced and will come out of both speakers.  On the other hand, if the player moves up the left wall the sound will shift to the left speaker more and more and visa versa.  While running down the groove the player will have to dodge static pockets that in addition to reducing score, will randomly change the character's speed and bump them to the left or right.

Something we've thought of for the future is to include a feature where if you go too far to the left or right you end up falling into the next groove over causing the song to skip forwards or back.

Now that we have a really solid idea of exactly what we want we're able to get a prototype up and running in Unity which we expect to have done by the end of tomorrow ideally.

Sunday, January 27, 2013

Groups Decided

This week the groups were decided and set in stone.  Cellblock, Fus Fus and Vinyl are still around as expected, but there's also a 4th group now that's combining a bunch of people's ideas into a game.  Vinyl has 5 of us working on it, myself, Jason, Sherly, Mike, and Brianne.

Tuesday we planned out a rough idea of how we want the next three weeks to go and came up with a basic plan of what we want to do engineering wise.  We're going to be talking with Zodiac since they have a rail system as well, which is what we're after.

Since then, and especially on Thursday, I spent a lot of time playing various other music games to see how they did things.  I got a bit of inspiration and ideas, but most of them just have music playing and the game doesn't really use it.  There's an iPhone game, Synesthetic, that's the closest thing to what we're going for.  We also listened to a bunch of various types of music as a group to try and decide what genre we're going to use for the prototype.  Roger recommended that we not use a copyrighted song, even for the prototype, which we're going to go with.

Thursday, January 24, 2013

Graphics Write-up #2



Wow!  That was certainly a crazy assignment.  Part of the issue was that Joe had given us an absolutely massive assignment that was due Tuesday so I didn't actually start working on this one until Wednesday.  Coding wise, we hadn't covered how to write the viewToProjected transform so that was the most challenging aspect I think.  In general, I understood all the concepts since we covered them very well in class, but putting down those concepts into working code was more challenging than I anticipated.  If we hadn't had the video of the class to go over your code multiple times I doubt I would have finished this assignment in time.

Another more challenging section of the code was getting the vertexBuffer and the indexBuffer to communicate, but Jason K and I thought we'd figured it out and then you confirmed it in an e-mail so that was great.  Additionally getting the camera created was very easy, but actually getting it to work as a camera wasn't as obvious.  Once I figured out it was just how you set up the transform everything made a lot more sense.

Oh, I also got the triangle count and vertex count into the file so that now no values are hard coded into the code, which I'm really happy about.  A big future change to make will be to get everything out of the same file and into separate files.  I wanted to do that this assignment, but there just wasn't enough time.

Camera Controls:
W: Up
A: Left
S: Down
D: Right

Cube Controls:
Arrow Keys



Link to code:  http://eng.utah.edu/~jthummel/graphics/ThummelGraphicsAssignment2.zip

Thursday, January 17, 2013

Game Pitching, the Results!

So after the pitching on Tuesday, today we got feedback from the professors on each pitch, which was really nice to hear.  In my case, Roger even went as far to say that my modifications to the rogue-like formula were "genius", which was pretty awesome.  They did feel that the High Fantasy aspects of the game were over used and didn't really bring anything to the game which I agreed with.  I've always used it for the example since everyone will understand it, but I feel like the game could work with almost any setting since it's so flexible.  We then got the rather shocking announcement that they weren't going to pick which games we'd as we'd expect them to.  Instead, it was up to all of us to figure out which game we were going to work on with the one restriction that teams had to be more than 5 people, but less than 12.

As of this point, the three games that have enough people on them are Cellblock, Vinyl, and Fus-Fus with around 9 people who still aren't on a team that's large enough.  At this point it's unclear if those 9 will come onto one of the three current teams, or if another game will be added to the group.  Sadly, my game didn't draw enough attention despite several people saying they were interested in it.  I'm really not that upset about it since I feel that so many of the games had a lot of promise and that any of them could have resulted in a game I'd be happy to work on.

I'm on the Vinyl team since I do have a music background and I also feel like it has the potential to be a really awesome game.  I'm a little unsure of how we're going to get the ball rolling on this, but I think the consensus between the current engineers on the team is to work on the string grinding first.  I'm really excited for the brass instrument section with the player flying through the tubes, it's going to be a lot of fun both to play and program I think.

Graphics Write Up 1

File Format:
For my file format I went with something I'd used in the past when working on my 3D reconstruction program and also just because it makes a lot of sense.  It's simply an x, y pair per line grouped into lines of three for a triangle with a blank line to separate the triangles visually.  One change I would like to make to the format is including the number of triangles to draw in the first line since right now I just hard-coded that value, which is really bad practice.

Shader Modifications:
Since some of the default shader manipulation used sin and cos to do interesting things I went on to try and see what tan would do and was not disappointed.  So now both my coloring and position are using tangent calculations, which I feel looks really cool especially since the movement clearly distinguishes the two triangles.

Additional Stuff:
Figuring out the correct order to draw the triangles in was certainly very interesting.  I'd initially gone counter-clockwise, which didn't work, and then changing to clockwise ended up working perfectly.  However, one of the guys I was working with had both of his triangles clockwise as well and they weren't working, which didn't seem to make sense.  In the end we decided it was because I was beginning both of my triangles in the same location, the upper left and corner of the rectangle.  We're not entirely sure if that was it in the end, but it does work.

Another thing that was confusing, but easy to fix, was only drawing a single triangle.  After going through the code again I found the logic where it decided how many triangles to draw and changed it to 2.  As I said above, this clearly isn't the best solution to this and I'd prefer to be reading in the first line of the file to figure out how many triangles need to be drawn.

The last thing that took a bit of work was setting up the MeshBuilder tool.  It probably would have been easiest to completely copy the TextureBuilder tool and then just rename everything, but instead I created a new project and then copied each file over individually.  As a result my project properties weren't correctly set up and so I went through all of those and tried to set them up.  In the end I missed one, which messed up some of the Windows specific code, but a quick Google search fixed that.  I'm also glad I went through this way since it really helped to learn how all the dependencies worked and where everything was being loaded in from.

Pix Screenshots:



Code to this first assignment can be found here: http://www.eng.utah.edu/~jthummel/graphics/

Thursday, January 10, 2013

Game Pitching

So our first assignment this semester is pitching a game idea to the class as a possible thesis project.  I'm going to be pitching Dungeon Descent since I've been designing it for the last two years.  When I pitched it in the Capstone class it was well received and moved on to the prototyping phase, but didn't make it past that. This time, hopefully I've refined it enough that it will end up being selected as a thesis game.

The core of the game remains the same:  A rogue-like RPG where the player controls a party of four adventurers through a dungeon, but eventually is forced to return to the surface to avoid dying.  However, doing so resets the party's experience and items so that the next descent is a fresh start.  The one exception to this rule are special artifact items that will last forever once discovered and are the primary means of being able to advance deeper into the dungeon.  Levels will always be randomly generated to ensure that no two playthroughs ever feel the same since the game will force replayabilty.

Previously I'd pitched the game with the concept of an item combiner which would take all the items you'd found in a run and give you a chance to get an artifact item so the player would be rewarded even if they hadn't found an artifact.  I felt this was a band-aid fix to the issue though and wasn't a huge fan of it so I've modified it.  Now the player will get "Descent Experience" each time they go through the dungeon earning more the farther they manage to make it.  This will contribute to your "Descent Level" which will provide small benefits to each run.  For example, at Descent Level 1 the party could start with a health potion.  Hopefully this system will be enough of a reward so that on runs where the player doesn't find an artifact, they don't feel like they'd just wasted their time.

The unique aspect of the RPG part of the game is still the spell system, although  it's changed a bit as well.  Spells are still just a single item that when equipped to a character provides a unique spell.  For instance, the Fire scroll allows the Mage to cast Fireball and the Fighter to cast Protect.  Spells can also be combined, although now only the Mage and Cleric can do this (since they're the more magic oriented classes).  Combination spells can be any combination of two scrolls (or even 3 in the Mage's case at high level) such as Fire + Fire which would result in an AoE version of the normal Fire spell or Fire + Earth which could be Meteor.  Combination spells do more damage, and have special attributes, but also cost more mana to cast.  Spell slots would be unlocked at certain levels, for example the Mage might get a single slot at level 5, and then a double slot at level 10.