Wandering Steering Behavior and Track Generation

If you've been following the development of my thesis project at all, you'll know that Vinyl generates its levels from the music you load into it.  Therefore all the bumps match the waveform of the song itself.  Aside from that, we just had the whole thing spiral inward to represent being in the groove of a vinyl record.

It turns out however, that constantly turning left is boring, so we decided to make the path turn randomly in any direction.

To tackle making a path that seems to wander I started with a steering behavior shown to me in an engineering class.  Upon trying a few times to implement this I ran into a few problems.  The main one being that the track could potentially wander back onto itself.  That could be remedied with a few safety checks, but I wanted more control over certain aspects of the tracks generation.

What we ended up doing was creating a "player" struct that just consisted on a position vector and a rotation and moved it forward in space one unit at a time.  Each step would rotate the vector by its rotation and add it to the previous position.  After it was complete, we had a spline of data representing the track and adjusted it's y values according to the waveform of the song.  From there we could use the same mesh generation code we were using to create the track when it was a spiral.

To further refine this process, we would randomly pick a direction to rotate in and decide how sharp of a turn to make.  After going far enough in a certain direction I'd make sure to prevent the track from looping onto itself.  With a few more checks and random elements thrown in, we were able to create much more fun and compelling tracks all procedurally generated.

Check 'em out in our Let's Play!

Vinyl at the EAE Open House

The EAE program had an open house this week to show off all the student projects we've been working on for the last year.  We typically get lots of friends and family, local industry professionals and faculty to come check out everything.  Since we were the second year grad students, we got to set up our projects in a much bigger area.  As it turns out, bright flashy colors and music on an 80 inch TV draws attention, so we were able to get tons of feed back.  We also set up a bunch of computers with feedback forms on the alternate monitors and got almost unanimously positive feedback from that.

We still get the occasional complaint that we mess up the music when we're trying to enhance it, or that the game favors the right side too much.  Both are valid, but I'm unsure if we'll be able to do anything about them if we want to keep any semblance of our original premise alive.  Part of me wants to try making the track either straight or curvy in random directions, but we shall see next semester.

The game is basically in a state we are currently very happy with and polish and bug fixing will be our main focus for here on out.

Aside from Vinyl, there were tons of other fantastic student projects at the show.  The undergrad PSP games are using the touch screen in unique ways, and the research teams have made several games on topics ranging from fitness to teaching social skills to autistic teens.  The first year grad students all had their rapid prototypes on display, and will be publishing them to the Windows app store before the semester is out.

All in all, I'd say it was a pretty successful evening.  And the cake was delicious.

Vinyl: Score Design

After much deliberation, we finally decided that Vinyl needed some kind of scoring system.  We resisted this idea for a long time, because we didn't want to enforce a "right way" to play our game and scoring systems naturally imply a proper method of play.  However, without one we kept running into the problem that playtesters didn't understand what to do in our game.

The biggest issue we had with a scoring system is the game has always been about audio manipulation, and if people want to make their songs sound weird and silly, we didn't want to stop them.  We had all but abandoned that notion, until JJ and our professor came up with an idea of "genre changers" which allow the player to have some more agency over the type of manipulation that is happening.  This system has no impact on the score, so the player is still free too play with the sound while still trying for a high score.

We tried a few scoring solutions, all revolving around the idea of a streak.  We initially tried basing everything on that one number, but it got confusing when your streak would suddenly go up 15% for hitting a filter since your streak no longer meant how long you've gone without hitting an obstacle.

We have since decoupled the score and the streak, so the streak adds to your score, and other things like filters also add to your score, but the streak is always how many obstacles you've passed since the last one you hit.  It works well, but we've struggled with the growth curves, since certain actions are more beneficial to you once you already have a big score since they are percentage based, and others are just linear.  Since all of this math is hidden from the player, it's probably not a good idea to make boosting worth tons of points near the end of the song, but have it be essentially worthless at the beginning.

I ended up coding several options for growth curves and score bases into the system so that we can play test quickly with different combinations of options that can be quickly tweaked from within the Unity editor.  I think the system is well designed, we just need to find the right balance to make it feel right.

Vinyl : IGF Edition!

We have officially submitted our game to the IGF Student Competition!  Actually, we officially did on Halloween... and then a couple more times after that, but I'm bad about updating my blog.  The key things of note since submitting was our post mortem required of us by the professors and general team grooviness.

I've said for awhile now that the engineering team generally works fine, we get all our tasks done and are typically all on the same page.  The same can't really be said for the team as a whole, and we've been making some pretty serious strides to remedy that.  The post mortem focused generally on us having entirely too many meetings where nothing useful is accomplished and general communication and team morale problems.

I think my favorite remedy to come out of the post mortem is our new policy of putting everyone's contributions to the game in regardless of quality, and not replacing them until we have something better.  Before we would either not put something in the whole team didn't like it, or we would take it out fairly quickly.  This discouraged the artists and left the game looking the same (programmery) for so long that actually refining an art style became incredibly difficult.

Since then, the art team have collaborated with the programs other thesis project art guys to come up with an art style we can seriously push forward with.  This probably should have been done six months ago, since we will ideally content lock in less than a month, but its refreshing to see the rest of the team have the enthusiasm that we all had when we started again.  I think with a bit of minor crunching, and maybe leaking a few weeks passed our deadline we'll have a much better looking game.

The engineers are almost entirely working on simple implementation changes, UI stuff and minor design tweaks, so while we have our hands pretty full, it's not with the kind of things that are difficult.

Aside from that, we've also become a bit more agreeable with design changes.  Largely, I think that is due to the fact that the game is in a state that we like, so changes are very minor.  Additionally, we are trying harder to take a "implementor gets creative authority of how a feature works" approach.  Which I thought we were kind of doing before, but I guess some people thought otherwise, once again due to communication issues.

All in all, I'm excited to see what Vinyl looks like in the next month.  Check out the current IGF build at www.thevinylgame.com

Vinyl: Installer Edition!

This is going to be a more technical heavy article, which is really what most of my posts should be about.  Anywho, one of my tasks this last week has been to build an installer for our game.  Given that we are building the game in Unity, it'd typically be pretty easy, there's a very easy build system built right into the editor.  You select the scenes you want, in the proper order, click the button and let it go!

When has that ever worked?  I imagine it probably would work pretty well for a normal game, but ours is running three separate programs, two simultaneously to handle all the weird stuff we do.  To start, when the game launches, we allow the player to select any mp3 they want.  This was a problem in itself because the file dialog box we were using was only available in the editor, so just to build I had to find a workaround for this.  Once the file is selected we launch a C++ program we wrote to parse the mp3 and generate the level from it.  From there we launch the game in Unity, and PureData, an open source audio engine, since Unity's Fmod wrapper doesn't give us anywhere near the amount of control we needed to manipulate the song in real time.

Because of all these shenanigans, we are constantly referencing song and level data files that are stored outside of Unity.  Turns out Unity isn't a fan of that, their system has you throw every asset required for the game into a Resources folder that then gets written to a giant binary file.  That won't work for us, so I've been figuring out a work around.  When you build a Unity project it creates an exe and a game_data folder which is apparently uses as its working directory.  If I copy over our External folder into the game_data, everything is then in the right place.  However, several little things have been causing a problem since, such as even though the relative paths are right, I can only seem to get files to successfully open with absolute paths.  Additionally, each method we use behaves a little differently, some require forward slashes, while others prefer back.

Once I get all the file reading to work properly in the built version, actually creating the installer should be fairly straightforward.  Since this game is going to be Windows only, Visual Studio has a Install Wizard project type I can use.  I just have to tell it what folders and files are required for the install and it more or less behaves like every other Windows install wizard you've ever seen.  It's pretty fancy stuff.

Hopefully we'll have a working installer we can send out to appease the masses by tomorrow.

Design, Communication and Faculty

So anyone who has read my blog posts from the end of last semester knows that we made a lot of dramatic design decisions with the game in rapid succession, without really settling on the best and without really having time to implement any of them.  We got more or less got to an alpha build over the summer, largely thanks to Cody and Sherly, but as soon as school started and everyone was back to have an opinion on design we seemed to lose focus once again.

Our biggest problem is probably communication, because if you were to actually track what the engineers have been building over the last 6 weeks you'll see we've more or less been on a similar track this whole time.  We've have a couple weeks where we tried new things to see if they were fun, but for the most part we've been working toward the same goal this whole time, while discussing potential designs a little too loudly, that were never meant to be officially implemented ideas.

In addition to that, the art side of of our team has fallen behind due to lack of communicating our needs.  With both of those combined, every member of the team had a different idea of what the game was supposed to be, which became painfully obvious when it came time to present to the faculty last week.

With the lack of art assets and direction so close to our IGF submission deadline, everyone was worried.  In retrospect, I think the problem seemed a lot bigger than it was, but it finally got us to sit down and plan out exactly what we want the game to be before and after IGF.  After a couple hours of design discussion we decided to change how a few features worked, which makes the game feel more comprehensive as an experience and is just more fun to play.  Ironically, its quite a bit more like the original prototype than it has been since May.

On top of that we have outsourced a bit of art, put Zeph in charge of the in house artists and seem to have a bit of a content pipeline going.  Of course, fall break just hit, which put a bit of a snag in our new found groove, but all the engineers are still meeting twice this week to implement a bunch of the mundane but necessary things such as fancy menus and building an installer (which I'll write about next, because it's proving to be quite the ordeal.)

Things should hopefully be going a bit more smoothly from here on out... we shall see!

Vinyl Shockwave!

During the last couple weeks of Vinyl development I've been implementing various gameplay features.  The biggest two have been obstacle generation and the shockwave (pictured above with programmer art).  We have already been generating obstacles based on beats and notes of songs for a long time, but it was thrown in quickly and the different types of obstacles could prevent you from hitting the others.  For instance, a ball could spawn at the same spot as a chorus filter, and the player could not hit one without the other.

I went through the generation code, and made sure things would spawn out of the way of other things, and added some functionality for spawning chains of filters for potential combos.

The way cooler thing I worked on was the shockwave.  Now when you jump out of the halfpipe, when you land everything within a certain expanding radius goes flying up and out of the pipe.  It's pretty satisfying.  As of right now, it just radiates outward from the initial impact of the player to the designer specified max radius over the specified time, blasting everything it hits out of the way as it goes.  I threw on the fancy static ball shader for now, so that we can visualize why the obstacles are flying away.

Vinyl After the Summer

Alrighty, Vinyl got a pretty major overhaul over the summer.  Basically most of the work we wanted to accomplish last semester, but had no time to do is now done.  Big props to Sherley and Cody for doing the bulking of the programming since the rest of the engineers had internships and were out of town.  I managed to throw together a useful main menu from Montreal, and sit in on several meetings via Skype, but for the most part I was busy with internships and had dodgy internet everywhere I was staying which made VPNing into the university network rather difficult.

Anywho, here's a short video of what the game looked like at the beginning of the semester, since I'm a couple weeks behind on these posts.

As you can see the pipe is now generated by the song itself and curves to the left like the groove in a record. There's some filters that carried over from the prototype and scratching, as well as a remixing system and some grinding rails that I believe were cut before this video was made.

Since the semester started we've been doing a bit more of an art pass, building the style we want for the game and bug fixing.  I personally fixed a few bugs involving the mesh generation and primarily worked on getting a rope made of tiny boxes to tether the player to the needle.

Here's an updated screenshot of the visual changes since the semester started.

The game is starting to look a little less like a prototype now, but still has some of the design/team issues I blogged about last semester.  We're working out the kinks and should be ready with something cool for IGF.

Year 2 Start and Summer Recap

So this blogs been pretty inactive for awhile.  Last semester was ridiculously hectic, getting worse and worse until finally coming to a sudden early end when I an internship offer from Ubisoft Montreal with extremely short notice and starting halfway thru finals week.  I managed to wrap up everything I was working on and get to Montreal with about 12 hours to spare, but the blog suffered a bit for it those last few weeks of school.

Anyway, the Ubisoft internship was really fun and I learned a ton about enemy AI, or at least how UDK does it.  It should probably be noted that this wasn't a traditional internship, it was kind of like a student project on a grand scale supervised by Ubisoft, that I got by competing in their game prototyping competition.  We basically built the winning teams prototype into a full fledged hour or two experience in 8 weeks using UDK.  It was an intense two months, but the end result was fantastic, and I was blown away by what some of those art students up in Montreal can do.  Here's a teaser video that has a download link in the info if you're interested.

Since that internship started so early and was only 8 weeks, I was done by the end of June with two months of summer left, so after taking a week off I headed down to Baltimore to intern at Zenimax Online working on the Elder Scrolls Online.  This was a more traditional internship and I spent the next two months building internal tools for the QA team.  It was great to see how a real studio operates from day to day and month to month and the game looks great.

The best part of these two internships is all the talented and also connected people I met.  I'm no longer worried about being able to find a job come May.

Onto this semester!  I know we're approaching 3 weeks in already, but the end of my summer was almost as hectic as the beginning.  I basically worked at ZOS until the Friday before school started, got back to Utah Saturday night, moved into my new house Sunday, started my new job as a TA on Monday and class started Tuesday.  And the homework for the first week held back no punches, I'll talk more about that when it's done (hopefully this afternoon) and make another update about Vinyl shortly!

It's good to be back!

Real Time Graphics Asg12

Check out my shadows, yo.  This assignment was easier than I was expecting.  The thing I had the most trouble with, even after questioning it in class and discussing it with Chris, was how the fragment from the shadow map could possibly correlate to the projected view.  It wasn't until I wrote the shader and saw what values we were actually comparing that I realized how it worked.

Anyway, here's my shadow map. 

Other problems I ran into mainly consisted of setting the directional light up properly.  Turns out that if I had just followed the writeup from the beginning I wouldn't have had a problem.

Here's the source code.  Sorry, I don't have more to say, it's 1am and this is the last thing I have to do to finish the semester.  It was brutal, but fantastic, learned a ton, thanks so much!

Catch up.

As I mentioned in the last post, Vinyl's had a lot of design changes this semester, but we had a few problems.  These mainly arose because the poor timing of a lot of big events this semester that pretty much killed our teams work flow as well as a someone nebulous design plan.

Mike and I from the beginning wanted the game to be everyone’s game.  We know how not having interest in a project can kill your desire to work on it, we saw a lot of that in cohort 2 and wanted to try to prevent that.  So from the beginning we tried to incorporate everyone into the design process.  This worked fine with a small team, especially since there were only ever two or three of us vocal about any particular mechanic.  Once we blossomed into a team of eleven however, every design meeting became a smorgasbord of new features.  People would talk to whoever was nearby about possible ideas, some would make it through the grapevine and become solid ideas without ever going through official channels.  Having a more organized set up for managing what ideas are new, how they fit in the game and if we want to prototype them would have been helpful.  Perhaps, in addition our daily standup meetings we should have had a daily design meeting where everyone spit out whatever new feature was on their mind and if we wanted it in or not.

Still, with the chaos of half or more of the team being gone for the majority of the alpha phase (if you can even call it that), I feel this sort of nebulous approach kind of worked.  Since there were so many ideas floating around, it gave the engineers that were around plenty of things to tinker with, without having to worry about an actual end goal.  Essentially, we were still in the prototyping phase for most of the semester, which made sense considering we didn’t have the manpower to go into full blown production.

Since we spent so much more time prototyping we now have a lot of cool features available to us loosely linked together.   To help with this nebulous approach to design and since we feel everyone has now had pretty ample say in what the game is, we are in the process of appointing two designers to have final say on features, with a product manager to keep us on track for who our target audience is.  We still want to take everyone’s input seriously, but we need a clear focused goal.  Also, now is a good time to make this transition because we seem to be at a place where everyone is pretty excited about the general vibe of the game, therefore maintaining that feeling should appease the masses… in theory.

Right now we are thinking Mike and I for final say in design, but the decision is still up in the air.  What we want is two designers to sit down and decide what will and will not be part of the final feature list before the summer starts.  This is because we are pretty far behind and if we want to have something presentable by IGF we have all agreed we have to work on this over the summer.  Most of the team will be around and available to work on the project this summer, and they are thankfully the people I have grown to trust to actually get the work done.

If all goes to plan, we should have all the major features, including the few massive undertakings I mentioned earlier, in some sort of alpha stage before school even starts next semester.  Therefore we should be well on our way to having a reasonable beta by October.

Vinyl Over the Months

I've been painfully aware that my blog posts this semester have been sporadic and pretty barren, and figured I'd take this time to actually make a thorough post about the design evolution of Vinyl and my next post will be about the problems we've had making progress over the semester what we plan to do to remedy that.

First Design

So the initial idea for Vinyl is pretty much nothing even remotely related to what the game is now.  Way back at the beginning of the semester everyone in our cohort was charged with pitching a game idea to be a potential thesis project.  One of our professors made the comment that he really liked music games so it might help our chances of getting chosen.  This sounded great to me, I've always wanted to make a music game.  So I got together with Mike and we tried to come up with an idea by looking at every cool music game we knew of.

Naturally that didn't work out that well, but a few days later I came up with the idea of turning the grinding mechanic from Sonic Adventure 2 into some kind of music game where you are grinding on the strings of some sort of instrument.  The idea was by jumping from rail to rail dodging obstacles you could essentially play the string part of the song.  This blossomed into a few other ideas such as flying through a brass instrument or bouncing off drums.

Second Design

So pretty much the only ideas from that game that made it over was that it's a music game, you can grind and it was still sort of a forced runner.  Or at least that possibility was solidified.  At this point Mike came up with the idea of being inside a record.  The player would grind along the ridges and do similar things as before.  Oh wait, I lied, we tried to incorporate the older instrument ideas as a sort of bonus section.  The problem with this was by essentially being the needle on a record, you would be in the groove and not of the ridges in between.  This problem of how far we pushed the actually being a needle in the record versus just breaking the rules of how records worked kept recurring.

Third Design

When we officially started prototyping we decided it would be better if we were in a groove and the game played a bit like the special stages in Sonic the Hedgehog 2.  The game got much simpler at this point, we went back to the roots of what made music games interesting and incorporated synchronizing gameplay with music.  To do this we spawned enemies based on notes of the song and sped up the music and slowed it down according to the speed of the player.  Some of this may have been in the second design, I'm a bit fuzzy.  The main point of this iteration was to emulate being in a record, while still being fun and not destroying the song too much.

Fourth Design

Our current plan is very similar to the fourth.  We have just included a few more mechanics, like grinding on the edges of the halfpipes.  We decided after prototyping that we were almost exclusively making the song sound terrible and that we wanted to look more into enhancing the music.  We found ways to do that from games like the new SSX.  Also, to further solve the problem of what a needle in a record is actually doing, we decided the player should be pulled by the needle like a wake boarder.  Therefore he can influence the needle a little, but the needle never leaves the groove, but the player can.

I'm pretty happy with the ideas for the game.  However we were supposed to ideally be design locked ages ago.  We're currently prototyping these new ideas out and plan to be design locked by the end of the semester so the students available can try to get us into alpha over the summer.  Next post I'll discuss how we got behind.

Real Time Graphics Asg11

This was a cool assignment.  It was nice to have an easy one after the ridiculous month I just finished.

The only real problem I encountered was copying and pasting handle code around that set things using the wrong constant tables and what not.  This actually led to a cool picture in picture effect I hadn't planned on.  I ended up setting the GUI texture as the already rendered back buffer texture.  I think at one point I even had it stretched over the whole screen so I was rendering everything to a texture, then copying that over pointlessly for some reason.

Other than that the assignment was pretty straight forward.  When you're done with everything, save it to a texture, then draw stuff onto that texture then display it.  Now that I think about it though, it seems like we should be able to just draw things directly onto the render target rather than copying things around.

Anyway, here's what it looks like with a kiwi as a health bar and a black vignette effect.  I also changed the clear color to green so that you can actually see the vignette effect.

And here's the code.

Real Time Graphics Asg10

Check it!

You see that crazy transparency on the blue spheres as they get close to the wizards face?  Yeah, I totally did that.  You can too, the arrows move all the spheres around, but now not the floor!  As you get closer to the floor it gets pretty transparent, I went a little overboard with the effect so you can really see it happening.

This assignment was kind of a tricky one.  I had a lot of problems with the depth buffer and what to do with it.  First I trying to copy the texture back to the actual DirectX depth buffer, which triggered an invalid call error.  I was on an airplane back from Montreal while doing this so googling the problem was kind of impossible.  Eventually I realized there was no reason to actually do this, since we can just sample from the texture.  Additionally, when to set the render targets and where to set them back had me staring at a beautiful black window for some time.

Here's what my depth buffer looked like by the way, and right afterwards is the actual depth buffer.

The biggest problem I encountered was something I didn't even think was a problem with mine until right before I solved it.  Other Jason was having this weird problem where only part of his spheres were showing up and when moving the spheres they went crazy.  My spheres weren't rotating and I had never moved the meshes, only the camera, so I just assumed mine worked and spent my time trying to solve his problem.  Turns out we were updating the meshes positions after we did the depth pass, which obviously you don't want to do.  We were just calling update on every mesh first thing in the draw loop, but since we added the depth pass before that loop we didn't think to move the mesh update above it.  Luckily I figured it out right around the same time I realized it was even a problem for me.  :)

One thing I kept wondering while working on this assignment was how when implementing the wobble technique we were told that games only ever do that effect once.  I figured this was because writing the entire screen to a temp buffer, then copying that over and manipulating it to make an object look like its effecting the background is really costly.  But sort of do that a second time in this assignment with the depth buffer (although we never copy it back) and we definitely do it again in the next assignment with the GUI stuff.

Anyway, here's the code.

Montreal!

Woo, busiest month of my life is now over.  I get to relax by catching up on the last 3 weeks of homework I had to neglect because of the Ubisoft competition and GDC... and flying to Baltimore for a day for an interview.

The Ubisoft competition was cool though, there were some ridiculously good looking prototypes there.  Guess that's what happens when your team of 8 has 6 artists instead of 1.  That said, we probably had cooler mechanics than any of them, or at least more complex, because we were so programmer heavy.  We definitely had more gameplay features.  We find out on Thursday who won what things and who will get the internship.  Also, it turns out I don't understand french so I had a hard time following most of the presentations.

Montreal seems like a cool city, or at least the 3 blocks of it we got to see.  Alcohol flows more freely there than in Utah at the very least.  Though alcohol flows more freely everywhere than in Utah.

Even if we don't win though, this competition was a pretty awesome experience.  It was interesting doing an even bigger prototype than we'd ever done in class, in a new and not even remotely user friendly engine, while simultaneously going to work and school, with a bigger team that usual to boot.  I may have bit off a bit more than I could comfortably chew this semester, and I can chew a ton, but it was definitely doable and I still got some skiing in.  Makes me happy knowing that next year will probably be substantially easier than this one, cause I'm pretty burnt out.  It's gonna be nice to get paid during crunch time rather than paying tuition to be in crunch time.

Anyways, not much more to say, at least not more than I'm willing to say. ;)  I think this experience will help when making Vinyl next year.

GDC and Vinyl stagnation

I just got back from GDC.  It was pretty cool, and I can check it off my list of big gaming conventions I'd like to attend one day.  Just leaves E3 now and I'll have pretty much all the big ones, including TGS.  That said, pretty much no one seemed too interested in hiring interns this year.  I had way more fun just finding triple A studio programmers and asking them questions and picking the other big schools students brains about their programs.  USC, Digipen and RIT were all there in pretty full force.

Next year should be awesome though, since everyone seemed pretty interested in hiring entry level stuff, and Vinyl will be almost complete.  Also, I plan to buy the nice pass and actually go to a bunch of the talks.  I went to one, but it was more about selling their product that automates LODs than talking about how they implemented their software.  Still, looked like a cool product.

Anyways, the reason I mentioned Vinyl stagnation in the title is because sadly, we haven't gotten any real work done on it since the industry panel.  One thing led to another and there just hasn't been any time.  Basically due to delays we didn't even do the industry panel until the week before spring break, when it should have been 3 weeks before.  So by the time the teams were settled we had a week off.  Then a week on again before GDC, and now another week after that where half our team, myself included, will be in Montreal.  That leaves about 3 weeks left in the semester to get into alpha.  Looks like we'll be doing a bit of  summer work.  That's okay though, I'm still more excited about this idea than any of the other projects I'm working on.  They just sadly had to take precedence for the time being.

Speaking of which, the main thing that has been occupying my time lately is the reason we're going to Montreal.  A bunch of us are in a game prototyping competition that Ubisoft Montreal is putting on.  Since we leave on Tuesday we've spent the last two weeks crunching out the end of the prototype.  Last weekend we went from a tech demo with empty levels to basically a full blown game in about 25 hours of work time.  This weekend, shortly after arriving back from SF we polished everything we could and tweaked a few more things.  The game looks amazing now and I can't wait to show it off in Montreal.

Still, I can't help but thinking maybe I put a bit too much on my plate this semester.  4 weeks til summer though, can't wait to just have a job for a few months.

Real Time Graphics Asg09

It's so shiny!!

Seriously, look at how shiny that dudes face is, it looks especially creepy on the floor.  It's like you can almost see an entire galaxy in his face, or maybe just a nebula, I dunno.

Anyway, this assignment was fairly straight forward, just ran into a few bugs.  Mainly fixing the camera to work how it was described in the email broke a few things.  I believe the problem was resolved by negative a value.  I'm not entirely sure why we needed to change anything, since from what I understood we were just passing in extra data that we didn't need originally.

Other than that the environment map worked just fine.  DirectX has great support for it.  I wonder, do people invent these technologies and then DirectX includes them in the next major release or how does that stuff work?  I thought environment mapping was a fairly new thing, but we're still rocking DirectX9, which is almost 3 years old now.  Then again, the teacher mentioned Shenmue 2 doing it and that was like 2002...

Moving onto the second part of the assignment.  Making anything behind the first sphere wobble according to a tangent function.  I dunno why we like tangents so much, probably cause of the asymptote that breaks up the squiggles.  In order to do that we had to all the non transparent geometry, save that to a texture and then draw the transparent stuff using that texture as a background.  Then copy it all back and actually draw it to the screen.  Here's the screenshot showing the texture before the transparent entity in PIX.

I was having trouble figuring out where to place the draw copy it back code, because when I stuck it in my transparency if checks it never fired since none of the entities were technically marked as transparent.  This led to a nice black screen, even though I could see all the stuff being rendered properly in PIX.  Sherly helped me modify my if check so that I got everything but the floor, turns out I was now copying the texture over to the backbuffer, but was doing it twice so I overrode the floor with the second entity.  It was kinda neat to see each draw call in PIX and watch the exact moment the floor went bye bye.  Fixed that one with even more modifications to my if check.

Those were the only real problems, the actual graphics part of the assignment was pretty straightforward.  Which is odd cause they are both pretty bizarre ideas.  Reflecting something that isn't actually there has a surprisingly cool effect that is very noticeably different from just specular.  I assume you would generally want the environment map to mirror whatever is in your skybox though.  I was also blown away by how we achieve the squiggly ball affect.  Literally saving the entire frame and then drawing over it seems like a ridiculous amount of extra work to do every single frame.  That said, we are essentially doing that anything with each mesh being drawn on top of the previous one, but we're only drawing the fragments we need each time.

The teacher said we could only do it once or it'd get too slow, but I wonder if we could pull it off again considering how little we're actually doing in our scenes.

Anyway, source code!

Real Time Graphics Asg08

This weeks assignment was pretty cool actually.  I always had an inkling of what bump mapping was from being around games all the time, but upon actually implementing a simple normal map I'm a little blown away by what you can do to a surface by just altering some normals.  Here's the assignment for the random googlers.  And here's what the assignment ended up looking like.  Guess which one is specular.

I'm not entirely sure what to include in this writeup, usually I talk about all the horrible things that went wrong, but this one was pretty straightforward.  The hardest part was properly scaling the cube in Maya to output a cube at the same size as our hand coded cubes.  Changing the Maya exporter to output bitangents and tangents was exactly the same as how we were already output the normals.  The actual fragment shader code was pretty simple too, just modifying some normals with the new values.

I did find it interesting how DirectX handles multiple textures per mesh.  I figured we'd have to explicitly call SetTexture with the specific texture name, their way is much nicer.

Other than that I spent a bunch of time making new text files and cleaning up some things.  I took the specular exponent out of the scene file finally, even though I wasn't even using it.  Additionally I decided on an expected texture type of 0 to be just a texture and 1 to be texture and normal .  This way I can just do a simple int compare in the update loop, might not be the most human readable though.  Spoilers, 2 will probably include environmental maps.

I also spent a lot of time figuring out how I broke my specular lighting awhile ago.  Apparently I was passing a zero in for light intensity, which when multiplied with my specular lighting went to zero.

Anyway, here's the code.

Vinyl Greenlit, Administration discussions ensue.

So Vinyl got through the industry panel, because its awesome.  Our team has now more than doubled in size.    Sadly, two of the four got cut, including Ludology, which I thought was a fantastic idea and my fallback plan in case Vinyl got axed.  Ah well, such is life, Cosigners and Vinyl absorbed the other teams and now we finally get to start planning to make a game that isn't just a prototype.

We spent most of the first week debating platforms and engines.  A lot of the feedback we received suggested we do a mobile game.  We kind of like that idea, but we wanted to use Crytek and they cannot easily deploy to anything, but a PC.  The more we debated it though, the more we decided we could make a better game on PC and that trying to hit mobile because it's a better market is pointless.  We are a student game and we should be trying to execute a cool proof of concept.  If we have some time when we're done we could look into porting to Unity and deploying a lesser version on mobile.

On the other hand though, it looks like we may have to pony up a few hundred thousand Euro's to get a reasonable Crytek license so we might end up using Unity from the beginning.  We expect to spend most of our time figuring our how to process individual song sound waves anyway, which will be engine independent, and then using that data to generate levels.

So far we've looked into a few different opensource softwares to do that and a Unity library.  Looks like I might have to brush up on my partial differential equations as well.  Who knew those things actually had a use.

I'm gonna mess around with those over spring break and report back with some actual engineering stuff hopefully.  Catch yah on the other side.

Real Time Graphics Asg07

This assignment wasn't too shabby.  Once again the hardest parts seemed to be the sorting and setting up the  PIX calls properly.  I probably went about this the completely wrong way, but its been one of those weeks, or months or semesters or whatever.  Anyway, for the assignment we had to set up PIX event calls to make debugging in PIX easier.  Which is pretty awesome, but I haven't really had a reason to use it in awhile.  I suppose that's good, I'm sure I'll learn all the details when something goes horribly wrong as with most debugging tools.  Check these awesome buckets though.

The transparency stuff wasn't too bad.  Sorting the draw order so you could see all three cubes inside of each other was kind of a hassle, but not terrible difficult.  I now have somewhat gross sorting loops in more than enough places, but hey, selection sort on 9 items is probably manageable.

I think the thing that caused me the most trouble was actually a sorting loop that got copied and pasted from another incorrectly.  It was actually causing my transparency to not work at all, I think because certain settings were turned off at certain times.  Once I caught the error, a counting issue, everything just worked.  

Also, I had an issue with the world being incredibly dark, but I think that problem stemmed from some bigger issues.  I'm not sure my specular lighting was functioning exactly as it should.  Speaking of which, I moved the specular exponent to the materials finally, so be happy about that.  :)  I just realized I did not take the number out of my scene file though, so it is still being read in and parsed and not used.  I'll fix that later, everything is already zipped up and uploaded now though.  Anyway, back on track, my specular lighting wasn't quite working properly I thought, and upon looking into it I noticed I was actually passing a zero into the shader instead of my scene files value, I probably switched it out a bit ago as a test and forgot about it.  Upon fixing that, and a few other things, that I messed up this week, the scene went really dark.  Part of that was because of my ambient lighting being really small do to compensate for some of the other errors I had.

Long story short, there were several small lighting problems that when fixed turned into other problems.  I think I got it all sorted now.

Here's the code.  Sorry this writeup was so rambly and all over the place.  Hope you got the gist of it, nothing in particular actually pertaining to the assignment was terribly difficult this week.  Just a lot of little things that needed to be fixed.