Randomness and Player Agency

Hey all,

Have you ever felt like a random number generator (RNG), not the game itself, caused you to lose? Have you ever said "RNGesus beat me"?

Have you ever felt like RNG has led to your victory?

Today, I would like to discuss the use of random number generation and game design, specifically about player agency.

Agency: The capacity of an actor to act in an environment.
(At least I didn't OPEN with a definition. Sure, the definition came in about only 4 sentences, but who made you the authority on article / essay writing? Also, why are you counting?)

RNG is an interesting topic in games, because when applied correctly, it can allow for emergent possibilities that are more fun for your target players. When applied incorrectly, RNG can be an incredibly frustrating element for your players.

Think I'm exaggerating on that last sentence? Take a look at people's thoughts on Five Nights at Freddy's 20/20/20/20 mode.

In short, players want to feel like that no matter what happens, that the results of an encounter / battle / whatever are caused by their own decisions, by their own skills, not by the game itself. The player is an agent within the game's rules, and acts to cause reactions, and the results of the game should be a reflection of those actions.

That doesn't mean that all RNG is bad, however. For that, let's take a look at a few examples.

• Texas Holdem' Poker: Cards that are dealt are essentially random, as cards are dealt, the possibility space (the cards you can possibly get) decreases. Any one player can beat another player during a single game of Poker. Randomness is mitigated by playing a set of games. Good players are capable of playing the odds and wagering when the odds are in their favor, or bluffing (playing the other player), resulting in a win over the course of a set.
• Mario Party: Movement is random by rolling a die, the possibility space in that sense is constant. Mini games may have elements of randomness in them, sometimes deciding winners arbitrarily, but there are so many mini games played during a session to mitigate the effects of a single adverse mini game result. The end game star allocation makes the possibility space wide open, leaving players who are the best at mini games or map navigation to be subject to losing, potentially rendering an entire game of smart play as moot. Any one individual game can be so random that caring about winning is really a test in insanity. (I call this the absurdity principle.)
• Mario Kart: Item allocation is a weighted random, where players who are lagging behind are given a higher chance of getting better items. Items create new possibility spaces by knocking leading players out of the way, or giving lagging players a speed boost. The amount of variance is limited, and may cause a better player to not land in 1st place. Good players can mitigate the effects of the items through skilled play, item management, and maximizing opportunities over a set of races.

Notice something about the first and third entries? A good player can win by taking advantage of opportunities caused by helpful randomness, and mitigating the effects of adverse randomness (by either playing well or playing over a large set.). There's a key in there though, a skilled player HAS the opportunity to mitigate the effects of adverse randomness. Like I said before, "The player is an agent within the game's rules, and acts to cause reactions, and the results of the game should be a reflection of those actions".

Good use of RNG opens up the possibility space (the amount of possibilities that can be generated), but in a limited amount. Players continue to have agency in the outcome generated by the use of RNG. You can quote me on that.

Discussion about Mario Party is a great example of bad use of RNG. Ever heard someone say to you "I was winning, and then the game decided to give my friend all of the stars", or something equivalent? Dice rolling is one thing, handing out game winning tokens at the end of a game, when players can no longer take action, is another. Ever had that friend who almost ended a friendship with you because of Mario Party, or heard such a story? Mario Party becomes more fun when players give in to the "Absurdity Principle", which is essentially admitting that the game is crazy and to not take it seriously.

A bad game will use RNG to potentially affect the outcome of a game, and not give a player the opportunity to change the outcome based on said RNG, or severely limit the amount of actions that a player can take, removing or crippling their agency. A bad game will let RNG blow the possibility space wide open and essentially decide winners and losers. I literally have a phrase for it, "Deciding winners and losers.", don't let your game do that, if you're making one.

Bad RNG removes a player as an agent within the game, not letting their actions have an effect on the outcome. You can quote me on that, too.

Following the "Absurdity Principle" is hard to achieve, and the designer is walking a tight rope and relies on the player's subjective definition of fair and competition. I'm not saying to not make a ridiculous game that uses RNG, just be careful.

When making your game, if you choose to have an RNG element to your game, consider these things:

• What does this use of RNG do to my game's possibility space? (What results can come from it?)
• Does this use of RNG limit what my players can do, and if so, by how much? (How much agency will my players have?)
• Does this use of RNG decide winners and losers?
• Can players overcome the results of this use of RNG?

If any section in here needs clarity, let me know.
Jimmy

A Topic About Persona 5

Hey all,

Today, I wanted to discuss a mechanic of a game that has been making some waves. Before I really get started, I want to say that I'm enjoying Persona 5 so far, I'm about 84 hours in and about to wrap up the final chapter.

I'm not here to talk about the game as a whole, however. I'm here to talk about one mechanic, specifically the monster recruiting mechanic. I'm going to be 100% frank here, I think it's not as good as it could be.

To the uninformed, Persona 5 is a new game from Atlus in which the player controls a group of teenagers who use their new-found powers and friendship to save the day, while staying true to themselves. This game allows players to recruit monsters into their party by communicating with the monster after it has been struck by a critical attack or its weakness while in combat. Once the communication has been initiated, the player must answer 2 questions from the monster correctly. Each question has three possible answers, and the answers are based on the monster personality, which can be viewed before initiating communication, but not during.

I have several problems with this mechanic:

• A lot of the answers to the questions involve lying to the enemy. In a game whose narrative is about being true to yourself, why do you have to lie to the enemies? Doesn't this oppose one of the points of the narrative?
• Not being able to view the monster personality during a conversation in order to gauge what kind of answer will most likely be correct, is bad.
• If the player gets one question right and the other "half right", the monster will randomly either give an item (and run away) or join the party. I dislike random chance in situations like these.
• Not knowing what kind of answers are correct essentially makes the answers random, and when the player gets these questions randomly wrong, the player may feel cheated. Also, in this case, the optimal way to play IS to guess randomly, removing any agency the player may have in this scenario.
• The tutorial about monster recruiting isn't exactly helpful: "Gloomy monsters like vague answers." Sometimes, none of the possible answers to a question fit the description, maybe this is a translation issue, but I dislike it nonetheless.

Now, I wouldn't just complain about something and not have a solution of my own. This is just me spitballing, but I think even this would be a better mechanic.

Have the monster say something about their personality over several turns, the player is allowed to either get another personality hint or select the person on their team whose personality best matches the monster (or make an educated guess on the personality type or whatever) to convince the monster to join their team. The player gets extra money or experience for convincing the monster sooner before the maximum turn limit. Think of it like a game of Mastermind. The randomness would be removed and player's would still have to engage with the monster's personality. Maybe if the player has a narrow miss of recruiting the monster, they will get an item instead, but NOT by random chance.

I just made that up, seriously.

To be clear, I'm not against random number generators in games, but I am against them in select situations where player agency is involved. Maybe I'll go over this in a separate post.

Oh well, at least this mechanic as it stands is better than Shin Megami Tensei 4? That game was not as good as everyone said it was.

Jimmy

A Chemistry System?!

Hey all,

So, I got this idea from my trip to GDC last week, from Nintendo's The Legend of Zelda talk. The idea was to make a chemistry system for games, since physics engines already exist.

You can see the commit here: JFramework

Basically, I created a component (called material) with properties such as melting point, freezing point, boiling point, conductivity, temperature, etc. that keeps track of properties of a material. This component can essentially set objects to freeze, or melt, or whatever I need it to do given the right conditions.

On top of materials, I created an element component, which radiates a temperature and/or wattage.

The rules of the system are as follows:

• A manager will have a global temperature to apply to materials.
• Materials can exchange temperature and wattage from other materials, and elements.
• Elements can exchange temperature and wattage from other elements. (i.e. a flame can be put out by water.)

It's a pretty basic rule set, and may be adjusted later.

I thought I would discuss what I was working on while NOT playing The Legend of Zelda: Breath of the Wild.

Speaking of Zelda... Play it. It's now my favorite game of all time, maybe a full review later?

New A Sound Plan footage here: YouTube

Thanks,
Jimmy

A Very Peculiar OSX + OpenGL + SDL2 bug

Hey all,

I was working on JFramework (Link), updating the OSX edition to fully utilize shaders, because A Sound Plan is nearing Beta status, when I noticed a most interesting bug.

Using shaders ran the game at 100% CPU usage.

I was completely baffled, to say the least, as the build ran at about 4-8% CPU usage on the Linux AND Windows builds of the engine.

Part of me yelled that I should have taken care of this sooner, as both the Linux and Windows builds of the engine had been using shaders for over a year. Another part of me yelled for not just taking care of the OSX build at the time when I worked on the Linux and Windows builds. Another part of me yelled for being all "hindsight is 20/20".

After the yelling session was complete, I had to buckle down and just get this thing out.

Rather than tell you every step I took to solve this issue, I'll just give you the highlight reel of what makes the OSX driver so strange.

1. OSX differentiates between its 2.1 and 3.0 cores in their driver, you must specify which core you are using when you create a new GL context. The default is 2.1. There is very little compatibility between the two cores, i.e. you cannot use immediate mode in 3.0. Example provided below on how to activate the 3.0 context using SDL2. Note: I'm using GLEW to assist in loading and linking OpenGL functionality, the glewExperimental flag allows OSX to use core functions without the EXT or APPLE extensions.
   
   
   
   How to set up the core profile on OSX.
2. I implemented a batching algorithm to draw similar objects together, since the algorithm is so long I'll summarize it:
   
   • Start with a list of objects to draw.
   • For each object that shares a texture id and program id:
   • Add vertices, texture coordinates, vertex colors, etc. to separate containers.
   • Upload all data in containers using glBindBuffer and glBufferData (i.e. bind a buffer location and upload data to GPU)
   • Make draw call, in my case I call glDrawElements using GL_TRIANGLES.
   • Iterate until all objects are drawn.
   If you want to see the code in action, look at file: Source/Graphics/PCShaderScreen.cpp
   While this improved the speed of my drawing, it didn't fix the Mac build, but it's nice to have.
3. Calling glActiveTexture using proprietary drivers on Linux and Windows using different ids is perfectly acceptable depending on hardware, the driver's patching abilities are pretty slick. The OSX driver, however, is HORRIBLE at patching itself (in its current state), forcing a recompile of the shader as it can't effectively sample a texture from any slot. Basically, call glActiveTexture(GL_TEXTURE0) unless otherwise required.
   • If your shaders are running slow the moment your shader calls texture (i.e. sampling), this is probably your issue.
4. The OSX OpenGL driver is peculiar in how it handles shader attributes. If you leave any one of the attribute fields unused but declare the location, the shader may run in software (i.e. CPU) mode.
5. Use Instruments on OSX whenever possible, use the Time Profiler module, use it. If you notice calls to SCCompileShader, that means that something in your shader is forcing a recompile, spinning up a lot of CPU.
6. Write functions that pretty print OpenGL errors, just do it, it's massively helpful to know that you're adhering to the OpenGL spec. Remember to sprinkle the pretty print call wherever you can, so that you know when you've broken something. Turn on debug flags so that your release build doesn't print, you don't need that.

 Use Instruments, just do it.

OSX is known for having a pretty poor OpenGL driver, if you're having issues with performance, hopefully this short post will be of assistance.

If you want more hints, the docs here: Shader help, Texture help will help you.

Thanks,
Jimmy

Neat transition tech. (+Tutorial and link!)

Hey all,

Just gonna post this really quick before I go to bed:

Tech for this shader found here, all credit goes to this guy for the legwork: YouTube

I haven't written a tutorial in a while, so let's just jump into it! I'm excited!

I'll go over the details really quick, in case you don't want to watch a seven minute long video, but if you have the time, seriously, watch his video, give him support. Also, his video goes over differences between HLSL and GLSL, so it's more informative than what I plan to provide. The version I provide below is applicable to GLSL specifically, although translating to HLSL or whatever else comes along should be simple.

1. Make a texture that gradients from black to white, in any way you'd like, like so:
    
2. Write a fragment shader like so:
   
   i.e. If the color in gradient (in this case, the red channel, but that's not important.) is below your cutoff marker, make the pixel black, else it's invisible.
3. Apply this shader to your object, adjust the "cutOff" variable over time, and watch the effect in action!

Made using JFramework, found here: JFramework
Perhaps the best thing about this solution is the flexibility, you can just change the underlying gradient image to create a different effect.
If you have any questions, feel free to ask.

Also, I haven't shown Chang-e in a while, so you kinda get to see that, too.

Thanks,
Jimmy

I hate flying

Hey guys,

I'm returning back to Seattle after a week off in Maine, where I'm from. I didn't do much work on either game, decided to just sit back and relax to refresh myself.

I think it worked? I don't know?

I'm on a plane right now, there's 4 hours left on this flight. I don't like flying, I pretend that I hate turbulence, but in reality I just hate being cramped into such a small space for several hours.

Anyway, here are some doodles I made while I was away:

When I get off this plane I'll get back to work on games, maybe post a few videos from the playtests that I've conducted.

See you around,
Jimmy

A Sound Plan: Some New Stuff

Hey all,

So, Dean (Twitter, follow him to add to his count of followers despite him not posting anything.) and I did some talking, and we figured that A Sound Plan does not have enough variety.

So we fixed that in a quick and dirty way.

We added new rock types.

Yep, now we have rocks that explode, rocks that have a boomerang effect, and many others. Look forward to them in the next playtest!

Here's some sample art to look at.

Oh, that last one has nothing to do with A Sound Plan, but does have to do with Chang-e. I'm planning on developing Chang-e further and laying out an art style to have an artist follow in the near future.

JRPGs are notoriously hard to prototype and playtest, and it really shows for Chang-e, as development has slowed because I've run out of programming tasks for the most part, I really need an artist now to get a much needed boost.

Anyway, you can see a video of the Boomerang rock type here.

I really want to do another engine tutorial, to demonstrate JFrameworks feature set.

Jimmy