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.