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: 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.

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.

Vinyl and the Industry Panel

Last night was the "first gate" that we had to get through to get our prototype greenlighted... sorta.  I kind of feel like getting chosen among the 15 or so pitched games was really the first gate, but I suppose not.  We're mostly programmers, lets call that one the zeroth gate.  Anyway, the game has progressed a ton since I've last written about it.  It currently has particle effects instead of spheres for the static, and the lasers look a little better and even pulse as they pass by the player.

Most importantly we have an equalizer now that jumps to the music and we spawn the enemies based on the intensity of the song.  It definitely needs a lot of tweaking, some songs do almost nothing and others spawn absurd amounts of enemies, but it was definitely effective for the prototype.  Here's a video of someone playing really well, you can see it get crazy when the metal part starts.

http://youtu.be/icjEKQDvM-8

We also have a video of someone butchering Thriller since changing your speed affects the pitch of the song and moving side to side affects volume.

http://youtu.be/HjB0d-RGBAs

The game is pretty fun to play, it just needs some further refinement and a probably a few more features.  And a real artist, right now its pretty much been Mike and I throwing colors into the mix.  If we get past the first gate we have some big plans though that I'll cover in another post.

The first gate went really well, but we'll find out for sure on Thursday which games made the cut.  Everyone put forth a fantastic presentation and had some great prototypes, so it'll be interesting to see what ends up happening.

Colors Everywhere!!!

Well, Vinyl now has an overwhelming amount of color in it now.  We got put fancy bright colored texture on the half pipe that repeats to give the player a sense of motion.  Before you couldn't really tell if you were moving since it was just a super long gray halfpipe with a fixed camera.  The balls rushing toward you helped, but the colors makes it feel a bit more frantic and hip.  We also randomly generate colors for the balls.  Ideally these will turn into some sort of electrostatic particle effect, but that isn't really necessary for a white box prototype.  Lastly, we added lasers in that are really just long cylinders that you cannot pass through.  They are forewarned by a red ball about a half second before they show up.  However with the multicolored other balls it's a little hard to tell right now.

In addition to all that Shirly implemented a lot of the musical features of the game.  We couldn't natively make Unity force audio out of the left or right speaker, so for now the farther you get away from the center of the halfpipe the quieter the music gets.  Additionally the speed at which you move affects the songs playback speed.  It's kind of a neat effect, but its still a little wonky.  Definitely works better with some songs than others.

Right now we're figuring out how to analyze the songs using Unity's libraries to actually generate the obstacles.  Also, we'd like to implement a rewinding function.  I have an idea about how to do it and will hopefully get that working on Thursday.

Here's a screenshot of all the colors.  This should hopefully clarify a bit of the details of what I'm talking about.

Oh, also we added some fun lasers in the background for a cool visual effect.  It was kind of an accident when we implemented the red lasers, but it looked cool enough that its not a bug, its a feature!

More Vinyl Changes and Progress

So I mentioned in the last Vinyl related post that we were making some substantial changes to the design.  It sounds like everyone in the cohort did because we're now getting an extra week to work on a prototype.

Anyway, the essence of the game remains the same, but to further emulate being in the groove of a record we decided to put the player in a halfpipe like Sonic 2's special stages.  This allowed us to brainstorm a lot more record-like abilities and functionality.  We still want to effect the stereo sound based on the side of the halfpipe you are on, but are running into technical difficulties with Unity for that, in that Unity doesn't seem to be capable of doing it.  Additionally we came up with ideas such as a player usable "scratch" that rewinds time a bit and of course plays the "wiki wiki" sound.  We'd also like the pipe to curve and drop according to the beat.  I think the coolest, but possibly the hardest feature to implement is changing the point of the song based on if the player gets to far up the side of the pipe and falls into the next track of the record.

What we got so far is fairly simple, we have a player cube that can go up and down a halfpipe while randomly generated balls rush past it.  Here's a screenshot.

The hardest part was getting the cube to actually move along the curve of the halfpipe.  We tried a number of techniques, but ended up settling on a rotateAround method that is currently using the origin.  This isn't going to once we start changing the pipe's direction, but it should suffice for now.  We shouldn't have to change it too much once our levels get more complex.

Vinyl Tech Stuff

So the only substantial thing that happened last week was technological stuff.  The cohort of students ahead of us in the program made a forced runner thesis game in Unity and I asked them some questions about how they did it.  Turns out they used this pretty fantastic library called iTween that does a lot of animation type stuff and even music manipulation.  I spent awhile this week learning my way around the framework and got a cube spinning around a record.  It sounds like we'll be changing the design idea around a bit this week though, so I didn't go too much farther.  iTween will work just as well for the new idea however and hopefully we can get started tomorrow or Thursday.

I'll discuss the details of the changes in a later post and maybe some screenshots of what we got.