Friday, December 13, 2013

My Second Attempt at Ludum Dare is About to Begin


It's that time again!  As of writing, we're about thirty minutes away from the theme reveal.  I'm rather ill prepared for this game jam, so we'll see if I can make it.

My last attempt was for LD #26.  I've recently released a more polished version of that game on itch.io.

I'll try to post regularly on their public blog, so if you want to see any of my in-development ramblings you can find them here.

Thursday, November 21, 2013

Better Late Than Never...

Hello everyone.  It's been a long time since my last blog post.  I've been incredibly busy the past few months, and haven't had the time to provide an update on the various projects I've been working on.  I hate to say, but I've stopped and started this blog post several times for two months now...

Which is unfortunate, as a lot of cool things have happened.  Buckle in, this could be a long ride.

Updates on Prisma
We're still trucking along with Prisma.  It's been a very slow process, but we have made some notable improvements to the game since I last talked about it.  Firstly, the user interface...


As you can see, the main menu has been completely revamped.  Hank did a fantastic job creating illustrations for the title screen.  In order to make them move based on the player's current selection, I used a handy, free plug-in called HOTween.

However, the main menu wasn't the only part of the user interface that was revamped...


We also revamped the gameplay HUD.  Alex selected a different, more readable and thematically appropriate typeface, and Hank created a new power indicator as well.

But wait!  There's more...



We've also updated the pause menu and end of level menu.  Basically, everything has been changed and revamped.  This process took about a month and a half to complete, but I wanted the team to move slowly and confidently instead of rushing ahead without care.

In late August, the team determined the next steps towards polishing Prisma.  I drafted a flow chart -- which is visible on the left -- that demonstrated our current priorities and the order in which we should approach tasks.  I also decided to continue with a two-sided approach where the art director focuses on defining the visual look of the game and the designers and programmers implement functional constructions.

Alex took charge of the menu design, and created rudimentary frameworks that the Hank could draw over. After the draw overs were completed, Khoa and I implemented them into the engine.  Overall, I think it is a tremendous improvement over what we had before.

With the updated user interface, we also implemented a ranking system that grades the player on how quickly they complete a level.  Each level has a set of par times (Goddess, Guardian, Titan, and Underling) which are all stored in a single XML document.  My script then grabs the XML document and determines the par time for the level.


Another big update to Prisma is that our diffuse swapping shaders finally have the ability to accept lights.  This update has, in my opinion, tremendously improved the look of the game.  There is now actual depth and a sense of three-dimensional space to the environments.

Behold...

Out with the old...

...and in with the new

Finally, we decided to revamp the red ability.  Originally, when the player was in the red dimension, the player would be able to push and pull specific objects around the environment.  The player's range of possibility was somewhat constrained, yet it still allowed for some interesting emergent behaviors.

That being said, we felt that it did not synergize with the blue and yellow abilities, which let you jump higher and run faster, respectively.  In other words, the red power could not stack with the blue and yellow abilities, which almost always disappointed play testers.

Why were we introducing two abilities that were explicitly related to each other, yet the third and final ability had no direct relationship to the other two?  In hindsight, simply pushing and pulling objects was not the logical conclusion for this mechanic.  Despite these problems, we did like how pushing and pulling added a new dynamic to the play area.  A level was no longer a static construct that the player had to navigate around; instead, it was now something that the player could modify within limit.

What am I getting at here?  It's actually quite simple:  we had a good idea, but the execution wasn't fun. Therefore, it needed to be changed.  So now, instead of simply pushing and pulling blocks, the player can now physically pick up and carry objects around the environment.  On a surface level, this might not seem like much of a change, but in reality it modified the dynamics of Prisma by a great degree. Below is a list of reasons why:

  • Most importantly, the player can now use the blue and yellow abilities when carrying a movable object.  By picking up an object with the red power, the player can then switch to blue or yellow to take advantage of those abilities as well.  With this change, it is possible for the player to have all three abilities activated at once.
  • Before, the player could only fully control the movement of objects along the x axis.  Movement along the y axis was constrained to downward movements.  By being able to pick up objects, the player can now carry objects upwards as well as downwards.

Naturally, such a big change required us to go back to the drawing board for the third world.  Alex is currently heading the charge, and from what I've seen, the levels are a big improvement over what we had before.  I look forward to sharing more of that at a later day.  Please be excited! *wink*

Introducing Bala

When I haven't been working on Prisma or independent contracts, I've been assisting Angelica, David, Daniel, Hank, and Khoa develop Bala.  Bala is a twin-stick shooter that focuses on exploration and discovery over linear action, and is being developed for Angelica's and David's senior-studio class.  I'm acting as lead programmer and level designer on the project.

We began work on Bala in the middle of September, and we just recently cleared the Alpha milestone. A lot of Bala's team worked on Prisma, and I think it's pretty clear that a lot of the lessons we learned from Prisma are showing in Bala.  Below are some of the cooler elements that are currently in the game:


We've implemented eleven enemies for the Alpha build.  Some of these enemies even have textures and animations applied to them!  I'm also really happy we got to experiment with rigging a rudimentary model and basing its attack pattern on animations.  You can sort of get a glimpse of them in the animation above.

I'm not sure how much else I'll post about Bala on this blog, but if you want to read more about my specific contributions you can start here.

That about covers a good portion of my past two months.  I'll try to update more frequently, from now on...but we'll see.  Thanks for reading!

Monday, October 7, 2013

SCAD Generate 2013: Designing a Level in 24 Hours

This past weekend, I participated in Generate, which is a campus wide event at SCAD-Atlanta where students from each department work to complete a project within twenty-four hours.  For the game development department, we were tasked with building a level that effectively utilizes space to convey meaning.

I worked with Hank Silman, Angelica Rodriguez-Vazquez and Graham Waldrop to create...a rather strange environment.



My job for this project was to design the environment and implement the technology that would be required to achieve our goal.  Angelica formulated the original concept, which was to create a naturalistic environment that represents the various stages of life.  From there, we decided to chunk the environment into three distinct segments:  death, birth, and nirvana.

The first draft of the level map
Early on, we decided we wanted the level to start off with everything dead and decayed.  As the player progressed through the level, the environment would slowly rejuvenate itself:  textures would be more saturated, flowers would be blooming, and animals would populate the area.  This core idea is representative in the final build, but we quickly decided to deviate from the linear pathway that I initially sketched out.

Because we were building an interactive scene, I decided to instead take advantage of the extensibility of Unity and make the level a seemingly endless loop.  I wanted to procedurally modify certain traits of the environment as the player walked between each section, such as the number of objects in an area, or the direction in which they were facing.

Unfortunately, I over estimated my willingness to write this sort of code at three in the morning.  It ended up taking longer than I expected to place all of the assets and arrange collision volumes.  By the time I was ready to start adding in special effects, I was already running on limited energy.






The second draft of the level map
Even so, production of the level went smoothly.  Thankfully, my careful preparation of the level map made the initial arrangement of the environment incredibly simple.  I first created two rudimentary maps on paper so that I could quickly iterate the core idea.  Upon finalizing the core concept, I took it into Adobe Illustrator and created a polished level map.

The first illustrated map is pretty representative of the final level's layout.  Most of the assets that we planned were put into place, with the only real exception being the frog eggs.  Not setting aside time to add in the frog eggs was one of my biggest regrets for this project, as I wanted them to be one of the few things that the player could directly interact with.  My intention was to attach rigid bodies to the eggs, and allow the player to roll them into the lake.  If an egg entered the lake, it would have become a tadpole, which would then swim away.

To me, this was a crucial aspect of the implied narrative that was planned, and their absence took a lot away from it.  Even so, I still feel like there are more successes than failures in this environment.

Illustrated map made from paper drafts

When designing the layout, my goal was to create an esoteric environment that would provoke the player to develop their own interpretation.  I wanted this to be something akin to ride from a twisted Disney park, where the story is told through a series of sign posts that the player moves past.  Indeed, it's important to stress that I did not intend for each of the three sections to coexist together.  Instead, each of the three areas are supposed to be representations of the same environment at different points in time.

While I did have an implied narrative in mind when building the environment, I deliberately made it so that the player could draw their own conclusions after spending some time in the setting.  There are a few factors that allowed this to happen:

In editor, over head shot of the environment.

  • The non-linear nature of the environment means that there is no "correct" pathway, and thus by extension no "correct" interpretation of the narrative.  While our original plan was to have the player go from Death -> Birth -> Livelihood -> Back to death, the final layout ultimately allowed the player to go wherever they want.  Even though the player starts off in the death area, they are free to go to either of the other two areas.  Where they choose to go first will impact their interpretation of the environment.
Notice the unnatural elements of this shot, such as the upside down bird and the giant bird obscured in the fog.  The player is allowed to develop their own narrative around why these things are here.
  • As I watched people explore the environment, I noticed that they didn't realize they were walking around in a circle.  It's difficult to ascertain why this is the case, but my personal theory is that the environment, upon first experiencing it, gives the player a wide range of imagery at a fairly fast pace.  Upon loading the environment, the player is immediately confronted by dead frogs and menacing birds.  Shortly after stepping away from this environment, they come across a serene, misty area with blossoming flowers and eggs scattered about.  There is a huge contrast between the three areas of the level, which means the player tends to not fully acquaint themselves with an area upon their first run through it.  This means that, upon returning to the area with the birds and dead frogs, the player is likely to absorb information that they did not notice before, thus making their return to the beginning a fresh experience in itself.
The fog effect and ambient lighting gave a much greater definition to the lotus flowers.
  • Finally, I feel that the changing color of the fog and ambient lighting did an amazing job setting the mood, as it convinced the player to continue exploring the environment.  Changing the fog was done through code, and was activated whenever the player entered a trigger volume that enveloped one of the three areas.

I am very impressed that we were able to build a level of this scope in such a relatively short amount of time.  Designing the layout was incredibly fun and rewarding; as the night progressed on, my sleep-addled mind allowed me to make some odd decisions, such as placing a bird upside on a branch for no real reason.  I feel that this contributed to the dream-like, mysterious nature of the environment.  Regardless, Generate was a great experience, as it allowed me to push my level design skills to the test.

Saturday, July 13, 2013

Information and Boundaries Within Games

All play moves and has its being within a play-ground marked off beforehand either materially or ideally, deliberately or as a matter of course. Just as there is no formal difference between play and ritual, so the ‘consecrated spot’ cannot be formally distinguished from the play-ground. The arena, the card-table, the magic circle, the temple, the stage, the screen, the tennis court, the court of justice, etc, are all in form and function play-grounds, i.e. forbidden spots, isolated, hedged round, hallowed, within which special rules obtain. All are temporary worlds within the ordinary world, dedicated to the performance of an act apart.

-Johan Huizinga in Homo Ludens: A Study of the Play-Element in Culture

A few weeks ago, I had a conversation with a friend about how The Legend of Zelda series has evolved over the years qualitatively.  One of his points was that The Legend of Zelda:  A Link to the Past is objectively better than the original Zelda, because it takes everything that the original did and improves upon it.  Better graphics, better sound, and arguably even better level design.  More importantly, he considered A Link to the Past to be the better game because it included an in-game map.  With that feature, the experience becomes more directed, streamlined, and user friendly.  For him, the experience becomes more enjoyable.

I don't necessarily agree or disagree with that point.  However, since that conversation, I've been thinking a lot about the boundaries of a game, as well as the implication of features such as in-game maps or guides.  The degree in which players receive information changes the dynamics of the experience.  By not providing in-game maps or information, players are instead encouraged to document their findings with resources outside of the game, such as with pen and paper.

One of the earliest instances of this can be seen during the Atari 2600 era.  During this time, almost every game involved players accumulating points in an endless game loop. The game would only end once the player had reached a fail state, and there was almost never a plot or narrative goal to reach.  Naturally, because these games were score-based, players found themselves competing with each other to see who could accrue the most points.

However, the games were unable to store high scores in memory; therefore, if players wanted to keep their scores, they would have to document them outside of the game.


Notably, players who accumulated high enough scores in Activision titles were even given physical incentives that took the form of fabric patches.  Much like the achievements and trophies that proliferate in gaming today, players were given meaningless tokens for reaching milestones.  However, back then they had to use a Polaroid camera and the postal service to claim their prize.

While interesting, the incentivization of a high score through physical goods didn't, in my opinion, impact the game's boundaries in a dynamic or meaningful way.  As games grew more ambitious in scope, the juxtaposition between game and reality became more nuanced.

As such, players found themselves getting lost within the game world.  For example, players often had difficulty navigating through the original Metroid, which featured no in-game map and very few landmarks to help players determine their location.  If players didn't have a subscription to Nintendo Power, their only option was to chart the game's world on paper.  This was particularly true for games not on Nintendo platforms, such as Wizardry, because there wasn't -- at least to my knowledge -- a magazine with all the answers.

I find this to be an interesting expansion of the game's boundaries as the player is no longer playing the game with just a gamepad.  While the core mechanics still occur within the digital space, an ancillary mechanic emerges from the need to map their progress.  In addition to being a hero with a sword or laser gun, the player must also be a cartographer.  Correctly charting the lay of the land becomes a game itself, as incorrectly documenting the world's geography could lead to disastrous results.

Some titles have even acknowledged this behavior, and integrated it into the core game system.  For example, the Etrian Odyssey series for the Nintendo DS uses the console's touch screen to emulate a pen and paper map.  While these games are essentially another take on the first-person dungeon crawling formula, there is an intrinsic beauty in making map drawing a part of the game system.  For one, players don't have to worry about having their work modified or tampered with.  Furthermore, because it is a digital map, the player is given ample space to make detailed annotations.  Finally, it is much easier to make corrections to a digitally drawn map than it is a hand drawn one.  The Etrian Odyssey series is a notable curiosity because it's a rare example of a system taking out-of-game behavior and bringing it back into the game.  The end result is, in my opinion, quite elegant.


A few other titles were even more creative with having players interact with real world objects.  For example, StarTropics featured a puzzle where players were required to take a letter -- which was packaged with the game -- and dip it in water in order to obtain an access code.  At the time, this was likely an early attempt to combat rental services and used game sales.  Either way, the letter became very difficult to find, thus making the game unbeatable for many...at least until the advent of the internet.

It's an interesting riddle, because the solution doesn't exist within the confines of the game world.  To solve it in the way the designers intended, the player must make actions that are atypical for a video-game.  The issue, however, is that it prevented many players from progressing through the game naturally, as they did not have access to the object that the designers required.

The recently released Ni No Kuni:  Wrath of the White Witch attempts something similar, but handles it in a much better way.  Players who purchased the special edition of the game received a lovely reproduction of the Wizard's Companion, a book that the main character carries with him throughout the game.  The book outlines various aspects of the game, providing the player with alchemy formulas, a bestiary, and extensive backstory.  There are several points where the game requires the player to research this book to progress.  However, because the designers knew that not every player would have access to the book in physical form, a digital version is included within the game.


While the digital version of the book was smartly included, I still found that thumbing through the physical Wizard's Companion was a much more satisfying experience.  Whenever the game asks for information from the book, the player must provide the answer by manually typing it out.  Most roleplaying games would present a multiple choice question, whereas Ni No Kuni requires the player to fill in a blank.  This process was streamlined and made much more entertaining by the presence of a physical book, as I didn't have to close the in-game keyboard to interact with a clunky Wizard's Companion interface.  In other words, I was playing the game not with a controller, but with a hard-bound, 340-page tomb made to emulate a magical in-game relic.

As a designer, it's important to think about the boundaries established by your game, and realize that the degree of information given to the player will impact their interaction with the game.  By providing information in-game, the experience becomes streamlined and user friendly.  On the other hand, hiding information creates an opportunity where the player may interact with the system in a way that is unexpected or atypical.

Thursday, June 6, 2013

Xbox, Go Home

Since the terrible PR debacle that was the Xbox One reveal, I've been saying that Microsoft needs to clearly and honestly state their policies, and let consumers decide rather or not the product is right for them.

Now that they've attempted to clear up that message (and failed), I feel that the Xbox One is fundamentally incompatible with my views as a gamer as well as a developer.

I'm ambivalent to used games.  I don't typically purchase used games, and I rarely lend copies of games to friends or family.  I never trade-in either, so their policy in this regard largely doesn't affect me.

I also don't really care about the privacy concerns surrounding the Kinect.  I'm not going to do anything that would get me in trouble, and it's not like I'm going to flash my social security card in front of the camera.  Potential voyeurs will only see me yelling in frustration at Dark Souls.

However, the one thing I do not like at all is the need for the console to check in every twenty-four hours.

I'm not talking about verification of used games.  Used games are, actually, completely irrelevant to this discussion.  By extension, media sold through retail is also irrelevant.  As Phil Harrison so, *ahem*, eloquently, put it, this discussion is actually about "the bits [that] are on your hard drive."  No matter where you get your content, your access to it is being controlled by someone else.

As far as we know, the Xbox One requires what could be considered a persistent connection to their servers.  Users will, reportedly, be able to play without a connection for up to twenty-four hours.  That's a problem, and it's not because my internet connection is spotty.

Remember the fiasco that was Sim City?  What about Diablo 3?  Or what about almost every MMO launch ever?  Remember when Playstation Network was taken down?  How about when Ubisoft's DRM servers crashed due to Steam sales?  Must I go on?

Point being, the consumer's quality of internet isn't the determining factor in this situation.  Microsoft has put themselves in a position where they must provide a secure, reliable connection to their service for me to be able to enjoy the content that I'm paying for.


Microsoft's justification for this policy lies in "the cloud."  As they say themselves, "because every Xbox One owner has a broadband connection, developers can create massive, persistent worlds that evolve even when you’re not playing." Granted, yes, this particular feature has the potential to be very useful for specific game types.  For example, Destiny, Bungie's massive multi-player title set within a persistent world, could potentially benefit from this architecture.

However, here's how Microsoft decides to pitch it:

"Part of the cloud processing could be focused on elements such as lighting in games. Booty describes a forest scene where light shines through trees, or a battlefield with fog. Both elements don't need to be updated in real time and can be processed in the background, while the controller remains responsive to the action parts of the game. 'Those are perfect candidates for the console to offload that to the cloud—the cloud can do the heavy lifting, because you’ve got the ability to throw multiple devices at the problem in the cloud.'"
-The Verge, "Microsoft explains Xbox One cloud gaming in an effort to justify online requirement"

So...the justification for a persistent connection is to have improved particle effects and lighting?  Keep in mind, every game will need to be able to "intelligently handle" the occasional network outage for it to be playable.

How in the world will this improve the development cycle?  As a developer, I cannot fathom the desire to further complicate the production process for better graphics, especially if the project is planned for additional platforms that won't have cloud functionality.  As a player, this isn't improving my experience.  In fact, if there's a noticeable loss of quality due to a network drop, it might actually hinder the experience.

Granted, yes, this is all speculation on my part.  But so far I've yet to see anything to convince me otherwise.  If better graphics is the first benefit to be pitched, then I really don't see this as anything more than a marketing buzzword.  Pro-tip:  the use of cloud computing as a buzzword is the exact mentality that Mega64 is lampooning in the video embedded above.

Point being, not every game should be expected to benefit from Microsoft's cloud.  I suspect most multiplatform titles won't.  Therefore, I feel that the cloud as justification for a required, persistent connection is incredibly weak.

Tuesday, June 4, 2013

...The Journey Ends [For Now]

Last week, the SCAD quarter ended.  In turn, this means that that the school year concluded, and with it the very rigorous course that was Senior Studio.

What does this mean, exactly?  Quite simply, it means that Team Prisma has reached an incredibly important milestone:  we've "shipped" a fully playable game, which can be downloaded for free at prismagame.com!

I sarcastically put "shipped" in quotations because, to be frank, the game is still pretty rough.  There's a lot of features that we had to cut, and there are several portions of the game that we had to rush to meet our deadline.  Prisma is nowhere near ready to be a commercial product, but as a student project and as a portfolio piece I feel that it is quite successful.

Development of this iteration of the game started nearly a year ago, and I've learned a ton of things along the way.  For this blog post, I'd like to share a few of the lessons I learned as I worked on Prisma, in post-mortem format.

What We Got Right

Rapid Prototyping

One of the things that I'm most proud of with Prisma was how quickly we iterated, from core concept to level design.  As a programmer, one of my initial goals was to expose the level designers all of the various variables that controlled the player, such as movement velocity, jump height, and much, much more.

I believe that this process was successful, because the designers were able to determine early on how Prisma felt, and were able to fine tune these variables real-time, in-engine.  Because of this, we rarely had any complaints about how the game felt during play testing, and rarely had to tweak the variables during the later stages of the project.

"Killing Our Babies"
I sincerely hope I don't get any weird people visiting this blog because they found it through a gruesome Google search!  Nevertheless, this phrase is commonly made in a joking manner at SCAD, as it is simply a way of talking about cut features.  Like any game production, we cut out a significant number of planned features, because it was apparent that they were out of scope.

At first glance, this may not sound like a success on our part.  However, I feel that this saved Prisma's production in many ways, because we were very smart in picking which features to cut.  By doing so, we created a very clear image of what we needed to do to make a complete student project.

What We Kinda Got Right

Delegation of Authority
Officially, I'm billed as the Project Manager.  Personally, I don't consider myself the Project Manager.  One of the earliest choices I made was to delegate authority to individuals who had a better understanding of the task at hand.

In many ways, this wasn't a wholly beneficial decision, as there were many instances where I, or the professor, had to step in and reconfigure the schedule for a specific part of the project.  That being said, I still consider this a positive in Prisma's production, because it prevented bottle necks from occurring.

What We Got Wrong

Production Management
We started Prisma not really knowing much about game production.  While the entire team had taken several classes on game art and design, nothing could have prepared us for the monumental effort that was producing a fully featured game within a year.  Because of this, we messed up in a few areas.

For one, the only management software that I used was a spreadsheet in Google Drive.  While this spreadsheet was helpful, it simply wasn't a valid substitute.  For future projects, I'm looking into Trello, or at least something comparable to it.

Art Production
To me, the biggest production issue was generating and placing art assets.  Early on, we studied games, such as Kirby's Return to Dreamland, and attempted to deconstruct their production process.  I feel that this wasn't the wisest decision on our part, because we ended up using somebody else's solution to a problem that we did not have.  Instead, we should have analyzed and predicted the problems that we would have faced, and formulated a pipe line that would work for this project, and only this project.

Internal Communication of Ideas
In many ways, the art production was impeded by a lack of communication between the design and art teams.  That's not to say that we didn't exchange ideas -- because we certainly did -- but we didn't exchange enough.  We relegated most of the discussion to scrum meetings, which are very short and not conducive to exchanging ideas.  For future projects, I hope to have the team regularly play the game together as soon as possible.  This means that once designers have whiteboxed a few levels and the core mechanic is implemented in engine, the art and design teams should play the game together and write an asset list together.

What We're Doing Next
First of all, we're going to take a well-deserved break.

After that, we're going to determine how to move Prisma forward.  The general sentiment is that Prisma has the potential to be much more than just a student project, and so we want to try to bring it to its logical conclusion.

To do so, we plan to refine Prisma's core mechanics, polish the art direction, and improve on the cutscenes.  After watching tons of playtesters and amassing quite a bit of feedback, we've realized that Prisma has a few flaws in its design, so we want to go back and work some of it over.  Naturally, I'll be sure to discuss all of these changes in a future blog post.

We're also considering a crowdfunding campaign.  This would act more as a test to see if the market would want Prisma as an actual product.

Simply put, Prisma in its current form is a complete student work, and is a part of every team member's portfolio.  Now that we do not have a deadline hanging above our heads, we're going to experiment to see what makes sense for the project.  Honestly, it could go either way.

For me, personally, I have a few different opportunities right now, which I'll be pursuing alongside Prisma over the coming months.  I have one more year of SCAD left as well, and I plan to help out the next batch of senior studio students.  Exciting times are ahead.


What's Going to Happen to This Blog

Hopefully nothing.  I plan to continue posting about my various game development adventures.  I do want to get away from writing exclusively about Prisma.  I'm thinking about expanding into commentary on various controversies within the industry, or maybe have some in depth analysis on some of the games I've been playing.


Either way, I plan to maintain a blog in some form.  I'm strongly considering moving over to my own domain (kylejbolton.com) and using a CMS.  Nothing's really set in stone right now.  Because of that, I've never felt more relaxed.

Sunday, May 19, 2013

Prisma Has a Website


Over the weekend, I've been working on Prisma's web presence.  It's based off of Alex's designs.  Naturally, there's probably some bugs, because I don't have that much HTML and CSS experience.  Therefore, what better way to get a bug report than to put it out there for all to see?

I'll continue to work on the site over the next few weeks.  There's still a few features I want to add, including a team page and possibly even a new playtester hub.

You can access the page by clicking the image above or clicking here.