Before Episode IV

Prologue

A long time ago, in a galaxy far, far away, a civil war rages.
“We should go,” Maria said.  “The plans are compiled, and we don’t know who could have been listening.”
“Do you think Imperials would peep all the way out here?”  Kyle asked, rising from a console.
Maria closed out of the last few glowing screens.  She was middle-aged, still in a prime though aged with years of subversion.  “I’m not talking about their tech; they know things they have no business to.”
“Rumors are rumors,” Kyle said, shaking his head.  “You always bring that up.  There’s no proof that a scanner can detect these Confederate channels, saying the Whites have that magic.  My mum said the Force -”
“Shut up about that!  How’d she get caught-up again?  ‘Didn’t see it coming’, was it?  Back before your stint with the Empire?”  Maria didn’t usually get this venomous.  Carrying data about the most dangerous weapon to the galaxy, one that a fleet would very likely die for, put her on edge.  “The Empire fought with the Force in the Wars, whatever the history holos say.”
Kyle opened the door without a word, a hint of a frown being taken into the hall.  He wished his mum hadn’t been brought up at all.  “As you said, we have a long flight ahead of us.  Tantive won’t wait long.”
“Ya.”  Maria, having spent more than tenfold the time than Kyle opposing the Empire, knew how quickly appointments could fall apart.  And how quickly a spy for the Whites could get word out to a communication probe.  “The encryption took so long, it should have bought us a few hours.  At least the Bothans automated the processes before they bugged-out.”
Kyle only shrugged.  Time serving in the Stormtrooper Corp exposed him to much better technology than even the best Alliance command posts he’d seen; this backwater listening post being far worse.  He’d seen reports on Bothans, too; easy enough to spot with the fur, but still-secret personal cloaking that beat even Imperial detection allowed them uncontested stealth within Imperial holdings - well, most of the time.
He wasn’t much for intuition, but he was uneasy - so was everyone else in the corridor which they passed.  Something was different this time around.  A harsh year with the Rebel Alliance saw round after round of furious flight from fort after fort followed by soul-crushing periods of boredom.  Now, post weeks of waiting with secrets few trusted him to have, the presence of the schematics acted like a malicious talisman from Maria’s Force stories.  The Bothan discovery and subsequent rout made the situation want for at least a bare minimum of neutral news, too.
But that wasn't something to be shared with this coconspirator.
Maria had earned her place with the Rebellion.  She, a new land-trader, had seen the end of the Clone Wars only to have an Imperial task force ‘render’ the major cities of her world, one that had been on the wrong side of the galactic conflict.  Salt-and-pepper close-cut hair, dark skin, and grey eyes, her withering stare did less damage than her veined hands - at least to the throats of a dozen troopers on her homeworld, tucked away in their barrack bunks.  Had it been known that a whole hemisphere would be bombarded from space, six million lives may not have been worth a fist-full.
Seeing too many friends die had branded her as very no-nonsense.  Maria’s oft preached belief that the enemy had access to the Force was the only unevidenced mindset Kyle thought her to have.
This asteroid post from the Clone Wars was too small, too poorly equipped with anything but the necessities, to sport a turbolift.  Stopping at the cross-station ladder well, hand on a rung, Maria turned to Kyle.  “Just watch it getting out of here - assurances that-”
She was cut off with a boom.  Lights blanked-out to be replaced by red strobes and a pitiful electric wail.
The gravity went out too, saving Kyle from cracking his face into the wall.
“Slag it!” Kyle shouted.  Gravity returned long enough for Kyle to barely get his feet before another shudder hit the station.  Maria was already up the well, yelling down at him.
“Kyle!  Get going now!”  Maria’s face disappeared as Kyle raced up after her.
“Imperial forces have dropped out directly in our space.  Proceed to evacuate,” echoed the loudspeakers.  “Repeat, Imperial f-”
Kyle cursed as he chipped a tooth when another quake hit the small asteroid.  Launching himself down the weightless hall, he barely dodged Warren, the atmosphere quality tech, floating by with his head at a wrong angle.
Loosened paneling vibrated in rhythm with the thumping surface guns; guns too small for any military-grade shielding.  Dust mixed with the escaping smoke of blown electrical routing.
“Maria!”  Kyle couldn’t find the evacuation strip in the flickered red light.  Looking for the right passageway, he slowed his momentum along protruding handholds.
Two station personnel careened into the hall at the far end.  They were mouthing something Kyle couldn’t make out over the whine of alarms.  What he did hear was screaming - of man or metal, was a difference without distinction - as a fireball ripped the far corridor asunder, vaporizing the other evacuees before emergency seals slammed together between him and the flames.
Stunned, a grip along Kyle’s ankle wrenched him through a small accessway just as the locks further on began hissing atmosphere.
“Idiot!”  Maria threw Kyle down the hole.  “Go go go!”
They pawed over rungs and floating debris into a sub-corridor.  Flying by, Maria pulled through their ship’s docking port, heading straight to the cockpit.  Kyle closed the hatch, strapping in next to Maria.
Keying in the cold-start sequence, their ship vented propulsion directly onto the asteroid’s surface, pulling charging cables in their wake.  Charging out of the hidden rock cleft, hunks of planet-forming stuff rolled in front of them, rushed past them.  A boom rocked the ship’s shields which squealed in protest.
“Readings fore and aft - I think they’re TIEs.  Eighty-percent on the Hyperdrive.”  Maria banked through the still expanding cloud of detritus of the Alliance station.
Through the cockpit window, a green streak annihilated an asteroid dead ahead.  As Maria twisted to avoid the majority of rocklets, Kyle punched-in the final coordinates for the Hyperdrive system.  Chancing a glance, he switched to the rear camera.  A new layer of cold sweat beaded on his forehead.
Glowing bone-white, the colossal Star Destroyer of the Empire was as keen as a dagger against the blackness of space, smaller escort craft hugging its flanks like flies on a carcass.  Even at their distance, Kyle could make out the Star Destroyer’s rows and rows of mounded turrets that could burn away a planet’s crust in mere hours.  Green sparks twinkled over its surface.
“Incoming!”  Kyle furiously typed in the counter-frequencies for high-energy deflection.  He knew it wouldn’t be enough to handle a direct impact, but he figured there was very little else that could be done.
An eye-searing explosion of green light filled the cabin.  The ship, tossed through space like a toy, narrowly missed skyscraper-sized rocks.  Every warning alarm the ship possessed deafened the screams of the engines attempting to straighten-out.
Maria, gasping through tearing eyes, righted the craft.  “One hundred-percent,” she wheezed, slapping the Hyperdrive engage switch.
As the universe began to vanish into a tunnel of light, Kyle noticed the blood filling the cockpit.

Author's note: I've been quite busy at work, but nothing is ready to be shared code-wise.  At home, there's been more of a creative expression - one part, being a rewriting of Star Wars Episode IV's original screenplay and novelizing that.  This is a part of that effort needing to get out before too many people see Rogue One!  (Star Wars and all fictional content relating to that property is not owned by me.)

It's Raining New Content: Rapid Test Iterations

(Games of Taste - Notes from a GDC 2013 session.)


Session presenter: Benjamin Seifert ( QA Lead - Riot Games )


Image from Riot Games Twitter account.
  • Look for analysts, not "testers".
  • Quality Assurance must be ready to commit no matter the project.
  • QA pick-a-path strategy for development: Subject Matter Expert (SME), People Management, and Project Management.
    • QA should be capable to pick-up on any of these skills.
  • Automated testing will catch things such as FPS drops; use it often.
  • Test things to see if it is fun for players (automation isn't everything).
  • Feedback playtesting comes in the forms of company group-play, intra-team play, and inter-team play.
  • “Is the cool new spider monster engaging?” - A verbatim question on the League of Legends Twisted Treeline map's content
  • QA starts by giving feedback on character concepts at Riot.
  • Ongoing challenges with Rapid Test Iteration: Continual training and innovation along with a lack of documentation.


Final Thoughts


  • Strive to reach a 0-bug build.
  • ‘Pain Score’: Each bug has this; if the score of a bug in a build is low enough, a build is released.
  • Content is the lifeblood of LoL.

Find more sessions like this at the GDC Vault.

Philosophy on Design Progression and Balance - Railgun



Image from Railgun Twitter page.
(This post was first drafted and published here.  Updated and reposted with permission.)

I'm working as the associate Game Designer on Railgun, an action shooter for Windows PC, built using Lua scripting and Blueprint-like Flow in Autodesk Stingray.  Levels and some of the gameplay systems are my forte.

Here's how I go about designing things:

Bottom-Up Balance

Image from Battle.Net.
Companies such as Blizzard typically start their design balancing from the bottom-up.  Starcraft was made by first balancing the starting worker and warrior characters: Terran Marines, Zerg Zerglings, and Protoss Zealots are fine-tuned with each other before other units hit development.

I apply similar principles to the evaluation of Railgun's systems in these ways:

  1. If the base weapon and unit are not fun, we have a problem.
  2. If a new weapon or ability isn't fun with the base unit, we have a problem.
  3. If a new unit isn't fun with the base weapon, we have a problem.
These tenets make it easy to develop scenarios for different aspects of the game.  Though there can be exceptions (after close analysis), generally removing ambiguity simplifies the testing process and the communication that needs to happen with other members of the team (i.e. explaining design philosophy).

100 of a unit, the weapon choice for the player, and leaving everything else the same further allows for standard algorithms to be generated in predicting the outcomes of play (more on this below).  Repeated tests can refine prediction variables, but they get designers working with something decently accurate to the final outcome quickly.

Copy-Pasta Templates

Railgun_Autodesk_Flow
Image from RailgunGame.com.
Dictating parameters in a way that can be quickly replicated is a (glorious) feature of Visual Scripting, something Stingray and the more well-known Unreal Engine 4 take to heart.  Each node exposes only the necessary variables needed for design - K.I.S.S. and YAGNI reduce option-overload for non-designers, designers, and even the original background-code developer of the node.

After overcoming the psychologically debilitating selection of choices in Flow, I increase the speed of level generation by copying-and-pasting more complex code structures that only require first-time setup.  Time is then only required to tweak parameters for a given level to fit my progression modeling.

Not Designing in the Dark


Artists and writers often face detriment when it comes to the blank space of a page.  The same happens to a designer facing an empty level: What goes where?  Is it too tough?  How many rewards is the player going to get?  Does a story fit here?  Should it?

That's where abstract prediction algorithms come in.

At the earliest opportunity, get a visual representation of the game over time/space.  Even a back-of-the-envelope sketch of how difficulty, progress, and other measurable aspects guides the design process without doubt as to if the designer is going beyond their means.  This will guide design throughout the product lifecycle, projecting expected outcomes once the game gets to players.

It's important to prototype what is going on in-game before diving into the editor to see how things look on a spreadsheet (stereotypical friend of the designer).  Paper prototyping (or putting in ready-made assets into a blank, digital level) delivers what the base game could feel like, thereby outlining a point about which to escalate in difficulty.

Railgun-SpeedVSPoints-Chart
Image from RailgunGame.com.

As for starting to put in units and objects into a level, a general rule-of-thumb is to keep the first few minutes of the game educational (AKA the tutorial).  I involve one, at most two opponent types (these can be puzzles or similar obstacles in other genres) with enough change in the space of the level to encourage using nearly all the controls available to the player.

In 8 short steps:
  1. Paper-prototype game timeline/progression.
  2. Develop prediction algorithm.
    1. Compile game telemetry data to determine trends.
    2. Play the base set (unit, weapon, etc.) of the game repeatedly, plugging in the aggregate data (deaths, points, play time, etc.) into a tool such as Google Sheets, and deriving a value from that.
  3. Create basic first level.
  4. Apply prediction algorithm.
  5. Repeat processes three and four (approximately) to game design completion.
    1. By "completion", this means that there's content in every level, every unit/weapon has been implemented in code.
  6. Play the game; refine the algorithm's parameters, unit stats, and level design based on the firsthand experience.
  7. Get others play the game; observe performance, ask what players don't like, and never blatantly implement a solution offered by an outside party.
    1. Solutions to problems is the role of the game makers; players also tend to be biased towards fixes that benefit their style of play.
  8. Repeat steps six and seven to and through launch.

Image from Railgun Twitter page.

Conclusion

With simple rules and graphical projections to guide development, putting together levels and gameplay systems can be significantly sped-up while also decreasing the tweaks needed to balance the experience.  Railgun is one case study where this is working to great effect.

Look for more news from Railgun soon.  Check in again when new programs, designs, and insights are released here on Make Better Games!

Multiplayer Learning with Banjo-Tooie

(Games of Taste - Comments from late '12 after varied game competition.)



Banjo-Tooie Multiplayer

Image from Banjo-Kazooi Wiki.

  • + Unique library of weapons to use.
  • + Distinct character features to fit multiple play styles.
  • - Useless melee ability.
    • A fix: Decrease cool-down times in attacking while increasing the effective range of the attack.
  • - Unintuitive effects from weapons.
    • A fix: Define all the effects of an attack in the first pull of the trigger.
  • - Clumsy controls in aiming and movement.
    • A fix: Keep sensitivity of aiming at a moderate scale, while only keeping movement on one control (not both the directional pad and analog stick); don’t use inverse controls by default.
  • - Level design is absent - like a cake missing something sweet.
    • A fix: Make levels have high and low areas, while also placing weapons in locations that naturally draw players together.


This past weekend was another Olympic LAN party.  A few games were played, but I felt Banjo-Tooie’s multiplayer needed special mention.  As you can see by the list above, it was… unimpressive.

The game provides a unique library of weapons to use.  Mines, bombs, rockets, and machine gun rounds are all in the form of eggs shot out of a bird.  Special, right?  It is, but all for the wrong reasons.  Mines explode when placed anywhere near another mine, machine guns do zilch, and the difference between higher-damage rounds can’t be told just looking at them.

Speaking of weapons, the melee would be better if it didn’t exist.  When the melee button is hit, the in-game character goes into a dreadfully long animation to do essentially nothing.  That time makes the player a sitting-duck, readying them for cheap-shots in multiplayer matches.  Attacking hand-to-hand is a death wish.

Image from Wikipedia.
There is a fun set of familiar Banjo game characters.  Each one is either fast, average, or slow in movement.  However, the controls make every character feel like they are either antique tanks or sliding on a greased floor.  Turning to aim at an opponent is nigh futile; the prevailing strategy is to shoot like a madman in the general direction of foes.  Maybe then a hit will be landed, but it won’t make up for very touchy controls.

Finally, multiplayer levels lack a lot of what modern games take for granted.  Modern games have elevation levels, ‘safe’ and ‘prospect’ places, and flow to direct players into confrontation.  Banjo-Tooie misses these things by a mile.  To summarize, encounters are random, and players can easily get lost in the cramped depths of the multiplayer arena.

In essence, Banjo-Tooie is a game to learn from.  Being a spearhead of 3D gaming, there are both good things, and terrible things, in the game’s multiplayer design.  Good differences are present in character traits and weapons, but poor weapon instruction, excruciating controls, and no level design leave the game lacking.  May we all learn from Banjo-Tooie’s multiplayer to help make better games in the future!

Windows Insight App

Summary

The Windows built-in Task Manager program is good.  It's my go-to when needed to verify performance, garner information about a program, or kill a pesky process.  At times, it doesn't do enough.

To cover the bases and add the deep-dive functionality that Task Manager lacks, there's now this application:

Screenshot of the Insight App, taken by itself.
Windows Insight App - a program designed to deliver user manipulation and performance data on a targeted process.

Here's how it works:

  • On launch, the program finds all processes running on the computer, removing background apps that are more low-level.
  • From the list of running processes, clicking the name of the process will populate the name and computer title of the program, further populating other data fields on the Main and Diagnostics tabs.
  • Resolution can be changed, screenshots taken, and unlisted (background) processes manually entered.
As it's yet to be optimized and there are a number of features I'd like to add, the program's not yet ready for download.  It'll be up on my GitHub with a link updated here when publicly available.

Considerations / Specs


The Windows Insight App (WIA from here) is made as a Windows Presentation Foundation (WPF) program in C# utilizing the Model-View-View Model (MVVM) framework.

A positive in the development of WIA is how much control over diagnostic information can be given:

A few data-points about a program and the system it's running on.

A current negative aspect about the program is that it checks target processes repeatedly, which can snag a few MB of RAM, more than I'm comfortable with.  Additionally, the program has fallen into the trap of using Object Oriented Programming classes as merely namespace controls (therefore, no longer resembling the original OOP).

Future

Additional options and exposing diagnostic features (read: checkboxes) to users are planned TODOs.  Further, allowing users to change more aspects of their target process and the WIA itself is coming.

In short, optimize and scale.  Get the project's source up on GitHub.  I'll likely stay away from a complete refactor (something I plan to do repeatedly with another tool, Turn Timer), but may come back to clean-up the many redundant classes and re-apply OOP methodologies.

Check in again when new programs, designs, and insights are released here on Make Better Games!

IGDA Nanocon '12 Notes - The Lens of Truth

(Games of Taste - Notes from Nanocon '12.)


The Lens of Truth: Real World Adaptive Level Design


Speakers: Chris Totten (Art Director E4 Software) and Josh Lynsen (Creator of StreetPass Network)

How did we get here?


                How Chris got here:
    • Architecture Masters.
    • Self education in Blender.
    • Teaching on game development.
    • Writing on game development.
    • Doing game development.
    • Advice: Be self-motivated.  Put the time in.  It will work for you if you keep your head down and hit the grind-stone.

                How Josh got here:

    • Took the skill in his day job and applied it to what he wanted to do in game making.
    • Does things that apply to a part of game making.

Discussion


Use virtual clues for real-life treasure.
How to deal with structures that already exist
                Use Urbanism
                                - Large spaces can keep people away from each-other
                                - Paths, districts, nodes, landmarks allow for meeting
                Connectivity
                                - Cell phones/internet create a damaging interaction issue

Adaptive Game Reuse - take a game and re-center it around a place
                1. Games that enhance
                                - Simple mechanics to real-world situation
                                - Ex: item finding to explore locations
                                - Ex: virtual art/characters in real locations
                2. Games that pervade
                                - Events can only be executed in specific locations
                                - Going from point A to B affects the virtual world
                                - Ex: passing someone in life gives virtual goods/action
                3. Games that rehabilitate
                                - Jane Megonigle
                                                - Works on games that makes the world better
                                                - Gamify basic actions in a positive way
                                                - Ex: Tombstone Hold'emCruel to be Kind
                                - Gamifying a common feature/location

Chris and Josh: Creating a ‘Hometown social game’



  1. Goals
    • Revisit hometown and bring welcome visitors
    • Support local business and institutions
    • Inject new life into smaller/shrinking cities
    • Maintain links to - and value - your past
  2. Platform
    • Facebook, Google Plus or other social network
    • Any communal posting area that supports photos/discussion/moderation
  3. Guiding principles
    • Large amount of local control
    • Encourage tourism as much as revisiting
    • Especially support volunteerism
    • Especially support local festivals and city events
  4. Example point system for pictures taken:
    • 2 - you in town
    • 5 - you and local landmark
    • 10 - you supporting local business
    • 50 - you volunteering at local charity
    • 50 - you at local festival
  5. Rewards
    • Game enjoyment and community support
    • Gold, Silver, Bronze involvement rankings
    • No specific leader-boards
    • Less about competition, more about involvement
  6. Notes
    • No specific hometown?  You are a nomad player.
    • National chains ineligible for business photos.
    • Chambers of Commerce could be local bases.

Turn Timer 1 - WPF

Summary

I've been a player of Risk for over a decade.  Smashing enemy troops, bottling-up entire continents, and even achieving the odd victory is a high that keeps me coming back.  A piece of feedback keeps coming up, too: My turns are too stinkin' long.

Fifteen minutes of deliberation is not unheard of.  Five minutes is a lightning round.  Attempting to cover any possible outcome is a recurring theme time and time again.

So, for all of my future teammates and opponents, here's a solution:

Compressed screenshot of Turn Timer, taken by another tool not yet ready for display.
Turn Timer - a program designed for any turn-based game that encourages players to take their turns quickly.

Here's how it works:
  • Each round takes a default X time (set by the players).
  • A player finishes their turn at Y, with a difference D = X - Y.
  • That difference gets larger and larger the longer a player deliberates.
  • Difference D is added to the next player's turn, D + X.
  • If the player uses all their time, the program alarms the gamers that they need to move on.
  • If a player ends their turn before X (they got so much time from the previous player they ended their turn early), no time is given to the next round.
Why stop at Risk?  Turn Timer can optimize Chess, cards, and even D&D!  You can check out the most recent download here on GitHub and on Board Game Geek (link coming soon!).

Considerations / Specs

Turn Timer is made as a Windows Presentation Foundation (WPF) program in C#.  Both WPF and C# are very familiar to me, thus allowing for Turn Timer's quick creation.

The code follows the Model-View-View Model (MVVM) framework.  MVVM enabled me to get the basic functionality in, and once in, not have to worry about it as I began work on the XAML design.

A separate View and View Model were deemed necessary to handle the Settings popup.

As can be seen, the program is fairly simple, but what it allows for is something more robust than merely watching the clock.

Future

Number one item in the future is to get links onto this post after uploading the program to different locations!

Next issue to tackle is getting the XAML reigned-in to be more pleasing for users.

Finally, I aim to challenge myself to remake Turn Timer in the following formats and languages to move out of my .Net comfort-zone:
  • C++
  • Java
  • Remade as an Android / Mobile app
  • Remade as a Universal Windows Application (UWA)
Check in again when new programs, designs, and insights are released here on Make Better Games!

Telemetry, Logging, Debugging : Background Necessities of Development

Imagine you're helping test Beth's game.  Suddenly, jumping onto a ledge in the new lava level, things begin to lag, enemies stop attacking, and the game crashes; a popup of "Unhandled Exception" shows.  Consulting Beth, she doesn't know what happened and confirms there isn't any information saved from the game in cases like this.  Thus, valuable details on a bug are lost, leaving Beth to try to reproduce the issue and stepping through the code with breakpoints!

After years of both making programs and being on the receiving-end of someone else's development, I've come to identify a number of things that every program should have (including Beth's) to help designers, testers, and the developer themselves when their product is in use. Let's see how they could help Beth's situation:

Telemetry

Performance

- Crashes: hold enough memory in reserve to send a final notification to inform on any crashes.  The type of crash (OOM, unhandled exception, etc.), the callstack, build version, and any other applicable details must be included in the telemetry event.  This way, no application failure will go unnoticed, decreasing turnaround time to getting a fix in.

- FPS, memory/CPU usage, and network details should be included in periodic telemetry check-ins.  Gauging what is happening between check-ins can show trends of where performance needs to be improved, such as in the lava level.
An example from the lava level could have been:
1-2-16 17:18:19 (date-time), 123abc (session-id), 0.1.2.3-Test (version), unhandled_exception (type), foo at bar (callstack if applicable), Lava_Level_1 (level), 12.3 (FPS), 456 MB (memory), Windows (platform)

Input

- Can the program accept user interaction?  If so, every user action should be attempted to be recorded (a must for simple GUIs).  For more complex products such as Beth's game that can have dozens of inputs in a single second, the following is more suitable:

Interaction

- Pickups, the firing of weapons, level exits, cinematic skipping, the works - in this case, more data is better.  When the user can take action on the content in the program, it should be recorded for later analysis.

- Things to include would be information akin to time/date, a session ID, XYZ, level, what's currently equipped, checkpoint, health, what's being interacted with, etc.

- If there are processes or actors (e.g. NPCs) other than what is coming from the user, record those, too!  Who's the AI targeting, how is the manager handling pickup clean-up, and the streaming-state of cinematics are all questions Beth should be wanting answers to.

Logs

In General

- Pick a spot to put playtime and error logs that is going to be present on every system (a user's Documents folder, phone/console scratch folders, etc.).  When on a development environment, the details should be very verbose, allowing anyone to deduce what both the player and the system were doing at any given point.
During release, the user doesn't (shouldn't) need to see all the details of what is going on, so regular playtime logs could be toned-down or turned-off.  Error logs do, however, need to be made available to the end-user if developer follow-up is required.

Debugging

Hooks

- Exposing debug hooks that affect the nature and status of the program is necessary if there's any high-level blackbox testing to be done.  Instead of starting from scratch, a testing user can allocate virtual funds, profile details, and, in games, weapons, health, and altered-AI states quickly and on-demand.  Instead of starting from level 1 in Beth's game, the player can go straight to the lava level and re-equip the gear they had before the crash!

- Hooks should be disabled for release builds of the product to eliminate an avenue of unwanted manipulation when it comes to data and performance.

Error Messaging

- No-matter the version, any time a program hits an error or crash, a useful error message should display to the user explaining the problem encountered and any additional steps they should take.

And what makes a message useful?
  • A lack of technical jargon.
  • An explanation that could be given to Beth's grandmother.
  • What can be done by the user in the future (e.g. enter only letters and spaces into a name field).
  • Contact info or a link to submit an error report (if the issue is serious enough).

Before Beth starts looking into why the game crashed on the lava level, she may want to spend time implementing behind-the-scenes systems to make future issues easier to resolve.

Including telemetry, session logs, and embedded debugging in any game or commercial app will ease a lot of pain when a user comes back with a crash or other heinous issue that needs correction.  For myself, this is a best practice for anything new I make, and I highly encourage you to do the same!

Welcome!

Thank you for visiting!

This blog is taking over from GamesOfTaste.blogspot.com.  The best content from there along with fresh posts are on their way shortly.

I look forward to sharing with you insights and thoughts on games and how to make them better.  Feel free to checkout Games Of Taste and to contact me at jmchattin (at) gmail (dot) com.

Take care,
Jimmy