Sunday, December 17, 2017

Game Design 101: The 4 components of a game

Hey all,

Today, I want to take a step back and explain one of the very fundamentals of games.

Not JUST video games, mind you, ALL games.

Games are made up of four basic elements:
  • Objects - The actors, per se.
  • Attributes - Things such as health, movement styles etc.
  • Interactions - How do objects communicate with one another?
  • Environment - I like to call this "context", in what way is this game being played?
This is explained more in depth in the great book, Rules of Play, where Katie Salen and Eric Zimmerman both try to establish the building blocks of all games. I highly recommend it for budding designers and developers to understand the very fundamentals of the craft of game design.

Anyway, it's best to explain with an example. Let's take a look at Chess:
  • What are the elements of Chess?
    • Objects
      • The pieces
      • The players
    • Attributes - Pieces each have their own movement styles
      • Pawns - Can move one space forward, can move two spaces on first move.
      • Rook - Can move as far as they want (without going through pieces) in one of the 4 cardinal directions.
      • etc. etc.
    • Interactions
      • Players can move one piece per turn
      • Pieces can capture pieces from the opponent's side if their movement pattern allows them to occupy the same space as an opponent piece.
      • etc. etc.
    • Environment
      • Medieval look to the board and pieces.
      • Played in a competitive or educational setting.
When I make games, usually the first three elements (Object, attributes, and interactions) come simply enough, and I mostly think about the last one, environment.

The reason why environment is so interesting to me is because it takes an existing game and can literally change the entire meaning of the mechanics. For example, if I changed the pawns from foot soldiers and I made them dishevelled animals, and make the power pieces (queen, king, etc.) hold whips. All of a sudden, the game takes on a new meaning, yeah? You can do this to many games, give them religious allegories, real world problems, or circumvent that altogether!

Changing the environment of your game can literally change how it is interpreted, just as much as changing the interactions, the objects, or attributes.

I notice a lot of designers tend to neglect the environment of their game, with their themes merely there to showcase the other three elements in a barebone fashion. I personally believe that all elements should work together to create a general feeling, that a complete package game does not neglect any of the four elements.

A great example of a complete package is Nintendo's Splatoon! Think about how that game is played, and how the kid / squid theming kind of just makes it all make sense, contextually. Imagine if the characters weren't squids, would it still make sense, or even be as fun?

I'll end with this, don't neglect any facet of your game, think about it as a complete package!

Jimmy

PS. The next post will be an Game Engine Design 101, I swear. Sorry that I've been going on this design bend, it's just been on my chest for a while.

Tuesday, October 24, 2017

The Whole Package: An Appeal to Polish

Hey all,

This month, I want to talk about a subject that game design schools rarely talk about. It's a subject that is really just common sense, but I'm going to mention it anyway.

Honestly, my thoughts on game design schools in general could be its own topic.

Anyway, I see a lot of young game designers, or young indies, showing their games, and I've noticed a trend. A lot of the games I see have solid gameplay, but other aspects of the game are lacking. It seems as if they were taught "make the game fun", and took that as "the ONLY thing that matters is gameplay." I then see these young'uns try to sell what would have gotten them a "B" in class as a retail product.

Capitalism will not be kind to those people. While fine for school, these products would be consider lackluster once their creators start asking for money.

I'm not trying to be toxic to young indies, in fact, what I'm saying should be taken as a letter of challenge.

Games are so much more than just the gameplay. While the gameplay is, indeed, the most important factor (no one worth their salt would debate otherwise), there are many other things that propel a game into greatness. Things such as a clean look, clean sound, and solid music will only make a game better. If everything in a game is as good as the gameplay, it'll only make the game appear THAT much better.

Do you think Tetris would have gotten as far as it did with gray blocks and no music?

To those young'uns: Think about the whole package.

Before people get on my case, I'm not debating against simplistic looking games, not at all. I will argue, backwards and forwards, that Tetris is one of the greatest games of all time, and that game uses colored blocks! What I am debating against are games that, while solid in fundamentals, use the following in any combination:
  • Unequalized sound / music
  • Royalty free sounds / music
  • Unpolished, barebones, boxy graphics (If boxy is your aesthetic, at least make it look polished.)
  • Menus are simple text, using Arial or similar font.
  • A clearly not well thought out color palette.
  • Lack an options / settings screen.
  • Lack a logo / title screen.
Before you ask, yes, I've seen games try to sell themselves as retail products with some of the above.

If you are an up and coming indie / designer; on top of your game being fun / feeling good, ask yourself: "does EVERYTHING in this game feel as good as the gameplay?", as well. That way of thinking will help propel your game into greatness.

I'm not asking for much, just polish your game as much as possible.

Jimmy

Saturday, September 9, 2017

The Idiot Box

Hey all,

There's something that's been in my mind lately, and I really can't hold back talking about it anymore, so here goes.

It really goes without saying that we live in an incredible time, we can communicate across the world, can look up information at the moment we think to look up something, and can project our opinions out to the world, as bad as they may be. (See what I did there?)

But there's a concern that I have, and I'm not the only one to feel this way.

We carry devices in our pockets everyday: idiot boxes.

Idiot boxes aren't designed to enable their users to create, they are merely designed for their users to consume: apps, news, entertainment, opinions, etc. Idiot boxes enable people to be more connected than ever, yet lonelier than ever. Idiot boxes allow us to embrace superficial relationships over real ones. Idiot boxes make people available at someone else's beck and call. Idiot boxes enable people to look up other people's opinions on subjects to avoid forming an opinion of their own.

What is an idiot box? You're probably reading this post using one right now: it's called your cell phone / tablet. Combined with the internet, idiot boxes have allowed people to engage in the behaviors I mentioned earlier.

I call these devices "idiot boxes" because they are not used to create, these devices are used for consumption, a lot like TV. Frankly, I think people use these devices as a crutch to consume content, to not think for themselves, to avoid critical thinking (hence "idiot").

Now, I'm not saying to throw away your cell phone, I use one everyday, if only because of work.

I pose to you a few questions:
  • How many of your friends on social media are your "real friends"? How many of them would care if you were feeling down, not superficial "I'm sorry" caring, but really feel for you? Will these friends hurt if you are hurting, and vice versa?
  • How many hours a day do you spend on YouTube, Spotify, Buzzfeed, etc.? How many hours of productivity have you lost?
  • Have you noticed that your attention span has shortened, even to the point that sitting and doing nothing for 10 minutes is agonizing?
  • How many times has someone asked you a question (via text or social media), and then expected you to reply almost immediately?
  • How many times have you been to dinner and noticed that a LOT of people are on their idiot boxes, not engaging with the people literally around them? 
  • How many times have you looked up a film review or game review and formed your opinion on said subject based on the review?
Idiot boxes and social media have turned people into a product, where people show only their best sides to the world, it's incredibly hard to make real friends in this way. "Friends" is simply a number that goes up based on your popularity. When times get rough, if all someone has is their social media "friends", that someone may not want to expose such feelings to the world, it can create a feeling of loneliness. Connected, yet lonely.

Having unlimited entertainment at our fingertips has given us instant gratification, we don't have patience anymore. We have grown accustomed to always having something playing, entertaining us; so much so that not having something around is the exception, not the norm.

Always being connected has allowed people to contact us at any time, for better or worse. People may expect an answer from another person immediately after sending a message, even when that person may be introverted or may not want to talk. We have become a product for other people to consume.

In some cases, people don't even pay attention to those around them, instead they choose to consume media from the idiot box. I don't know about you, but when someone does this to me (at dinner or something), I feel lonely, boring, or inadequate. Frankly, I find it rude.

Lastly, it's easy to avoid thinking critically when you can simply look up someone else's opinion and borrow said opinion.

All I ask is that every once in a while, break away from your idiot box, pay attention to those around you. Be understanding, be kind, and care for those immediately in front of you, they're people too. Spend time with your friends in the real world, talk with them over lunch or dinner. Take a few minutes out of the day to just exist, no entertainment.

Who knows, you may notice something you didn't before.

Jimmy

P.S. I find it amazing that we can communicate as much as we can now, just be sure to interact with the real world every once in a while.

P.S.S I want to make a game surrounding my feelings on this subject someday. Frankly, I hope by the time I get to making the game, my concerns are addressed and then I won't need to make the game at all.

P.S.S.S Don't form your opinion based on mine, think for yourself.

Tuesday, August 1, 2017

Game Engine Design 101: The Factory Design Pattern

Hey all,

Wow, it's been a while since I made a tutorial / learning series.

But I'm back, and I'm taking a 15 minute break from coding.

While coding up something, have you ever noticed that it would be nice to be able to create objects, but not worry about the specifics of the object you are handling? Maybe you would like to create an object "for now", but it may change later, and you don't want to rewrite all of the sections that use your object? Do you want to centralize all of the logic of creating objects of a specific type?

Good news! There's a design pattern for you!

Known as the Factory Design Pattern, this pattern allows you to specify the way in which you create objects, and let you not worry about the specifics of creating an object nor the specifics of what kind of object you are handling, so long as the objects derive from the same base. Another benefit is that all the logic to create derived types is in one place, rather than strewn about your code base.

All examples pulled from: JFramework

An example: Let's say you want to create a material (for chemistry stuff, think gold, steel, cloth, etc.), but you may create different kinds of materials based on certain parameters.

We start with a basic ChemistryMaterial class. This class can be derived from, or used as is.

#ifndef __JFramework__ChemistryMaterial__
#define __JFramework__ChemistryMaterial__

#include "Component.h"
#include "Common.h"
#include "ChemistryManager.h"

class ChemistryMaterial : public Component
{
private:
  // Members

public:
  ChemistryMaterial(ChemistryManager* aManager);
  virtual ~ChemistryMaterial();
  
  // Virtuals derived from Component
  virtual void Update();
  virtual void SendMessage(Message const& aMessage);
  virtual void ReceiveMessage(Message const& aMessage);
  virtual void Serialize(Parser& aParser);
  virtual void Deserialize(Parser& aParser);
};

#endif // __JFramework__ChemistryMaterial__
If you want different behaviors for a ChemistryMaterial, just derive from this class.

Next, we create a Factory class as an abstract class, which means in order to use these methods you need to derive from this class and implement them yourself, there's a reason for this.

What if you want different kinds of Factories to have different behaviors, but still be usable in the same places in the code base? That's why.

In JFramework's case, I can't possibly account for the numerous types of Factories, with distinct behaviors, that a user may want to make, and purposefully leave it open ended by allowing the user to create, implement, and change Factories within the engine.

#ifndef __JFramework_ChemicalFactory_h_
#define __JFramework_ChemicalFactory_h_

#include "ChemistryMaterial.h"
#include "ChemistryManager.h"

class ChemicalFactory
{
public:
  ChemicalFactory() {}
  virtual ~ChemicalFactory() {}
  
  virtual ChemistryMaterial* CreateMaterial(ChemistryManager *aManager, HashString const &aName) = 0;
};

#endif // __JFramework_ChemicalFactory_h_

Now, we derive a Factory.

#ifndef __JFramework_DefaultChemicalFactory_h_
#define __JFramework_DefaultChemicalFactory_h_

#include "ChemicalFactory.h"

class DefaultChemicalFactory : public ChemicalFactory
{
public:
  DefaultChemicalFactory();
  virtual ~DefaultChemicalFactory();

  virtual ChemistryMaterial* CreateMaterial(ChemistryManager *aManager, HashString const &aName);
};

#endif // __JFramework_DefaultChemicalFactory_h_

#include "DefaultChemicalFactory.h"
#include "ChemistryManager.h"

DefaultChemicalFactory::DefaultChemicalFactory() : ChemicalFactory()
{
}

DefaultChemicalFactory::~DefaultChemicalFactory()
{
}

/**
 * @brief Create new material.
 * @param aManager Manager associated with creation.
 * @param aName Name of material.
 * @return New material.
 */
ChemistryMaterial* DefaultChemicalFactory::CreateMaterial(ChemistryManager *aManager, HashString const &aName)
{
 ChemistryMaterial *material = new ChemistryMaterial(aManager);
  return material;
}

Making a Factory is simple now.

ChemicalFactory *mFactory = new DefaultChemicalFactory();

You can now create ChemistryMaterials with your Factory and do whatever you'd like with them like so:

/**
 * @brief Create new material.
 * @param aName Name of material type.
 * @return New material.
 */
ChemistryMaterial* ChemistryManager::CreateMaterial(HashString const &aName)
{
  ChemistryMaterial* material = mFactory->CreateMaterial(this, aName);
  AddMaterial(material);
  return material;
}

At this point, you can do whatever you want with your ChemistryMaterial that you could do with any other ChemistryMaterial.

To make things interesting, let's make our Factory return a variety of ChemistryMaterial types.

Assume that all materials referenced here derive from the ChemistryMaterial class.

#include "DefaultChemicalFactory.h"
#include "ChemistryManager.h"

DefaultChemicalFactory::DefaultChemicalFactory() : ChemicalFactory()
{
}

DefaultChemicalFactory::~DefaultChemicalFactory()
{
}

/**
 * @brief Create new material.
 * @param aManager Manager associated with creation.
 * @param aName Name of material.
 * @return New material.
 */
ChemistryMaterial* DefaultChemicalFactory::CreateMaterial(ChemistryManager *aManager, HashString const &aName)
{
  if(aName == "Steel")
    return new SteelMaterial(aManager);
  else if(aName == "Cloth")
    return new ClothMaterial(aManager);
  return new ChemistryMaterial(aManager);
}

If you were to do this, all the code that you wrote previously around the Factory would still be valid! You don't need to handle the particulars of the different ChemistryMaterial types yourself, and if you want to create a new ChemistryMaterial type, just change the CreateMaterial function in the DefaultChemicalFactory.

As you can (hopefully) see, the factory design pattern is great when you want to "set and forget" a particular implementation of an object. It's great when you need to make a variety of different types that derive from the same object, and you don't want to worry about the particulars of the derived object itself. It's also great when you want to centralize the creation of objects that share the same base.

With my time up, I'm gonna get back to work.

tl:dr of this whole article:
  • Make a base object that created objects will derive from.
  • Make a Factory object that has a method that creates objects of base object that.
    • Make that method take whatever parameters it needs to make objects.
  • Replace all uses of new on base object type, replace with you Factory creation method.

Jimmy



Tuesday, July 4, 2017

A Sound Plan Beta: Announcement!

Hey all,

I've been hard at work on A Sound Plan and Chang-e for the past few weeks, so I've kind of neglected this blog for a bit.

But it was all worth it, because I'm proud to show you this:
A Sound Plan Beta

The story behind this build is a bit of a long one, so I'll keep it short:
We had to get something ready for Seattle Indie Expo.

Dean and I had to work really hard, but we managed to get a stable build out into the judges hands, we're waiting on final review on whether or not we'll be in the show. (Crossed fingers)

Some things that have changed include:
  • New power up rocks
  • Dust clouds
  • Audience
  • Body parts fly around
  • Menus are a bit smoother
  • New art
  • New sounds
There are more features, but I'm drawing a blank right now.
If you have any questions after watching the video, feel free to ask here or on Twitter: Twitter

Thanks,
Jimmy

Monday, June 5, 2017

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

Sunday, April 30, 2017

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

Monday, March 13, 2017

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

Friday, February 17, 2017

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


Thursday, February 2, 2017

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

Monday, January 23, 2017

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

Monday, January 16, 2017

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

Saturday, January 7, 2017

A Sound Plan Alpha?!

Hey guys,

Big news! I'm happy / worried to say that A Sound Plan has entered into an alpha state!

Feast your eyes on this!


...

Okay, maybe it's not that impressive. But the game is, as far as Dean and I are concerned, mostly feature complete.

In fact, if possible, there may even be a tournament for A Sound Plan tomorrow at Seattle Freeze, a local fighting game tournament! (Event Info)

Current plans will feature local versus and cooperative multiplayer (up to four players, teams of any arrangement), with game modifiers to make for some extra fun.

If I manage to get any footage up on YouTube, I'll post it to this blog.

Edit: Here's a video.

Thanks for reading!
Jimmy

Monday, January 2, 2017

Year in Review: 2016

Hey all,

I'm going to do a quick list of games I liked / didn't like this year.
I may go into more depth later, but I just wanted to write something quick this week. I left some quick notes for each game.

These are in no special order.

Games that were good:
  • Final Fantasy XV 
    • Exploration is fun, driving is interesting when characters have something to say. Exploration can get too restrictive, however, where the car cannot go offroad. There are lots of things to find in the world that don't pertain to the main quest. Chapter 13 changes up the gameplay in a bad way, doesn't make sense. Pulls a reverse Final Fantasy 13, in that the game starts open, and then closes up and becomes a hallway. Combat is fun once you gain the ability to air dodge. The ending made me cry, and I kept playing after the credits rolled.
  • Dragon Quest Builders
    • Minecraft with a goal. The game changes up locations just as you become bored. The core loop is fantastic, and there are many things to build that serve a purpose. I felt like I was really embarking on a quest.
  • Shantae: 1/2 Genie Hero
    • This one surprised me with its tight controls, solid variety, and its ability to compel me to explore places I've already been to with new powers. The story was never meant to be great. Some of the levels are truly unforgettable, so much variety without breaking the game's mechanics!
  • Let It Die
    • I never thought a free to play title would be on my top list of games for the year, but here we are. Suda51 tried his hand at a Dark Souls game, and it has all of the punk stylings that you would expect. The game also has many subversive elements to poke fun at games, and the fact that you are playing one. Subversive doesn't mean good, however, the rest is left to the games looting system, weird items, and solid combat. The game does have rough spots, however, with controls taking some getting used to, and you start to notice patterns in some levels. I personally enjoyed this game, but it may not be your cup of tea.
  • Super Mario Run
    • It's a solid runner, it has all of the polish that you would expect from Nintendo. Toad Rally is addictive, and the levels have replayability thanks to the coin system. It's $10 to get the full game, but it's worth the price if you like simple experiences.
  • Doom 
    • Holy crap, THIS is the Doom we remember! Intense combat, metal music, blood everywhere, and tight controls! This is one of my favorite games ever, not just recently!
  • Dishonored 2
    • CHOICE MATTERS! Go stealthy, be aggressive, it's up to you! It feels like Arkane Studios took lessons from the first Dishonored and applied some of them to the second game. Though far from perfect, Dishonored 2 has some creative levels, neat powers that are all useful, and two characters to play, each with their own powers. Controls are smooth, levels have multiple angles to approach a particular problem, and have sub-objectives that affect the mission in some way. The biggest gripe I have with the game is how much that writing is on the wall about "going stealthy is the ideal way to play", the designers should never tell the player that, let them figure it out.
  • Hyper Light Drifter
    • Beautiful aesthetic, mysterious world, tight controls, and solid combat that allows you to approach however you'd like. This game was a surprise for me, and was a total joy to play. This game allows you to tackle the areas in pretty much any way you wish, making your journey feel truly your own.
  • Dark Souls 3
    • Tight controls, mysterious world, freely available to explore, rewarding alternate paths, many side areas to explore, it's a Souls game, and the best one, in my opinion.
Games that were mediocre:
  • Uncharted 4
    • I have always been a fan of Naughty Dog up until everything after Jak and Daxter. It's yet another Naughty Dog game to me, in that the gameplay is in service of the story, and the gameplay is not really that good. Repetitive combat sprinkled with high spectacle, climbing got an overhaul from previous titles but still doesn't gather interest. Choice is not really a thing in these sorts of titles. The movie bit isn't that great, either. Comparing this game to a film will show how weak the story really is.
Games that sucked:
  • The Last Guardian
    • This one hurts, I wanted to like this game. The game is contingent on an AI partner being good at following directions, but the AI partner doesn't like to follow directions. It gets better by the end of the game (or it felt like it, idk, maybe I was punch drunk by then?), but even when the AI follows directions, you quickly realize that the game is just playing itself. The controls are really loose and slippery, it's hard to put into words. There always feels like a 0.3 second delay with each input. I must have lost 2 hours of my life to trying to tell the AI to do something over and over again. The story will make you feel a certain way. The puzzles are along the lines of the designer saying "Guess what I'm thinking?", whose solutions may feel arbitrary. Sometimes you'll have the solution to a puzzle, but the AI partner won't perform the action to complete said puzzle, so you'll try another solution, which won't work, then go back to the original solution, which will work! It's incredibly frustrating. The art direction is absolutely beautiful!
  • No Man's Sky
    • Holy crap, this is a lesson in how to piss off a bunch of people. The game is just a survival game in space, repetitive as chores, and slow as molasses. I feel like I can't add more to the conversation that hasn't already been said. On a positive note: the character I made is a space pirate with a crap ton of gold!
  • Star Fox Zero 
    • It's Star Fox 64 with crappy controls. Here's a lesson: Miyamoto wanted to make a game that was cool to look at, what he didn't realize was that Star Fox was already cool to look at. As a result of Miyamoto's interference, we got a game where you constantly have to switch between looking at the TV screen and the Wii U tablet to get all the information that the game has to offer. The reticle on the TV screen does not hit what it's aiming at. To barrel roll (insert meme here) or perform maneuvers, the player has to flick the right analog stick, which has VERY mixed results. The game overall plays slower as a result of the terrible controls, enemies rarely try to actually dodge your attacks, and boss attacks are slow.
  • Mighty No. 9
    • ...Do I really need to go into this one? Read the full angry review I made.
Overall, 2016 was a good year for gaming, here's to 2017! Didn't like my choices? That's fine, games are subjective, like all art.

Jimmy