How we got here.
At the beginning of 2013 we turned our little company Smithsoft down the indie game dev path. With careers in Software Development well developed us we knew it was time to live our dream and bring some of the game ideas that had been keeping us up at night to fruition. After saving up enough money to pay for food and a roof while we got going the first game Ethex2080 was started: an adventure game set in the year 2080. See a video of where we got to below.
Our plan with game dev was to make enough money to keep doing what we loved, and to get feedback from gamers so as to get better at doing it. Well, it turned out to be hard to even get a game out the door, let alone start making enough money to enable us to keep doing it. We think we did pretty well technically and game play-wise considering none of us had any game dev experience.
While working on this quite ambitious adventure game a lot of data needed to be wrangled. Each room has descriptions, Lua scripts, and numbers describing all sorts of game data values. At first in the very start a CoreData (SQLite) database was used. We figured this would be fast, and we could ship a database with the app, and copy it into the read-write area. Well it turned out to be a king-sized pain. All the boiler-plate to set up CoreData was just overkill for our type of app. It was probably fine if you were writing an address book, but for a game it was awful. Plus we had to write a custom tool just to get the data into the SQLLite store - every little thing that was new needed tweaks to the tool because it wasn't generic enough in its structure.
The game dev tools we were using like Texture Packer and Physics Editor not to mention the level editor CocosBuilder all used plist files. And XCode has a handy plist file editor so it was a no-brainer to switch. Wow - it was so much easier using plist files compared to a database.
Then we started running into another couple of problems. First our writer was working on a Windows box and could not use XCode to create files. Second XCode was a big hammer for the plist file problem. Starting it up every time I wanted to work with the level design took me into the coding environment for the game which was not where I wanted to be. We were trying to keep the engine of the game seperate from the data. XCode's window for editing plist files was a pain too - strings had to be squashed into a tiny field and I could not see all the plist files in the project.
I spent a week and hacked together a Plist editor and made a Windows build for it (using the cross-platform toolkit Qt). It was rough and ready and full of bugs, and it only handled XML format files, but it was already better than XCode as it had a large window for our Lua scripts. Plistinator was born!
In October of 2013 we realized that we needed to take break from Ethex2080 and get some more funds before restarting it. We felt really good about what we'd acheived but seeing the amount of work still ahead made us realize we needed to collect our thoughts, and try to get a bit of money coming in again before we restarted. What about Plistinator? It was pretty cool, and if we could get it to commercial standard, we were sure other folks would think so too.
Bringing Plistinator up to commercial quality took another 3 months of hard work. Adding in all the things that folks expect from a paid-for tool took ages:
We had to put some things on the wish-list of future features - things that even though we know would be super-important and useful we could not justify until we get Plisinator earning its keep:
One big hurdle for us was getting Plistinator in to Apple's Mac App Store. Apple requires all Mac App Store apps to run under the security sandbox. Here's how the sandbox works: when an app launches it is restricted to only access files inside a special directory called the Container. Usually the path for this directory is something like /Users/joe/Library/Containers/com.mycompany.appname.
OK, but how do you get any work done? The answer lies in the magic way Apple has used the humble File > Open dialog. Usually your program calls for a file-open dialog to be displayed and it is inside the memory space of your program. When in the sandbox, your restricted app calls file-open and the Mac operating system opens the dialog for you outside of your program and running as a privileged, non-sandboxed process. It looks like its part of the App, but its actually running outside it, under the control of the OSX system.
Because the file-open dialog is outside of the app, and is privileged, it can access any file that the user can navigate to. Even more cleverly, once the file has been opened, and passed back to the app (which remains cooped up in its container) along with the file comes some special credentials called a security scoped bookmark. These credentials can be saved by the app, so that even after the app has been opened and closed again the access rights to the file still exist: handy for Recent Files functionality.
We got the file opening and bookmarks saving down without too much pain. In order to get Plistinator's directory view pane working with the App sandbox, we had to jump through some hoops: when the pane is first opened we pop up a file open dialog so that the user of the app can provide permission. This then provides access for that folder and everything below it. But it was a lot of work to get it all working. On top of this is all the App signing and entitlements and slew of other Apple requirements, just to get access to the App Store. If you're interested in the deeper technical details check my article on getting a Qt app into that app store.
We've tested Plistinator on the following Linux distributions:
We see Plistinator as something bigger than Just Another Plist Editor. We have plans for it (see the Planned Features above) that we hope will make it super-useful in ways that are downplayed when thinking of it as just an editor. This is why the big emphasis on Structured Data.
You know writing a data driven app or game is the right way to go, but then when the time pressures bite it always seems that taking short-cuts and hard-coding all that data into your app will get you there quicker.
It sure seems like just using string tables, or some JSON file will get the job done. My experience tells me otherwise. This is why we say Plistinator is a tool for structured data, not just A Plist Editor since first off not everyone knows what plists are, and many more don't know how cool they are as a way of getting data into your game or app. Anyway if you want to read more about that check out the page on the plist format for details.
It'd be great to hear how Plistinator is helping you get your app or game data problems sorted, and making development fun again. Got stories? Let us know!