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.