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.

Games for Fools - Mami Update

Wow – what a week!  Enemy distance handling, tile loading quality assurance, and a big fair to boot.  It is safe to say that some Mami work has been done!

What do I mean about “distance handling”?  The enemy spirit object that rests on the stage patrols a static location just fine, even with the screen scrolling, but when it comes to registering where the player is and the relation the character has to the object is a bit funky.  Over the last week, the other programmer and I learned a lot about Actionscript 3’s location functionality; our player’s position locally – player.x – and globally – player.truelocation.x – stays the same at a range of the screen.  The change is also skewed as that anything that is represented globally is double what happens locally.  To say the least, the enemy is having glitches on telling what the player’s location is.

The main programmer is gone for the weekend, so our project manager and I practiced good QA skills; we broke things.  After exiting the introductory level, it appears that a few of the objects of the intro remain in the next level.  After removing a few of the offending collisions, it became noticed that we start not at the start of the next level, but exactly at tile ‘n+1’, where n is the number of tiles prior to the level change the player encountered.  The solution: send the setup of the level an integer to compensate the offset position, placing the player in the correct tile.  Ta da!

Now, Sunday is April 1^st, All Fools Day.  This year is having the 2^nd annual All Fools Day Game Fair, where the Game Design professors nominate and sponsor various games being made or conceptualized here at the university.  With both Mami and Perpetuam Memoriam being nominated, I am well on my way to loving the heck out of this event – mass free game testing!  Mami will feel quite clean after this, and Perpetuam will get its first public appearance since Global GameJam 2012.

Other going-ons with Team Squaybies concerns moving finalized vector assets into the game and removing the lack-luster filler blocks.  My level layout is being placed into the primary level of play to give a dynamic sense of progression through the world.  Further, I do believe that certain animations and attacks are finishing themselves quite fine.  All in all, the work can be called progress.

I’m unsure of what will come in the next 2 weeks; Easter is going to most definitely be a jam in the flow of things getting done.  But, if this week and the pace we’ve been setting in both Team Squaybies and the Perpetuam Memoriam game is any indicator, the end of the spring semester is going to see 2 finished projects.  Woot!

Well, I had best get back to programming.  Enemies, platforms, and code-cleaning… Take care until the next update.

Puzzles! Prototypes! Play!

Can you guess what this is about yet?  Well, it has been awhile, but I promise you that I’ll be writing about Team Squaybies and Mami – my school group game project – more frequently.  So, as a start, here’s what I’ve been doing recently.

A few weeks ago our group leader brought on the next stage of Mami’s development in the form of having a spree of stories written for this sprint (if you aren’t catching the lingo, check the wiki) concerning puzzles and prototyping.  Stories from map implementation to death-trap rhythms are being pursued to test their fit within the game.  As the official QA lead, this has been my calling!

Last week saw me write-up and test a paper-pencil prototype for the possibility of adding a map a la Oddworld: Abe’s Odyssey, materials provided for by other group members.  The initial tests were promising, allowing me to formulate a general strategy for utilization, and a rule-set for future testing efforts.

Just today, a team member and I play-tested the rhythm sequences that would harm the player in-game from falling or flying objects.  At .5 seconds for falling, .5 for jump safety, we concluded that that timeframe would be a great start for any newb player trying the puzzle for the first time.  This was accomplished using only stopwatches and quick fingers; definitely a time-saver on a programmer-strapped team!

Well, there is of course more, but that would be taking away content from next week’s update.  Suffice to say that Mami is coming along nicely.  Take care, and stay tuned for more to come!