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

Friday, May 25, 2012

Dig-N-Rig is Worth Digging Up

Me neither.  Dig-N-Rig is a game straight out of the Digipen Institute, where “resource management with creative building” are the key fundamentals.  Have you played a game like Minecraft?  This review may sound familiar.
  • + Colorful and delightful 8-bit visuals.
  • + Having tools for every occasion.
  • + Quick reward schedule of getting minerals and items from those materials.
  • + Compulsive play.
  • + Space!*
  • - Poorly executed tutorial.
    • A fix: Give aesthetic care to the delivery of information, or edit the knowledge into a more efficient form.
  • - Unrestrained upgrade system, upsetting game balance.
    • A fix: Set scales ensuring proper capping of abilities and/or escalation of environment hazards.

Dig-N-Rig has a slippery start.  The first five to ten minutes of the game consist of paging through tutorial slide after tutorial slide.  This wouldn’t be half-bad if the information wasn’t a jumble of hard-to-read text randomly popping up everywhere on the screen.  I’m still not sure I managed to read them all, as tutorial textboxes easily blend with the pixelated background.  Don’t take from this that the visuals are unappealing; they’re not.  Very cool, in fact, for this 8-bit title!

Getting through the tutorial, the game does not try to burden the player with a convoluted narrative or crazy objective.  You are digging down to the center of the Earth for scientific study and exploration.  There.  Past that, go down, mining and building what you please with the boat-load of material you uncover behind nearly every bit of rock so those materials can be used to build even more cool stuff.  Repeat on the next play-through.

The player has a wealth of tools that aid in navigating down to the core.  Drills cut terrain like a knife through butter, but only if they are designed for a specific piece of ground (i.e. dirt drills manage dirt, rock drills blast rock, etc.).  These devices are fun to play with, but I found myself coming back to the rock drill time and again, for it doesn’t stop when it hits a barrier, only meagerly slowing down.  And bombs?  They’re good on the first play-through, but after a few upgrades to the rocket-propelled bazooka bullet, firing that beast makes all other blasting object obsolete.

Despite anything that I have said here that may be a strike against Dig-N-Rig, this game is compulsive.  You can lose hours of an evening scraping-up every last colorful jewel between your base of operations and the end.  You can finish in a fairly straight-forward fashion, and you become overpowered within a few upgrades, but again and again you’ll find yourself carving a complex path down into Earth’s depths.

Dig-N-Rig has holes (see what I did there?), needs a bit more content, and just feels like a game that almost was.  Looking at it from the point of it being a student project, however, this game is a blast.  It’s not a title to kill an entire day, but if viewed as a prototype or a proof-of-concept, Dig-N-Rig does just fine.  Now, what’s my suggestion?  Give this game a play.  Take care to checkout the gallery over at Digipen, too; you won’t be disappointed!

* Hint.

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.

Thursday, May 17, 2012

Pay the Dues to Majesty 2


I need to thank a friend of mine for going to the Game Developers Conference.  From his trip, I was able to snag some of his swag in the form of a Majesty 2 key.  Let me start by saying I’ve never played anything like Majesty 2, and rarely anything as difficult.

The game takes itself really light-heartedly.  Very quickly a player will receive funny quips and witty writing for everything from dialogue to loading screens.  Keeping the humor refreshed throughout play, Majesty 2 delivers a balance of easy attitude to counter the intensity of play.

Real-time strategy games are usually characterized by being plagued with micromanagement.  Unique, self-reliant AI of individual units that negates detailed supervision is both a blessing and a curse.  Your heroes can handle tasks by themselves by healing, fighting, and retreating fairly well.  However, when you are in a tight spot, or require something to be done immediately, your troops can be a bit fickle, getting either themselves or your base killed in pitched battle.

Further discussing units brings-up the point that some units are just not useful.  A hero may just be too expensive, or too weak, or not capable enough until a given level to provide the right amount of support to your army.  I found myself repeatedly going back to a 4-class system of knights, rangers, clerics, and dwarves; there are 13 classes in all.  That amount of excess that just doesn’t seem to have much of a place in the game makes the game appear to have not been completely thought-out.

The base your army is hired to protect grows.  Majesty 2 does an excellent job making your settlement seem alive, as all non-essential buildings pop-up around the fortress you make.  This leads to not base being the same another time through, while defenses are also needing to be dynamic as pesky rat-spewing sewers are randomly placed as well.

Time is relative, and Majesty 2 lives this to the fullest.  Full control of how fast the game flows is unimaginably useful.  Speed the construction of buildings or a drawn-out battle, or slow the chronometer to handle full-on assaults in the fantasy world.

Speaking of time, most missions won’t give you enough of it when the baddies come calling.  The game is just brutal.  Enemies never stop coming, and mass attacks can leave your defenses beaten and broken, with your heroes strewn about the battlefield.  Some of the bosses are also sincerely unreal; one-shot kills blow through even the toughest of troopers.  Because of the intensity of fighting can be so much, reliance on slowing game-time and much trial-and-error is a must; even then, the best preparations may not be enough, leaving luck your only friend/enemy.

I had fun playing Majesty 2.  The easy nature of the title, unique AI management, and living worlds create an experience no other game in recent memory delivers.  However, even those prepared for a challenge will find that the computer has an unfair advantage, and relatively useless hero classes don’t help.  So, I guess I can only leave you, reader, with a warning with this title: go into Majesty 2 expecting a good delivery and an experience not had before, but do not get too frustrated at what the game may pull on you.  With that, take care, and farewell!

  • + The funny quips balance the intensity of play.
  • + Micromanagement of units is a non-issue due to self-reliant AI.
  • + Time control of gameplay.
  • + Dynamic settlement growth creates a living base.
  • - Some heroes are just not useful.
    • A fix: Run-though balance issues such that all characters balance and can be effective if used.
  • - The game is hard in an unfair way.
    • A fix: Rely less on cheap mobs and lots of hit-points, and more on refined AI strategy.

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, February 24, 2012

A Level Design, Anyone? - Mami Update


Welcome back to another checkup on the Mami game project!

To start with myself, I’ve been working on the layout of the first ‘real’ (ethereal?) level of the game.  This post-introductory environment is very important to Mami’s design, as it is likely to be the final displayable part completed before the end-of-the-year product lock and crunch.  Therefore, I may have been a bit nit-picky on the details of the rough-drafts, but those things need to be considered.  After review, a wish-list of features was finalized to be included in level 1, regardless of the gritty details.

Other members of the team have been keeping things going as well.  Vector illustrations are being finalized for the protagonist, background assets are nearly complete, animations are under refinement, and certain tutorial/narrative assets have been written.  Team Squaybies is trying to keep busy!

In regards to stories, we’ve hit our average number of completed stories for the week and surpassed it; sounds like an overall productive week!  Now, let’s see if we can keep it up next week (especially with Spring Break the week after).  Take care until later next week to see any new progress made.

Friday, December 2, 2011

7 Matt Weise - Philosophy in Games

Demon's Souls, Horror, and Holistic Design

Answers and their Points to a Set of Questions
·         Setting - very low fancy
o   Monte Python-esc portrayal of the Dark Ages
o   Only humans and monsters - very obvious
o   Very Gothic and authentically Gothic in a historical way
o   Premise put into modern day setting could not convince it was not horror
o   Silent Hill happening to an entire country
o   Describe and define what the haunting is
·         Integrated design - Demon's Souls does it best
o   Are rules different from fiction to the game? - NO!
§  e.g. Phoenix down on Aeris?
·         Shot to pieces in real life; hide and regenerate health in game
o   Coherent rules
o   Metaphysics and spiritual function is consistent in story and gameplay
o   How much power do you need?  How much are you going to take? - Corruption question
o   YOU ARE A BAD PERSON FOR BEEFING UP TO DESTROY OTHER PLAYERS
o   hitting someone with your weapon will make them very mad - > just like real life; will not hold your hand
o   the game makes you think of what a power fantasy is
§  horror is a disempowering fantasy
o   Super heroes are American
§  be stronger in an unfair fight
o   It's hard because a gamer must use common sense, not gamer sense
§  we expect a game to make us feel powerful, not us to make us feel powerful
·         Demon's Souls fiction is intermeshed into the game -> change fiction, change game
o   Humanity - "Souls are what makes humans human.  This also makes you human.  What's the difference?"
§  Dark Souls is full of philosophical questions
§  requires interpretation of the gameplay
o   The purpose of a game system is to destroy itself (game world destroying itself)
o   There is a massive collection of negative space
·         Rationalization of being a killer
o   Am I good for protecting my alliances?  Am I bad for killing innocents threatening my alliances?
o   Pay to have sins removed -> ticked NPCs love you again

6 Jacob Butcher - What is Player

All horror games have real stories
All horror games focus on eliciting the effect of fright
All horror games are interactive stories

Who Died?
·         YOU DIED
·         The avatar is the one who died, but it instills a connection that the player is avatar
·         Use "you" to refer to the character in the game as the player
·         Mix referring to "you" and the character specifically - creates confusion

Verbs
·         What can the player do?
·         Authenticity
o   create the illusion of being real
·         Evolution of verbiage:
o   Select item, USE               ->            Select item, ROTATE CONTROLLER

Contextualization
·         something doesn't have to exist to seem to fit into an environment

Tuesday, November 29, 2011

4 Chris Pruett - What Makes Horror

Eye of Newt, Toe of Frog: Key Ingredients of Successful Horror Games

Theory: Horror games elicit emotion
·         Look at mechanics that can be used elsewhere to make emotion other than fear.
·         What makes horror games scary?

Common Traits of Scare
·         Vulnerable protagonist
o   Could be ordinary or inferior
o   Antagonists make short work of characters
o   Characters feel "real"
·         Information does not make sense
o   Clues surround imagination space
§  Clues come through narrative
o   Misinformation leads to twists in plot
o   Culture shock leads to preconceived notions of how things work that don't work
·         Level Design
o   Pattern of decent
§  Once dropping down, can't return (e.g. holes)
o   Recursion - passing through the same place, but the place changes through time
§  Recursion is not used much in Western games (more linear)
·         Cinematography / sound design
o   Control how the player sees the world
§  Cameras build tension and force shock
§  See "Fatal Frame 2"
o   Sounds build tension and leaves clues to the world
§  Sound may be more important than the visuals (see "Silent Hill" "Dead Sapce")
·         Difficulty
o   Common to all horror games
o   Running out of consumables (ammo, health, saves)

UBER TRAIT: LOSS OF CONTROL
·         A horror game is scary if it makes you feel you are not in control
·         Instill no confidence to resolve the current situation
o   Vulnerable protagonists - you can't go in and protect the character
o   Confusion - you don't feel grounded in a concrete set of rules
o   Descent - removing you from a place that is safe; narrowing of options
o   Recursion - understanding a place then having that place change removes confidence
o   Cinema - no single character is known as the protagonists until the end
§  e.g. Alien
o   Difficulty - unique to games
§  Makes or breaks a good horror games
·         The body reacts to sex and aggression identically
·         Stimulus - perception:
o   To stimulus to general autonomic arousal to particular emotion experienced to interpretation
o   To context to particular emotion experienced to interpretation
·         A hard game gives stimulus to increase personal physical state w/o context
§  Scary monsters, places, etc. can be mislabeled as fear because of difficulty

GAMES THAT FAIL
·         Dead Space
-      not a lot of descent and recursion
-      protagonist is a "bad ass"
-      difficulty is not inherent
+     sound and cinema

·         Alan Wake
-      strong protagonist (the gun)
-      not put under pressure
+     lots of negative space

·         Dream 2
-      only one spot to go to
-      no physical elevation change
-      flat journey
-      confusing story for being a confusing story
-      lack of clues forming a negative space
-      fights are not hard

·         Clocktower 3
-      character cannot easily die
-      very little difficulty
-      bosses have nothing to do with the game
-      story is nonsensical
+     vulnerable protagonist
+     plenty of recursion

·         Call of Cthulhu
-      core mechanics are broken
-      cannot select things due to camera
+     early game is hard

SUPER TERRIBLE
·         X-Files
-      squandered license
-      did not tie together aspects of copied horror games
+     fixed cameras
+     limited inventory

·         Cold Fear
-      mechanics are broken
-      ammo loss halts progress
-      saves are random and not on demand
+     structured plot

·         Obscure 2
-      characters are unbelievable
-      offensive game script
+     good art and cinema
+     innovative 2 player mode

·         The Ring
-      WHATEVER THEY DO HERE IS BAD
-      ONE OF THE WORST GAMES EVER

Play These:
·         Silent Hill Shattered Memories
·         Siren
·         Hellnight


Answers to Questions
·         Play with a friend to overcome too much fear and increase fun output when gaming.
·         Pick a game that works for you if you find it hard to play horror games.
o   e.g. don't pick zombies if you're super scared of zombies