Problem

People with small amounts of spare time have a hard time getting back to long narrative games. Games tend to be designed to be a single long experience and often have few affordances to redoing their onboarding. (You give the tutorial at the start of the game and don’t retrigger it again.)

Let’s explore some ideas for improving the “haven’t played in a month” player experience.

Successful examples

• the Previously on Alan Wake segments are effective: they summarize what happened before, the character’s current motivations, and they’re good opportunity for character-building. You get one Previously On segment between each chapter which makes them a great stopping point. (This is very expensive and needs to be integral to the game.)

• Deus Ex: HR’s loading screens summarize where you are in the quest (with multiple updates for each quest). It’s different information each time you load (assuming you made progress), but not information overload. (This is pretty cheap.)

• Arkham City uses screen shots on the loading screen to lay out objectives or summarize recent plot points.

• Dishonored 2’s Travel Log documents the player’s journey with notes and photographs. This journal update after each mission. Dishonored 2 also features a pinboard connecting the characters/locations to give the player some spatial overview of what’s progressing in the world.

• Persona 5 has a few methods: a persistent countdown timer in the top right to highlight your deadlines, frequently mention objectives in dialogue, show snippets of conversations and tweets (usually related to the objective), dungeon save points trigger companions to talk about the next dungeon objective.

Potential Solutions

On a recent game, I pitched the loading screen as a mess of tweets about recent in-game accomplishments and plot points. It was age-appropriate to one of the characters, could convey character-building, and I thought a mix of pictures and text would be effective for keeping it fresh. (This is a bit expensive, but might be worthwhile for a long game.)

I’d like to try a tutorial pop up that occurs the second time you do an action unsuccessfully (the initial teach) and every time you fail three times in a row. So if you need to mash X during a grapple (in a scarce-UI scarce-tutorial game) and you keep forgetting, then the game can tell you what’s going wrong. If you come back after a long time, the game can remind you how to play. Need a careful balance between the game taunting the player on each failure. This logic can also push tips into the loading screen. (Probably worth the effort if avoiding hand holding tutorialization.)

Thanks to contributions from PiLLe1974 and Swiftster in the original reddit thread.

Basic requirements for a bug reporting system:

• Capture screenshot, machine info, in-game location, user-provided category, log, user data (arbitrary function returning a string), and upload to a server. Ideally I have the option of running my own instance of that server.
• Provide aggregation on the server (tag clouds, heatmaps, etc) to help narrow down which problems are most prevalent. Must be GDPR-compliant.

For a general system, it’s important to think about how different games have different needs and figuring out how to provide the most value to your target market:

• lots of worldgen makes some kinds of data (location) useless.
• static world makes other data (location) very useful.
• logs may be enormous (GB) and full of useless garbage. useful info is usually at beginning and end, but sometimes in the middle (followed by spam caused by the error).
• iOS has limited ability to access log files so a log buffer may be useful (was for us). Create a circular buffer and add each log print so they’re in memory.
• some platforms already have bug reporter that may access data that you cannot (like crash dumps) – how to get those into your system too.

What data should it upload?

• date
• platform/proprietary user id
• game version: build type (editor/debug/release/optimized), steam beta branch, revision or commit hash
• hardware: CPU, GPU, RAM
• OS version
• game world location (name of level, camera/player position, camera direction) – enough to programmatically jump back to that exact location
• log file
• screenshot
• provided by player: summary/title, description, category (Gameplay, Graphics, etc)
• save file
• world seed (for procgen)
• callstacks for scripting errors

Very specifically, the hardware info we grab using Unity’s SystemInfo:

• Environment.OSVersion.Version
• SystemInfo.graphicsDeviceName
• SystemInfo.graphicsDeviceType
• SystemInfo.graphicsMemorySize
• SystemInfo.operatingSystem
• SystemInfo.processorType
• SystemInfo.systemMemorySize

What rate of bug reports do you expect?

We got 20 bugs last week. Looks like lots of different people, but some people send better bugs (more details, repro steps) and some send unhelpful bugs (just a screenshot with a title “where collectible?”). Some of the bugs are in other languages (our game is in 11 languages). We probably get lots of feedback about the same problem, but don’t any kind of automatic categorization (no heat maps, word similarity, etc).

I don’t have any tracking for who submits reports (like how many were reported by one user), but I have seen some names pop up multiple times.

I wish we had fancier tools to make it easier to recognize issues that are affecting a lot of players to help prioritize.

Ways to present bug reporter

• Pause menu has a report bug option that opens an in-game screen for player to fill in title, description, and includes a screenshot of whatever’s behind the pause screen.
• Press a key from anywhere to open bug report screen with screenshot. Nice because it works for bugs on screens, but users have to remember that hot key.
• Console command that brings up a bug report screen (like BugIt in Unreal).
• External tool. Usually for internal use only.

Where to store bug reports

• Forum - as posts in a specific sub forum
• Slack - in a dedicate channel
• Bug tracker - like the open source redmine

In theory, users can comment on their bugs, but it’s much easier to report another bug.

Beware making users feel they can check the status of their bugs if you don’t intend to keep the status updated.

There are a few ways you can go about this abstraction in C-like languages:

1. make a base interface that your platforms inherit
2. make the platform-specific code the base class
3. make platform-specific APIs all use the same name

(1) is the most obvious:

// retailplatform.h
class RetailPlatform { ...api functions in here... };

// steamplatform.h
#ifdef STEAM
class SteamPlatform : public RetailPlatform { ...api functions in here... }
typedef SteamPlatform ActualPlatform;
#endif

// xboxplatform.h
#ifdef XBOX
class XboxPlatform : public RetailPlatform { ...api functions in here... }
typedef XboxPlatform ActualPlatform;
#endif
...

RetailPlatform* ThePlatform = new ActualPlatform();

(2) is a bit weird, but because only one platform API will be defined at a time, we can avoid duplicating function declarations in RetailPlatform and using vtables:

// steamplatform.h
#ifdef STEAM
class SteamPlatform { ...api functions in here... };
#endif
...

class RetailPlatform : public
#ifdef STEAM
    SteamPlatform
#elif XBOX
    XboxPlatform
#else
    // a fallback with mostly empty functions
    StubPlatform
#endif
{}; // empty!

RetailPlatform* ThePlatform = new RetailPlatform();

I like this method also because it’s the easiest way to have a fallback else case for a Stub. Having a Stub version of your abstraction is useful for testing without connecting to your the storefront and as a starting point for porting.

Also, with this method, we don’t even need virtual functions. Since only one implemention of each function will exist per build of the game, they’re unnecessary.

(3) feels a bit gross to me since the name isn’t specific, but it avoids needing a typedef or ifdef’d creation:

// steamplatform.h
#ifdef STEAM
class RetailPlatform { ...api functions in here... };
#endif
// xboxplatform.h
#ifdef XBOX
class RetailPlatform { ...api functions in here... };
#endif
...

RetailPlatform* ThePlatform = new RetailPlatform();

You might look at this and say, “what about pimpl?!” However, pimpl would look like (1) except RetailPlatform contains a pointer to RetailPlatformImpl which follows the (1) subclass pattern. I doubt you see an improvement to compile times since you can put platform headers in your pch. Hard to see benefits of adding that extra complexity.

ref

For really basic art, How to Make Your Game Look Good if You’re Not a Good Artist from Miziziziz is a good video overview.

An Approach to Game Art for Solo Devs, Small Teams, and Non-Artists has a collection of materials and methods that favour shapes and code transformations over any drawing. (reddit thread) It comes from a talk (summary stolen from here):

1. Simple shapes. Squares, circles, triangles.
2. Good color choices. Use color picking tools. Use less saturated colors.
3. Lean on post processing and other full screen effects to “tie the room together” and make your game look polished and intentional.
4. Learn a couple really simple code driven animation techniques to breath life into your characters and scenes.

A main point of the talk was designing for anyone. Since they’re making a 3D game, many issues arise from how to make things intuitive in the camera angles and movement freedom that 3D brings.

Aiming projectiles

12:01

Kirby is a sphere, so it’s hard to tell which direction he’s facing. Solution: sophisticated homing.

• (13:20) Score enemies based on facing direction, distance, importance/priority.
• Distance is directional so it doesn’t catch airborne enemies when Kirby is grounded.
• Airborne aiming is hard, so homing is stronger when flying.
• Homing works in two stages. In the first frame, projectile facing snaps to target. After that, homing is limited. Goal is to make players feel like they’re successfully aiming instead of homing.

Unique hit detection system

15:40

It’s difficult to get a sense of distances in 3D. If you’re aiming in the ground plane but viewing along that plane, it’s hard to tell when you’re shooting in front or behind objects. Solution: Apply hits based on whether it looks like they hit.

• (16:53) Extend hit direction in the depth direction. Not just larger hitbox, but it’s extended in the depth direction using the camera position.

3D cameras are challenging for beginners

19:01

It’s hard to control both character and camera at the same time. It’s hard to be aware of your surroundings in 3D. Solution: Level designers configure cameras instead of player control.

• Apply 2d level design knowledge.
• Shift camera to include relevant objects (hazards, paths).

Hovering out of bounds

20:38

Kirby can fly so players will want to explore out of bounds. Solution: hint boundaries with camera.

• (22:35) Camera object hits walls that prevent its movement. So when you walk right and hit a barrier, the barrier stays on the right side of the screen and Kirby can’t push the camera further right to see what’s there (there’s nothing there).
• Radially project from desired camera focus point to find camera boundaries and smoothly adjust the actual focal point. (Gotta watch because the explanation is not very technical.)

Posted on r/TheMakingOfGames

Check out Games Press for posting press releases. Make sure you have a presskit so interested journalists have screenshots and information.

Some articles to help with writing your press release:

• Hey indie devs, here’s how to contact the press!
• Getting Your Game Noticed (Is Very, Very Hard)

If you follow any industry news or gaming websites, then you should keep track of which people like games similar to yours so you can contact them directly about your game since they’re more likely to be interested.

Check out something like presskit.html. It’s like the old presskit(), but as a static site so you can host for free as Github Pages or any other hosting site. See The blueprint for building a press kit for a thorough presskit explanation.

ref

I’ve never seen a custom engine that impressed me so much. They’ve built a whole tech stack so all parts are tightly integrated:

• Custom language, compiler, runtime.
• Custom code editor and debugger.
• Custom game engine (obviously).

Because those parts are custom they can:

• Recompile on every keystroke without visible hiccups.
• Step through rendering code and see individual parts draw to the screen like RenderDoc or Unity’s Frame Debugger.
• Reverse step through code
• Run to breakpoint in reverse (or data breakpoint!!!)
• Stores a session file that tracks all of your input and code changes that’s portable so you can send to coworkers.
• Retrieve correct source version from version control so when you receive a session, it runs it with the correct code.
• Tag objects with a timestamp so you can jump entire program state to that time for stepping or inspecting.
• Profile, click on spike, click on timestamp on spiking function and it rewinds to that point with the debugger stopped at that function.

I wonder how complex their game can be and maintain good performance with all of this debug enabled. Could they make something with as many moving pieces as Factorio?

I think the reason these puzzles exist in many games is because either:

• the team didn’t have time
  • Either they wanted something more interesting or they realized too late they needed a puzzle.
  • They might have designed something, but cut it down to a simple block puzzle for scope and tutorialization reasons.
  • They might have realized that they needed some additional challenge on special chests to make them feel more consequential.
• Their designed puzzle was too hard
  • Playtesting showed a more interesting puzzle was too difficult for their target audience. Action gamers may not enjoy a challenging puzzle because they just want to shoot.
  • This falls back to the first point: they didn’t have time to do something more interesting.
  • Playtesting reveals shocking truths about some players. You have them walk into an area, turn the camera to look at the roof, have them stand in front of a van that’s half the roof height, and they’ll jump on the van, drive the van around, destroy it, but never guess they should get onto the roof. Many people don’t come to action games to think, so when you add mental challenges you will lose them.

Sliding block puzzles are safe.

• They can usually be shuffled around randomly until they unlock
• There’s no fail state. You can always get back to the initial setup without any undo button.
• They’re familiar. Players know how they work.

But they’re boring and I think we should all do better!

ref

Take a tutorial like this one and add more enemies. Add enemies that move in a different direction, have a different speed, or follow a sine wave. Try to do it without looking anything up. If that fails, scope down your plans. If it seems impossibly small and simple, google answers but not tutorials (stack overflow, reddit, etc). Try to piece together what people are saying and how to do it. If that fails, look up tutorials, watch, take notes, but don’t copy paste code. See if you can port their ideas to your code. If that fails, look yourself in the mirror and ask if you really tried hard enough to scope down and figure out this small step or if it just seemed too boring or too hard. If that fails, figure out how to motivate yourself to do hard and boring things (gamedev is full of them and they’re necessary).

I’ve worked in games professionally for more than a decade so it’s been a long time since I was stuck in tutorial hell. The above is my typical process when doing tutorials for a new engine or technology.

ref