Deploying SDL2 + GLEW Applications Using XCode Tutorial

Hey all,

So, in a sort of "Part 2" of what is now a series on SDL2 and XCode (first part here), I want to go over how to deploy an application that you made using SDL2 onto a store, like Steam of Itch.io.

The reason I'm writing this is for 3 reasons:

1. So that I don't forget.
2. I just finished A Sound Plan (Steam Itch) and had a real hard time getting this all together, and I don't want you, the lovely lovely reader, to suffer as I have.
3. There are virtually no tutorials on how to do this, despite SDL2's popularity and the rising rate of apps being made for OSX.

With that all said, let's get started.

You've just finished your game, it's a masterpiece and runs great on Windows and Linux, and you think deploying to OSX will be easy. You quickly realize that your previous assumption was wrong. You realize that OSX support of OpenGL is complete garbage. You realize that XCode is kind of a bad IDE, and that it's a miracle that anyone can make anything using it.

Maybe I'm the only one who thought those last two sentences, but you get where I'm coming from: The deployment process for this OS is completely different.

The first thing you may notice about any app in OSX is that they are actually a lot like folders, which you can peek inside and see all the lovely details. You can see this by right clicking an app and selecting: "Show Package Contents".

One thing you'll notice that's different from Windows and Linux executables: local files are not stored next to the executable, but rather in this "Resources" folder, and all libraries are in this "Frameworks" folder. Why does Apple organize things in such a way? I don't know, I'm not them, what a stupid question.

How do we get our files into those folders? Through XCode we can set up our build process as shown:

Notice the libraries are linked AND copied over.

How do we reference those files? Fortunately that part is easy (See below). Any files copied into the Resources folder can be referenced by prepending the value stored in path in the example below.
Example: "stuff.txt" would be referenced as: path + "stuff.txt"

CFBundleRef mainBundle = CFBundleGetMainBundle();

CFURLRef resourcesURL = CFBundleCopyResourcesDirectoryURL(mainBundle);

char path[PATH_MAX];

if (!CFURLGetFileSystemRepresentation(resourcesURL, TRUE, (UInt8 *)path, PATH_MAX))
  assert(!"OSX resource directory not found.");

CFRelease(resourcesURL);
 

chdir(path);

mWorkingDirectory = path; // Or just use path however you want. Just prepend to your local file names.

Last, and certainly not least, you may notice that if you try to run your application on another Mac, the app won't run, missing a .dylib or something. The reason for this is because of the install names of the .dylibs you used, these need to be set manually.

In Xcode, highlight your project, select "Build Phases":

Pictured: Click this in Build Phases

Add Run Script, and add lines like:

install_name_tool -id @executable_path/../Frameworks/libGLEW.1.13.0.dylib "$TARGET_BUILD_DIR/$TARGET_NAME.app/Contents/Frameworks/libGLEW.1.13.0.dylib"
install_name_tool -change /opt/local/lib/libGLEW.1.13.0.dylib @executable_path/../Frameworks/libGLEW.1.13.0.dylib "$TARGET_BUILD_DIR/$TARGET_NAME.app/Contents/MacOS/$PRODUCT_NAME"
codesign --force --sign - --preserve-metadata=identifier,entitlements "$TARGET_BUILD_DIR/$TARGET_NAME.app/Contents/Frameworks/libGLEW.1.13.0.dylib"

An explanation lies here, but basically you are setting the id of your .dylib, and then telling OSX what the executable path is for that .dylib. Code signing is optional if you are deploying via Steam or Itch.

Note: The first parameter after "install_name_tool -change" needs to match the install path of the library, or this command will do nothing. A good way to find out the install paths of your app is to run "otool" (included in XCode command line tools) on your app from the terminal.

With that, you should have a working app for OSX. Now get your game on Steam so I can review it, harshly.

Jimmy

A Quick Update

Hey all,

I know I've been gone for a bit, and yeah, that's my bad.
I know this post should have been a top ten list, but it's taking a bit longer than I expected, and I wanted to post this short update in the meantime!

Basically, two things:

• A Sound Plan will launch on 4/30/2019.
  Yes. Finally. Your eyes aren't messing with you, Studio Kumiho will be releasing something.
  Check it.(Please wishlist us, your support means everything!)
• Chang-e's development has taken off like a rocket, and I'm doing all I can to keep up! I'm so excited to show you all! Summer maybe?

Studio Kumiho has been really busy, we're up to 6 staffers now, and I think we're an incredibly talented group. I honestly believe this team is gonna make something amazing, keep an eye out here, and on our website, or Twitter!

Now, back to making games.
I love what I do.
I hope you're in a similar place in life, genuinely.

Jimmy

A Dangerous Precedent

Hey all,

So, I was watching a friend of mine (also a game designer) play The Legend of Zelda: Ocarina of Time, and he had various... complaints. Complaints that I thought were not... accurate.

He was complaining about how the game wasn't telling him how to solve the puzzles, where to go exactly, what room to be in, even to the point that the camera wasn't accentuating certain waypoints enough.

One token example, he was stuck in Dodongo's Cavern, unaware that he needed to drop bombs into the eyes of the giant Dodongo skull, despite there being a sign cryptically saying that the Giant Dodongo needed to see red to open the path, and there being holes in the bridge directly above the eyeballs, and the camera looking down (admittedly slowly) when the player walks near said holes. He had just acquired the bombs, the dungeon treasure, and had seen that the bombs explode in a red cloud.

The game was giving him the pieces, but didn't tell him EXACTLY what to do; the game led him to the location, but didn't tell him the solution, you know, a puzzle.

I still enjoy this dungeon.

So after talking to him about these complaints thoroughly, I came to a conclusion that a lot of younger designers fall for a particular design paradigm. The paradigm that I'm talking about, to avoid being vague, is...

"The player must know everything" or "The player must be told everything".

Modern video games have a tendency to overexplain and overcompensate in detailing scenarios and puzzles, in an effort to maintain the game's flow and minimize the player's boredom.

I disagree with this style of design, for many reasons, but primarily it goes against one of my game design rules:

Exercise the Brain: Learning is fun!

Players do not like to be talked down to, especially in a puzzle situation. How many times do you remember when people made fun of Fi from The Legend of Zelda: Skyward Sword? Getting all of the puzzle solutions and directions really killed the mood, at least for me, and a large portion of the internet.

"Master, a playtest in Japan shows that you have a 46% chance to solve this puzzle that you just saw on your own, so let me tell you the answer."

Disclaimer: I don't hate Skyward Sword, I just think there are some dumb things about it.

Why do I think that learning is fun? Good question. To me, I like to explain the fun of learning in this way: Remember the first day of school or work? Everything was new, including the trip there, and it certainly wasn't boring, now was it? That's because the human brain is good at consuming new information, in fact, it loves it! Learning new mechanics, learning about new countries or regions, or even learning about the trip to work, to your brain, it's all interesting, because it is LEARNING. Now, what about the 100th day of school or work? You need to find distractions away from your trip, because you know everything already, your brain doesn't want to waste precious energy on seeing the same stuff. Heck, you can probably do your trip without looking!

That's called "grokking", by the way. Also, that's why backtracking tends to not be fun.

For more details about this, I highly recommend reading Raph Koster's "A Theory of Fun for Game Design", it's a fast read and full of information.

Anyway, players like new information, and being told everything about a game, puzzle, etc. is the antithesis to that.

The goal should be to give the player just enough information, and then GUIDE them towards the solution.

A great example? Super Metroid. Remember the door that looked ominous and you couldn't get through without the High Jump Boots, well, without bomb jumping? That searing memory that you KNEW you needed something to help you through there? That was the hand of the designer leading you, not TELLING you!

Gunpei Yokoi will be missed.

Imagine how different this moment would have been if the game told you that you needed the boots here, or once you got the boots, told you to come right back here? Getting through would not have felt as good, now, would it?

You didn't know everything, and that was fine!

It's okay to not know everything about a game, in fact, I recommend it. But what things SHOULD the player know? In my opinion:

The player should know just enough to know what can be done, and enough to infer what needs to be done.

Great examples include:

• Super Metroid
• The Legend of Zelda: Ocarina of Time: Dodongo's Cavern bomb puzzle
• The Legend of Zelda: Ocarina of Time: Forest Temple's painting puzzle
• Catherine
• Dark Souls 

A bad example would include:

• Dr. Jekyll and Mr. Hyde

If I had to summarize this post, it's that treating your players like they have no memory, nor awareness, is not fun, for you nor the player. Leave a little mystery in there, players will love you for it.

Anyway, it took me forever to write this post, and for that I'm sorry. I've been busy handling Studio Kumiho stuff, you can check the website here. We have some exciting developments coming up, and I'm excited to share it with you all.

Next post will be another design focused one, and it's in everyone's favorite format: a top 10 list! /sarcasm

Thanks,
Jimmy

Whoops

Hey all,

So... I have some explaining to do, but I swear it's all cool stuff!

First off, Studio Kumiho is real! Visit our website here: https://www.studiokumiho.com/

Second, Studio Kumiho has been working with another developer on a project, but that's all I can say at this time. I will post here as soon as that project is announced.

Third, A Sound Plan is on break for about a month or two while we lick our wounds after being rejected from the Seattle Indie Expo for a second time. This feeling hurts a lot still, but I will recover from this and do better in the future.

Lastly, Chang-e is well on its way, hoping to have something to show by the end of the year. Until then, enjoy this:

That is all. I'll post a more substantial update someday soon.
Jimmy

Game Engine Design 101: Modularity

Hey all,

As promised, this month's (Quarter's? I don't know.) article will be another Game Engine Design 101. This time, we will be going over the topic of modularity.

This topic is a bit "in the weeds", and if you're not familiar with some of the topics discussed here, feel free to comment on this article.

How can you make sure that your engine can be ported to multiple environments / systems? You could use multiplatform libraries, but what if that library isn't compatible with a platform that you would like to port to?

What would we like to do?

• Separate out the platform specific code (ex. OpenGL) from the core engine code, to keep the engine code small.
• Maximize modularity.

This is where inheritance is actually useful.

SIDE NOTE: In general, favor composition over inheritance, consider which objects in your engine are a "has a" relationship versus an "is a" relationship. Example: A car IS A vehicle, a car HAS passengers.

The code examples from JFramework I'll be using are here:

• GraphicsManager.cpp
• GraphicsManager.h
• PCShaderScreen.cpp 
• PCShaderScreen.h
• Screen.cpp
• Screen.h 

The general idea is to create a layer of abstraction away from the actual platform specific implementation of libraries, i.e. abstract calls to OpenGL away from the core of the engine.

GraphicsManager HAS A Screen to render to, but if you look at the implementation of Screen, it has the most barebones implementation, in fact, there are no calls to OpenGL at all! Also, you can't even make a Screen in its own right, because it's an abstract class! The lines from Screen.h shown below are why it's an abstract class.

virtual void            ResetObjectTexture(Surface* aSurface, TextureData* aOldData, TextureData* aNewData) = 0;
virtual void            ResetObjectShader(Surface* aSurface, ShaderData* aOldData, ShaderData* aNewData) = 0;
virtual void            SetClearColor(Vector4 const &aClearColor) = 0;
virtual void            ChangeSize(int aW, int aH, bool aFullScreen) = 0;
virtual void            PreDraw() = 0;
virtual void            Draw(std::vector<Surface*> const &aObjects, std::vector<Surface*> const &aUIObjects, std::set<Camera*> const &aCameras) = 0;
virtual void            DebugDraw(std::vector<Surface*> const &aObjects) = 0; 
virtual void            SwapBuffers() = 0;

By doing the above, we're telling the reader / compiler: "You need to derive from this class, and implement these methods, all Screens need to have these implemented." Whenever a derived class calls one of these methods, the derived version will ALWAYS be called.

From there, we make a PCShaderScreen class, which derives from Screen. This class will implement the actual drawing to the screen via OpenGL. Displaying the code would be too much so just check PCShaderScreen.cpp. In this type of relationship, a PCShaderScreen IS A type of Screen, thus we use inheritance.

And now, the final piece of the puzzle: When GraphicsManager creates a Screen to display to, assuming we're on PC, it will create our PCShaderScreen:

GraphicsManager::GraphicsManager(GameApp *aApp, int aWidth, int aHeight, bool aFullScreen) : Manager(aApp, "GraphicsManager", GraphicsManager::sUID),
                                                                           mSurfaces(), mUIElements(), mTextures(), mShaders(), mCameras(),
                                                                           mScreen(nullptr), mPrimaryCamera(nullptr)
{
  // Add Default Texture
  AddTexturePairing(DEFAULT_TEXTURE_NAME, new TextureData(DEFAULT_TEXTURE_NAME, -1, 0, 0, "", "", Vector4(), Vector4(), 0, 0));
#ifdef SHADER_COMPATIBLE
  mScreen = new PCShaderScreen(this, aWidth, aHeight, aFullScreen);
#else
  assert(!"Needs screen for this device.");
#endif
}

And now any calls to Screen will call the derived version from PCShaderScreen, which will make direct calls to OpenGL.

NOTE:  The SHADER_COMPATIBLE macro is defined from the compiler, you can look up ways to do that, it's not hard.

So, what have we done?

• We separated the platform-specific implementation (PCShaderScreen) away from the core of the engine. (GraphicsManager)
• We used inheritance to extend a class (Screen) to be able to have a platform specific implementation (PCShaderScreen)

What advantages does this bring?

• When we move to a new platform, we can just not include our PCShaderScreen code, implement a new Screen for the platform, and move on.
• The code in GraphicsManager stays the same no matter the platform, and stays relatively small.

There, now our code is more modular, easy!
There are other cases that you can use this for, but graphics is the best example, relative to JFramework.

Note: I used hilite.me to render the code.

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.

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