Jimmy Chattin - I make better games.
Showing posts with label puzzle. Show all posts
Showing posts with label puzzle. Show all posts

Monday, May 21, 2012

Vessel is a Game Unfulfilled

Steam is a great service for online gaming, and Vessel is one of the many demos that is available to try before making a purchase.  I’ve played this test of a game, and though unique elements are present, they can’t make-up for the hardship I felt in the demo.

To begin this whimsical platformer, the stage is set through a slow camera pan through a lab.  The scene shows pictures of your characters research into creating “fluros”; strange, fluid-based automatons that become the workers of the steam-punk world you live in.  This gallery clearly lays-out that these laborers revolutionized society, but something went wrong, thus depicting the current situation you find yourself in.

The story is put forward in a decent manner, but this is a comment on the first time seeing it.  The second and third times are overly repetitive, and the player has no way to get past them!  This distraction detached me from the world of Vessel when I just wanted to get back into the platforming and puzzles.

So, why did I play the demo three times?  Well, the first time was that the game trapped me in one of its puzzles with no way out.  Getting stuck in a closet is not a way to encourage trial-and-error testing of the puzzles in the game.  Therefore, being left between two inoperable doors, I had to restart.

The third play through comes from something deeper in the very foundation of Vessel.  Getting to a fluid puzzle area – the one that trapped me previously – caused the game to jitter then crash.  Forcing me a third time to play the game, I nearly had the title crash again; more fluid-based areas caused the game to distort and slow to a barely bearable pace.  I made it through that sequence after a few minutes, but my confidence in the programming design of Vessel is deeply shaken.

Now, when I was actually playing the demo, I had fun solving and manipulating the fluid-based puzzles.  Hot and cold fluids have unique effects, levers and machinery fit well in the steam-punk universe, and the “fluro” workers lend a creative element to problem solving.  However, the time I had getting to these places was greatly lengthened not just by the aforementioned unskippable cut scenes, but by long, drawn-out loading scenes.  I was not expecting such a drag from a 2D platform puzzle game!

Vessel’s demo was a quick one; that must be a saving grace.  Don’t get me wrong, for I did have fun with the simplicity of the visuals and the intriguing puzzles.  The downfall comes from lengthy time delays, poor design choices that punish players, and issues at the core of the program execution.  If I have judged this game wrongly, where the demo cannot convey some majesty of the actual Vessel release, please let me know.  But, when it comes to the first impression that Vessel’s designers decided to put forward, they either made a poor choice or worse, made a faulty experience.  Either way, I’d say take care in trying other games before approaching this title.

  • + Good setup of background, motivation, and story right from the beginning.
  • + Creative and engaging puzzles based around fluid motion and physics.
  • - Uncontrollable, unskippable cut scenes.
    • A fix: Add a simple button press to take the player straight to play.
  • - Puzzles that punish curious testing without redemption from each trial.
    • A fix: Leave room for a player to reset to some sort of checkpoint, or create limited, foolproof level layouts.
  • - The game crashes over its main mechanic of fluid use.
    • A fix: Properly check the quality assurance to the title, making adequate changes in how the game relates to itself and the machine it runs on.
  • - Long load times.
    • A fix: Better streamline the asset reliance the program makes on itself.

Saturday, May 12, 2012

The Long Life of Half Life


I’ve played Half Life 2 and its episodes, and now I know where it all comes from.  Half Life, in short, was quite engaging and a blast to play.  The fun, however, was all too familiar; familiar to even a fault.  That aside, I guess if a formula works, use it!

The game begins with a tour of Black Mesa, the research facility you, the fresh lab tech Gordon Freeman, works at.  This is a brilliant move on Valve’s part (the successful creators of Half Life).  Why?  It’s brilliant because the game lays out the premise of the entire story without so much as a word.  The tour is also great for setting-up familiar places that (surprise surprise) will become strangely perverse in short order.  This stellar level design leads the player along for the entirety of the game’s progression; needless to say, you won’t get bored.

When delving into the confines of Half Life’s world, the player is faced with both aspects of combat and puzzle solving.  The puzzles are all environmentally based, and provide a stark reminder that the facility you are in is one: falling apart; and two: Black Mesa is being invaded by freakish trans-dimensional aliens!  The thought challenges in levels are usually very straight-forward and easy to navigate by any individual, mixing up the “go here, do this” formula so apparent in modern games.  But, when issues are presented without much info to go on, some puzzles can be shear frustration, be it a timing issue, a previous action having to have been done, or falling to your death.

One thing that any player of Half Life will first notice is the uniqueness of every weapon.  Crowbars, rail guns, and nasty little critters all make an appearance, each having a specific capability unseen among other equipment.  These tools are given in a drip-bag fashion, allowing for the player to get to know each weapon well for whatever situation comes up.  The final cool thing is the way that the weapons are grouped together; pistols are together, heavy cannons stay next to each other,  deployable equipment is packed nicely away, etc.

Speaking of weapons, the things they’re used on share an amount of uniqueness.  Zombies are slow, the iconic headcrabs provide nasty ambushes, spec ops baddies are persistent, and the rest of the cast has a familiar silhouette for easy recognition of their mentality and capabilities.  That distinctive nature keeps encounters refreshing, also enabling a quick-reaction to finding the correct solution to any given engagement.

The journey to get out of Black Mesa is a grand journey, taking the player to the depths of dank tunnels, through secret labs, and past the guarded surface of the facility.  This voyage is enjoyable, don’t read me wrong, but it has been taken before.  Nearly all of the level design was carried over into Half Life 2, with barely a hair of change delivered to the player.  This lack of originality cannot be attributed to the first Half Life, but this rehash, fun as it is, cannot be forgiven of Valve.

All in all, Half Life is a fantastic experience for any lover of games.  Valve’s attention to illustrating a living, unique world with minute details and overall execution is like no other.  Puzzles and combat lend themselves to an experience you will never forget (and will see again if you care to pick-up Half Life 2, undeniably one of the best games ever made).  I can safely say that I had a great time with this title, and that if you decide to pick it up on Steam or elsewhere, it isn’t a bad decision!  Take care with your gaming until next time.

  • + Brilliant level design.
  • + Good introduction of a wide range of varied weapons.
  • + Iconic enemies that give the player excellent company.
  • + Decent puzzle application for the most part.
  • - Level design that is to be rehashed later in Half Life 2.
    • A fix:  Um… not really much to fix here; if it works, don’t fix it!
  • - Some puzzles lack the hints needed for an ease of being figured out, developing them into unneeded hassle.
    • A fix:  Add simple graphic text hints within the context of the area.

Friday, May 11, 2012

Into My Frying Pan - Personal Post Mortem

I’ve mentioned in my previous post that Mami is a good game, with a strong team, that did a superb job in the game projects course.  However, it could have been so much more, and I share that burden despite my work, or because of it.  For a summary of what I think I did well (or not), see the end of the article.

On Team Squaybies, I was titled as the QA Lead, allowing me plenty of room to delve and assist in every aspect of the game.  Through development, nothing lacked a bit of my touch.

In the beginning, early god-bosses and enemies were needed.  Team Squaybies brainstormed a breadth of designs and characters, and I directly assisted in making a few.  Using an industrial production process, the pieces were turned-out very quickly with decent variety.

To help secure the direction of the game, we had to illustrate what was wanted in Mami.  To do this, all of Team Squaybies contributed to the game design document, with me as chief editor (spelling, grammar, inconsistencies, etc.).  Taking it from there, my QA instincts took hold, and I had a number of outside individuals read through the premise of the game, and took changes they suggested or loved to the group, implementing them appropriately.  In anti-climactic fashion, the document was never touched again, but I bear it on myself for not iterating the five letter word of every project: S-C-O-P-E.

For most of the year, I ended-up doing little programming features and research to assist the work of the chief programmer.  Being as unfamiliar as I was with the ActionScript language, catching-up to the employed skills of my friend made the impact of my work fairly small.  Slow work and low impact features are my downside (though I know AS3 so much better now!).

However, other than the chief programmer, I was the only other team member to actively program within the game.  Making the necessary changes to effectively fix minor issues that arose sped production processes along.  With the research I conducted, enemy examples and coding parameters were found, and a shadow system was discovered that is in current use within Mami. So, with all that, those contributions can be a plus on my part.

Now, let’s cover some items of a more superficial nature.  In teamwork, many times I became short with other group mates, and that is inexcusable.  On attendance, the chief programmer and I have the best showing of the entire class!  Concerning work ethic, I would rate myself above the average, in that I did not waste work time Facebooking, perusing Imgur, or reading Reddit.  That, I would state, is possibly my best trait given to Team Squaybies.

Well, there’s my frying pan.  I make no claim to be unbiased, and really do welcome your input in the comments section.  For my failings, they were wrong, and I can only hope to never make the same mistakes again.  Concerning my achievements, I don’t think that aiming to do better is out of my scope.  Again, please comment what you think down below, and take care for my next post of Half Life.  See you then!

  • + Being there to benefit every section of the game.
  • + Designing and carrying-out a number of visual concepts of possible characters.
  • + Spear-heading needed quality assurance with industry-grade detail and procedure.
  • + Actively programming features in ActionScript and finding asset examples for implementation.
  • - Repeated failure to raise the “scope” flag enough.
    • A fix: Scope!  Set conservative deadlines, believe attainable goals, and work on details after the main design is satisfied.
  • - Slow, plodding programming work.
    • A fix: Know what engine will be used prior to entering the project to catch-up on code writing.
  • - At times, short with other team members.
    • A fix: Patience is a virtue.

Friday, May 4, 2012

Mami's Post Mortem - Mami Update


Wow.  What a year.  Mami has been through a lot these past few months.  It has seen people come and go, lore written and dismissed, art created and discarded, mechanics programmed and removed, and countless other iterations come across the project life-time.  There are some things Mami still needs, but there are so many more things that the game has accomplished.

Starting the academic year, there were a lot of decisions to be made.  What mechanics could be applied to the game?  How detailed is the story?  Levels?  Engine?  Art-sound-etc etc etc?  Some of the most important insights into what would later evolve the title came about in September, October, and November.

However, scope is the five letter word of the industry as far as I’ve experienced.  Thus, the time not spent on the programming and implementation backbone of Mami was too great when compared to what the industry uses now as a production process.  Those assets, though, do bolster an impressive library of material that clearly defines the world Team Squaybies created, and the assets are always there for future reference or use.

Referring back to implementation, that brings me to my next topic: skills that are needed in a game development team, and the life-span of those skills.  Throughout the year, we at Team Squaybies - an assemblage of technically nine individuals to six by year’s end - had a various assortment of skills to bring to the project.

What was desperately needed was more programmers.  The chief coder was a beast at AS3, but he’d been working with the language for a year previously in a professional setting; Team Squaybies’s project manager knew a little bit, but otherwise was regulated to very front-end manipulation; I myself know plenty of code, and picked-up the language of Adobe Flash quickly, but I was still not on-par with the primary programmer, mainly slowing down his progress if I tackled a problem alone.  Coding was important from start to very finish, and having more coders with a previous familiarity of the tool of choice is not a make-or-break situation for game development, but it sure darn well makes things more efficient!

Now, what about the art direction?  To start, we lost our audio skill at the turn of the calendar year, though he did do excellent work prior to his leaving.  Would more work have been required of him the second semester?  I can’t say.  I also can’t say if it was overly detrimental to the outcome of Mami, but it just shows that the pool of audio talent that the game projects groups have access to is quite slim.

Moving the art focus forward to what is more traditionally considered art, the visual concepting phase of the project was by far too long.  Some persons were doing over an hour to turn out one half-finished piece of concept – when put into the context of working being done in only two-hour working blocks three to four times a week, that is ridiculous.  I have good faith that anyone in a design studio would happen to agree.

Now, try combining the visual arts, level design, narrative brainstorming, and other miscellaneous fields outside of the implementation track (e.g. programming).  These fields far outweigh the number of people capable of bringing about a game, and within the game projects course here, last on the employ of a team for the entire year.  I may be horribly biased, but a great number of non-implementation individuals are needed at the start of game development; halfway through the development cycle, I could only see maybe one, two, or at most three persons of strong artistic intent.  Everyone else should have multiple skills, transferable between development teams!

Well, I’ve ranted enough.  Team Squaybies really pulled a good project together this year in the form of Mami.  The team was fairly solid.  It was a great time, I learned a lot, and will be taking the best of my new knowledge to help create a game I designed for next year.  But now, here’s to creating great gaming experiences, and taking care while doing it!  

Stay tuned for a possible update to my Mami adventures, where I go into the details of what I learned, what I did horribly, and what I believe to be good work on my part.  See you then.

P.S.  Please comment on my thoughts of the past year, the issues raised, your own experiences in teamwork and project development, or ask any questions you may have.  If I missed anything, let me know!

Friday, April 27, 2012

The Last Week - Mami Update


Next week is Finals Week.  Thursday’s final presentation of Mami will be the final showing of the game.  There is more work to do before then, but the grind to next week’s deadline goes on.

The project manager and I have been working together to ensure our levels work without incident; jumping from platforms to platforms, triggering puzzles, shifting into walls, attacking, and getting stuck in corners are just a few things we tried and edited in regards to what came up.  Anything that couldn’t be handled by the simple moving and resizing of collision boxes I recorded in a QA to-do spreadsheet for later.  If I may say so myself, it was good quality assurance!

Other work going on in Team Squaybies would have to be the finishing of giving visuals to the platform collision boxes.  Further, the final rendering of the player character animation has entered its final phase; it’s implementation happens later today.  Finally, the chief coder has been working on smoothing the corners of certain mechanics, allowing for appropriate player engagement.

Well, it’s been a good semester.  Let’s finish it strong!  Take care until next week, where I’ll be writing a “post mortem” of the whole project.  See you then.

Friday, April 20, 2012

Program All the Things - Mami Update


I’ve recently promised to provide some code samples from our work on Mami, and have been talking about it even longer than that.  So, without further ado, le program:



Let’s start with some puzzles.  Above is the triggering code for the puzzles, and below that is the platforming code that handles various collisions with specific blocks within a level that open doors/grant recognition for this, that, and the other thing.  To reset the platforms, a simple timer will be used.  Easy!


As you can see, the implementation of special “shards” is a bit sparse; their collection throughout a level would activate various bonuses, but creating and managing another array within the game is currently being put on the back-burner.  The question is really how we would like to do it, and again, the time to implement and debug.


The last of the puzzle sections we are using, the map is very straight-forward; if the player is in reach of a special node, allow them to activate it.  Once activated, move to a new frame to show a picture, remove player control (aside for a deactivation button), and revert back to the playing frame once they are done looking at the map.  Only bringing in the picture into the library is the thing left to do.



AI seems to be the most fickle thing currently in our design.  To translate changing XY coordinates between the tiles, the enemies, and the player is just making a mess of things.  The chief programmer and I managed to make good progress on it, but the buggy nature of the beast has caused us to comment-out everything past our “patrol” mode and the self-deletion function.  For a demonstration of what we have, that code should be satisfactory (for the most part).

What’s here is but a very small part of the code structure, but the work I put in to creating these chunks of code helps the game flow in a way such that Team Squaybies may just make our deadline in 2 weeks!  Speaking of deadlines, I’ll let you go until next time.  Take care in commenting and reading future posts; I’m currently grinding through Majesty 2 and the original Half-Life.  Those are … interesting games.

Friday, April 13, 2012

Code in Abundance - Mami Update


With only 2 weeks left before Mami hits the deadline for presentation, the code is coming together, the visual products are being put into place, and the entirety of the project is coming to a head.  Despite setbacks, possibly losing some teammates, and some side project work, Mami is looking forward to its release date!

When code runs smoothly, it is a beautiful thing; when it’s code you’ve made, it’s personally satisfying.  This week saw the chief coder and I implementing the final programs for the three puzzle types we’ve designed: a displayable map, a special-item collection system, and a specific platform combination puzzle dealing with jumping onto certain locations at certain times.  Don’t worry; I’ll be sure to start posting some code snippets.

I hate to leave you so soon, but code not associated with Team Squaybies must be written!  Please comment  if you have any thoughts or questions; I’d love to answer!  Take care until next time.