Forgotten Tale Forgotten Tale

Let's Try That Again

I apologize for being behind schedule. Last week I discovered that my SSN had been used to file a fraudulent tax return.

I spent most of last week going over that, checking things, filing paperwork, and generally stressing out over the stupidity of identity theft.

It looks like a hack to an employment agency earlier in the year is the culprit for my SSN getting out.


Everything has calmed down a bit, so, let's try to get started this week instead.

The State of Things to Come

Starting this week I’m back to doing the weekly Forgotten Tales (short stories). I really did enjoy doing them, and think they can be a worthwhile effort. While I won’t guarantee I will have a new one out each and every week, I should have one out most weeks.

As for the audio readings, it will be a few weeks, but I will get them done and caught up.

On the game engine front I’ve had to scrap the proto code a few times in deciding how I want it to work. Should have made that left at Albuquerque. I have a really good idea of where I want to get to now but not sure exactly how to get there.

I’ll probably just whip together a few small adventure games with SDL and start reworking sections of the codebase and adding tools as I need them.

You can expect upcoming posts going into more detail on the game engine, future plans, copyright license, business model, and the like.

Now if you’ll excuse me, I need to go work on my taxes.

Dev Environment Revisited

So after a few weeks of using the dev environment that I talked about in my last post I’ve modified it and revised it thusly (anything to say the terrible word thusly in a post).

Code Repository

Since I started this, I’ve always had a concern over security and privacy with what could be very sensitive data on Dropbox, so I’ve stopped using it to host the code.

Don’t get the wrong idea, Dropbox is a great service, and I use it for a lot of stuff. It’s just not as completely secure as you might think it to be (which has it’s pros and cons). So things like taxes, financial information, and other sensitive non-encrypted data probably should not be stored there (well encrypted data, like 1Password, should be fine for most intents and purposes).

This brings me back to how can I get the code on multiple machines when I need to.

I generally work on the Mac, but on occasion I work on a Windows machine as well. I still don’t want to use GitHub since I want to have my own simple versioning system, and something down and dirty to use and learn. Due to the nature of the two OSes, I also don’t want to open my Mac to network file sharing since it would require me to reduce the security of the machine (cough, cough, windows, cough, cough).

So I decided on a little trick to be able to version my code, backup my code, and also have it available on multiple machines all in one go.

The process is relatively simple. Using a shell script (Mac) or a batch file (Windows) I can create a zip file of the current source code, put the current date in the filename, and place it on a networked drive. I can achieve all of that from within my text editor or at worst a terminal/prompt window with one command (which I usually have open anyway).

This gives me a backup copy of any given days work in a central location.

It’s not perfect yet since I still have to go and retrieve the code and replace the code on the local machine after I work on another machine. Which I should create a new shell script/batch file now that I think about it.

These scripts have taken more time then I thought they would. I spent one whole evening last week getting the batch file to even work just to find out all I had to do was close and reopen the command prompt (cough, cough, windows, cough, cough).

While limiting, these scripts are amazingly robust. Once I finish them I will be releasing a version of them for people to look at and use if they want to.

One may ask why not just create a program to do that. I should, and maybe someday I will, but right now I just want something that works and can easily be modified if I need to make minor adjustments.

Dev Environment

I've spent a good bit of time this week getting my development environment setup. It's not to the final shape that I would like, but it is in pretty good working order. I'm now able to actively code every day so that's a win.

The Machine

The development machine I'm working on is a 2012 Mac Mini with a 2.5Ghz Quad core i5, 16GB of RAM, a 1TB 7200 RPM hard drive, and outputs to two Acer 1080p monitors.

I've put this machine together over the last year, and for a machine that cost me less than $1000 all included it works pretty well.

The only downside is the Intel HD 4000 integrated graphics. Thankfully I'm just doing 2D graphics right now so that downside has little effect. Sadly it limits what other games I can play on the machine, but it's a work machine so that's a good thing, right?

The Software

For now I'm compiling and executing using Visual Studio 2013 Community Edition on Windows 7 in VWware 11 running in Unity mode. What a mouthful.

I've setup the virtual machine to use half the resources of the Mac so I can get decent performance (so 2 cores and 8GB of RAM). I also have VMware running in Unity mode which allows me to have all the active Windows programs in their own Mac window. This is really nice since all I have to do is cmd-tab over to any Windows program instead of messing with keyboard shortcut changes or clicking on the virtual machine window and then clicking on the program.

As for code I'm using BBEdit. BBEdit is just awesome and beats the pants off pretty much any other text editor (Mac or otherwise).

The Process

Ideally I would have a Mac port working and just shell script from BBEdit to build the game as I'm coding (to avoid having Xcode open all the time to just jump over and click compile and run). At the moment I'm too unfamiliar with command line compiling on the Mac and working around Xcode projects in general to get anything done. I've shelved doing that until I have time to devote to figuring it out.

Currently I write the code in BBEdit and save the file into a location on Dropbox. I am thinking I will switch this over to iCloud Drive, but this has little impact since they both work effectively the same.

Then I go over to a Windows command prompt to execute my build.bat file which compiles the code. Since the code is in Dropbox, I don't want it to build in Dropbox. I could just tell Dropbox to ignore the build folder, but that could be tedious and error prone. So instead I compile into a local directory and run it from there. Currently I've setup a virtual drive to whatever local folder I'm using to make life easier.

Once compiled (which takes like 2 seconds) I go over to Visual Studio and run the program in debug mode.

One of the awesome things I picked up from Handmade Hero is separating the game code from the platform layer. if the game is already running I instead just go over to it and check it or preform any testing since once the changes are compiled the game just updates automatically.


Obviously I would like to get the Mac port up and running with command line compiling tools on the Mac using BBEdit.

After that, another thing I would like is to use LLVM to target compile for another platform and compile straight onto a networked PC from within BBEdit. This would allow me to code and compile using the Mac and just turn around on my desk to a networked Windows PC and see the results.

Lastly, but really firstly, I need to setup a daily backup scheme for version control. At the moment I'm thinking I will just create a .bat file that I either run manually or have setup as a daily task.

Why the cloud?

The primary reason is to have an extensive backup option.

Having the code in the Dropbox folder allows all my changes to be propagated quickly amongst any machines that I may use (multiple local copies), plus grabs it to store online (Dropbox remote copy), Time Machine grabs it (local versioned backup copies), and my online backup, Backblaze, grabs it from several computers and stores it online (multiple copies in a different remote location).

A secondary reason is this allows me to continue coding on another computer, code on the go, or compile a local copy to say demo the game on another machine.

Why not git?

Honestly? Because I don't really need it and it's a pain in the ass to learn and use. I can easily create my own version control system, and BBEdit has a nice file dif function.

Why not CMake?

I'm not using CMake because I'm unfamiliar with it, and it takes a bit longer to compile. I also want to learn the manual process for each platform right now so I know what's going on.

I might consider using CMake in the future, but probably just for the game code and only to do the cross-platform builds.

Development Blog

I've done some development blogging on this site already, but starting today I'm going to start separating it from the rest of the content. At first this is going to be internally, but sometime soon I will have a different link for the development entries.

For the time being all development, regardless of project, will be in one set of posts. In other words I'm not going to do different development blogs for my different games/projects.