Monthly Archives: September 2021

Fixing the SFML Template in Xcode 12-ish

Posted on by

When I was trying to learn Unreal, I wanted to learn more C++ so I would feel comfortable working with the scripting. The book I was working through used the SFML library for building games. I was going to try to set this up in Visual Studio Code, but the SFML website recommends using Xcode. They even have a template and a tutorial about how to install it on the Mac.

I had some concerns about the template as the website says it will work in versions of Xcode above 4 and we just got version 13 a few days ago. (I didn’t update yet and had to look it up quick.) I thought it might need some work, so I tried to build the project directly after creating it and got a bunch of linker errors and other shenanigans.

I went to my husband (who has way more experience in this area than I do) and he spent like ten minutes fixing all the stuff that was wrong. (Side note: I am unsure if I would have figured this out on my own. I don’t know a lot of people who would have because most of the programming community has experience with high level abstractions that are maintained by people like my husband. Low level experience is hard to find!!)

I don’t think there is a massive glut of people who are chomping at the bit to do SFML or C++ development on the Mac, but if anyone is curious, here is a list of the changes I had to make to get the template to build in Xcode 12.ish.

Move the info.plist and Create a Resources Directory

Once you create a project using the SFML App template (which creates and entire application bundle and not just a binary), the first thing you will notice is that there are a bunch of disconnected resources in the resource navigator:

Screen shot of the file navigator with disconnected resources.
File Navigator with disconnected resources

This is one of the more simple problems to solve.

  • Move the info.plist from the Supporting Files group and place it directly into your main directory.
  • Delete the Supporting Files Group
  • Right click on the project in the resource navigator and choose “Show in Finder” to reveal the directory in your file system.
File directory with the incorrect configuration
File directory with the incorrect configuration
  • Create a “Resources” folder inside the directory
  • Move the four disconnected resources into this directory
File Directory with the correct configuration
File Directory with the correct configuration
  1. Go back to Xcode and use the file inspector to change the resource path for each asset.
Incorrect file path
Incorrect file path
Correct file path
Correct file path
  1. Restart Xcode. It won’t really “take” the resource path change until Xcode reboots.
Final version of the project navigator
Final version of the project navigator

To be fair, the only really “necessary” part of this process was to move the info.plist. If you deleted all the code in the main.cpp function, you would not need these assets and could simply delete them. But I like to get the project to a known good state and just wanted it to build as expected.

So this was the easiest fix. Next up is digging around in the build phases.

Build Phases

This section has to do with a discrepancy in how you are told to install the framework versus how the template assumes you have installed the framework.

First, navigate to the build phases in your template application and expose the Run Script:

Build phase run script that is incorrect
Build phase run script that is incorrect

SCREEN SHOT OF THE BUILD PHASES

The script is set up to look for your SFML header files and libraries in the file path “/Users/SFML/Desktop/packaging/tmp/install/Library/Frameworks”. But if you follow the directions used by the SFML documentation, the file path for your frameworks should be “/Library/Frameworks”.

My preference is to keep all my frameworks where they are supposed to be instead of creating a temporary folder on my desktop, so I change the first three settings to reflect the actual file path.

# SETTINGS SFML_DEPENDENCIES_INSTALL_PREFIX="/Library/Frameworks" CMAKE_INSTALL_FRAMEWORK_PREFIX="/Library/Frameworks"

CMAKE_INSTALL_LIB_PREFIX="/Library/Frameworks/lib" FRAMEWORKS_FULL_PATH="$BUILT_PRODUCTS_DIR/$FRAMEWORKS_FOLDER_PATH/"

Corrected run script
Corrected run script

”Provisioning” and Code Signing

Alright, I am aware that Apple has been pushing people to build universal apps that work on both the Mac and the iPhone. I have been fairly open about the fact that I have not been keeping up with everything going on the past few years, so I don’t know if things are different for provisioning. When I was still an Apple developer, I only did provisioning for iOS as that was the only job I had for most of my career.

My understanding is that the rules have relaxed somewhat when it comes to having profiles for just building to your own devices. At some point I will document getting an actual provisioning profile for the Mac when I have something I want to ship, but you have to have something in place in order to build on your machine and this is my shortcut.

  1. Go to your Targets->Build Settings-> All -> Levels -> Code Signing Identity.
How to find the code signing identity
  1. Select “Other” from the drop down menu.
I am fairly certain we tried the “Sign to Run Locally” option and it didn’t work and we didn’t debug it. I don’t think we were that stupid to not try it. /Snark
  1. Delete everything in the script
Empty code signing probably won’t get you through the App Store approval process, but at this point what will?

This is absolutely not a best practices thing. This is a total hack. This is my “I want to practice writing C++ code on my Mac and I want to see if it builds or not” hack. I will eventually have to figure out code signing and other bullshit if I want to ship anything I write here, but for my own narrow purposes, building is sufficient. If you already have this set up properly or I am doing something completely idiotic, feel free to ignore this or mock me.

Keyboard Input in Catalina

At this point your template project should build. Mazel Tov. However, if you want to run it you have one last bit you need to do.

In Mac OS Catalina, there were some changes to the permissions for allowing other applications to receive input from the keyboard while other applications were running.

The first time you run an SFML app, you will be prompted to give the application permission to use the keyboard while it is running concurrently with other applications. When I did this, I was dumb and made my game take up my entire screen, so I didn’t see the prompt. So even though I was clever and added keyboard monitoring to quit the program if I tapped “Escape,” I didn’t get the prompt to enable it, so the application had to be forced quit. D’oh!

So make sure to either enable this in the Security & Privacy settings or make sure your game is smaller than your screen so you get the prompt to do so without digging around in the settings.

I blocked out my “secret” project I am probably going to write about next week.

Conclusion

I am aware that I should probably put in a pull request to implement these changes on the actual template that is accessed by developers, but I don’t really understand the process of updating a template. I grok some amount of how to update a code base, but this is slightly outside my area of expertise. The Husband has some experience with maintaining open source projects, so some day when we both have a spare spoon he is going to help me put in the pull request. So it will probably happen after The Singularity.

The Engines of Creation

Posted on by

One of the biggest roadblocks I have encounter while trying to learn game development is dealing with an engine. My background is in iOS development and Xcode is sort of a happy medium between an IDE and an engine.

I didn’t quite understand a lot of how all the pieces worked together and talking to people whose only context about development was from games didn’t help much because people just didn’t have a mental picture of doing things any differently.

So, after several years of exploring various engines, my decision at this point is that I don’t want to use any of them.

Here are my reasons for not wanting to use the ones I am most familiar with:

  • Unity: Oh god, where to begin. I started with Unity and tried to learn it over the course of several years and I just don’t like it. I don’t like the user interface. I don’t like the gray box level builder. I don’t like their code frameworks. I don’t like C#. I additionally do not like that they keep adding multiple ways to accomplish something and then stop supporting them, leaving developers to hope they picked the right way and it will keep working moving forward. I talked to a bunch of indies who have used Unity for a decade and none of them thought any of this stuff was an issue. It was simply the way things are and you get used to them. I didn’t want to get used to it and wanted to find a better way.
  • Game Maker Studio: I want to start with 2D because my art skills are not great yet, so GMS was an option. It seems somewhat easy to learn and use, but it utilizes a proprietary scripting language and it charges you money for its use. Neither of these is ideal. Also, one reason I was interested in GMS was because I read Spelunky was created in it. After reading Derek Yu’s book about Spelunky, I found that he prototyped it in GMS and then actually built the version I play with in a custom engine. So this doesn’t seem like a good long term option.
  • Unreal: I will be honest, of all the engines I tried, Unreal was my favorite. I liked the frameworks. The shader builder was slick. The interface was nice to use. It actually works because the people who built it use it to ship games and things don’t just fall into ruin. It also open sourced its code so you can look at how things work and put in fixes if necessary. My only real issue with Unreal was that it is designed around larger teams doing 3D shooter games. A lot of the code is abstracted away to facilitate teams with a bunch of non-coders. In order to set up a 2D game I would have to position all the elements in 3D space and set up a camera. I really don’t want to do that. I loved learning Unreal while I was working with code, but once I had to work with the gray box environment, my brain would just black out. I’m sure there are ways around using the gray box, but I am too frustrated to deal with them right now, so I am considering revisiting Unreal once I have more experience building things.
  • Godot: I was under the impression that I had to use a language I do not know for this, so I didn’t seriously explore it. I will revisit in a few years as it seems to be changing and advancing quite rapidly.

While I was trying to learn Unreal, I realized I don’t feel comfortable with C++ code and syntax, so I decided to actually take a deep dive into the language. Everyone was warning me away from it because “It’s terrible!” But I didn’t actually find it to be so. I know the warnings are from people trying to debug code other people wrote that is in production and so forth, but I found the actual language to be well designed and similar to languages I already know and like. I am sure I will grow to hate it as others do, but for today I have found it surprisingly pleasant to work with.

I worked through a book on C++ game development that used the Simple Fast Media Library (SFML) to place sprites and do rendering. This library also felt very intuitive to work with. I found working with this language and this library to be the most intuitive way for me to work on games. So this is the combination I will utilize for at least the next year.

SFML also has a template that can be applied to Xcode to allow me to use Xcode for SFML development. I spoke with one of the maintainers on Twitter who indicated that I can build code I wrote in SFML to desktop and mobile devices. At this point I don’t need to ship to a console, so this is sufficient for my needs.

I don’t know if this counts as building my own engine or not. I’m trying to avoid touching low level rendering as that is a rabbit hole. SFML wraps OpenGL so I don’t have to get that working to build games, so there is just the right amount of abstraction for me right now.

A lot of the past couple of years has been me trying to force myself to learn stuff that doesn’t go with how my brain works. I logically understand that using an engine gets you a lot of advantages. But most of the big ones are not designed for people like me. For better or worse, I think in code. I have never been good at thinking about things in 3D spaces and I really do not like how the engines are designed around building visuals in these spaces and attaching scripts to them. I understand if you are building Fortnite that this functionality is vital, but it’s not if you’re building Candy Crush.

When you are learning a new skill, it can be overwhelming because there are fifty things you don’t understand. Knowledge comes from slowly learning bits and pieces of these things and winnowing them down until you don’t understand a third of them. Then you stop noticing the things you didn’t know before and can focus on the few things you still need to understand.

My hope is to spent the rest of this year and all of next year building small games. I would like to “ship” them by uploading them to something like Itch.io and selling them for a buck. I hope that after I have done this three or so times, I can come back to something like Unreal and feel more comfortable with the interface as I won’t have to learn the language and how to build a game.

If you are struggling to learn something you really want to understand, it’s okay to think about why you are struggling. Is it the tools? At what point do you just give up on something even though you don’t want to? Is there a way around the thing you don’t want to do? Not everyone thinks the same way and it is totally okay to pursuit a different direction if what you are currently doing isn’t working.

Change is Hard

Posted on by

About once a year since I started working on my Metal book, I think I should get back to my blog. My blog was an important tool in my learning process at the beginning. I don’t know if anyone read it or got anything useful from my fumbling with learning the Cocoa frameworks, but it did give me a spot where I could work through what I was doing and write it out to better understand it.

While I was working on the Metal book, it really didn’t make a lot of sense to write on my blog because I was writing a book. Anything I learned was going into the finished product. I didn’t have much to say and figured I would get back to things once I had something to talk about.

Then came the burnout.

I burned out before the pandemic, which was a blessing I guess? After spending a year converting gin into prose, I really didn’t want to come back here and try to find some piddling thing to write about with some tiny project illustrating something. I was tired. I didn’t want to produce content anymore. I also wasn’t really sure if I knew how to create and present content to teach people stuff. And I really didn’t think I wanted to anymore.

I got into writing at the beginning because I had a liberal arts degree and I knew I could write. I figured any questions I had as a beginner would be pretty common and so I could document my learning for other people so they would not have to talk to people who didn’t remember what it was like to not know something.

I figured if I kept doing this, eventually I would get better at things. I don’t feel this was correct. I was so focused on producing content that I never really focused on doing anything. I looked at code I wrote in 2015 and I am blown away by how much better my code was in 2019. It was depressing.

I had to make a choice. I had to decide if I actually wanted to be good at something or I wanted to invest all my energy into pretending I was good and hope no one noticed. I don’t want to pretend. I want to actually be good. I don’t care if I get invited to speak at conferences or write books right now. I just want to be good at what I do.

So I took a step back.

Last year, along with everyone else, I got super burned out. I took a five month sabbatical from writing code to learn to draw. I decided to start a new project at the beginning of this year after I got my shit together.

I sat down in December last year to work on a game jam. Everyone I know in game development says it is a great learning experience. I felt ready.

I was not.

I sat down and immediately realized I didn’t know how to do anything I wanted to do. I could do bits and pieces, but I couldn’t connect them together.

I wasn’t ready.

I have spent most of this year going in and trying to figure out all the stuff I didn’t know how to do. I had a horrible realization that most of my mobile development knowledge doesn’t translate to game development. There is not a common language or common design patterns. I had to almost start over.

I am still not sure if I am ready, but I think most of my lingering questions have been answered to some degree. I am going to start. I hope I know enough that when I encounter something I don’t know, it is a small layover and not something that stops me in my tracks.

My current goal with the blog is to write once a week at least about what I am doing. I bitch a lot about Agile on Twitter, but I don’t object to the process as it is described, merely how it is practiced by most companies. I think laying out a set of tasks to complete and updating people regularly about your progress is an excellent way to get things done. I plan to write about what I did, what I need to do next, and why whatever I was supposed to do didn’t actually happen. Life happens. People get sick. Holidays happen. It isn’t necessarily important for every day to be a blockbuster. You simply have to be consistent and try your best to do something every day, even if it’s small and even if it’s just recovering from a cold. I don’t expect anyone to gain anything of value from anything I write here. I write for myself and to stay on track for myself.

At this point, I don’t anticipate returning to iOS mobile application development. I got really excited about it during a time when Apple was releasing game frameworks and had lots of new and exciting graphics stuff. As time has gone on, I have observed most companies either dispensing with iOS native code altogether, or simply using it as a front end for data pulled from a server. This isn’t really what I want to do with my career, so I am following a new path rather than trying to convince people to follow me in a direction that leads nowhere. If Dave Verwer wants to remove me from his list of iOS developer blogs, I completely understand.

I have some plans for blog posts for the next few weeks. I hope to figure out other stuff to include after those ideas run out.

This transition has been hard. It has been going on for several years. I feel silly constantly talking about how I am going to change things. Change takes time. Change takes spoons. But here we are. I hope to not write another post like this in six months. I want this change to take this time.