Since I’ve created a personal site, it’s time to go through and update this site this site to get rid of any cruft. This will probably be finished over the next week. I will also be switching this site away from github in the near future.
I’ve removed all of the Forgotten Tales from this site and moved them over to my personal site. I have not bothered with putting in redirects. There has always been so little traffic to them (and I’ve not added a new one in over half a year) I doubt there is any old links sitting around that would confuse people (also part of the reason for this post).
Apple announced the “new Apple TV”1 yesterday and I thought I would take a few minutes and ponder about it as a game developer. Apple says it will be released in late October so it won’t be long before we find out about a lot of this. Possibly even sooner since “dev kits” will be sent out soon.
What is It
The new Apple TV is the long awaited update to Apple’s “TV hobby.” It’s a relatively small “puck” sized device (though now it’s a very tall puck) that hooks up to any HDMI equipped HDTV. With it they are bringing a slew of new features such as Apps, an App store, Siri, improved remote with touch and TV controls, and much improved hardware.
But is it a Game Console?
There was a bit of speculation before the event yesterday that Apple would be targeting the Apple TV as a game console. While the Apple TV does indeed play games, it is noticeably not designed or targeted at being a game console. Look at the lack of an included game controller and using the A8 chip instead of the A9. Though, much like the iPhone, I’m sure it will be a very competent game device.
The New Remote
The Siri Remote (not to be confused with the Apple Remote which is its “predecessor”) is the new control device/scheme for the Apple TV.
While having not used one, this looks to be a nice upgrade to the Apple Remote. Besides the Siri functionality, the touchpad looks and seems to operate similar to a one-click Magic Mouse or any of the traditional trackpads Apple ships. There are also three new buttons in addition to the standard Menu and Play/Pause buttons. One for volume (a dual, or rocker style, button), another for TV input, and a third for the aforementioned Siri functionality.
The Siri Remote also has motion controls built in making for a potential Wii- or Move-like experience.
This new remote has the potential to be a simple game controller / mouse-like device. If Apple had chosen to stick to the Apple Remote, really, the Apple TV would be a joke as a game machine.
My only serious question about the remote as a game controller is the sensitivity and programmability of the touchpad. This could really make or break using it as a viable controller for a whole host of games.
So, Game Controllers?
The Apple TV also supports MFi game controllers first introduced with iOS 7. Sadly Apple doesn’t make it’s own game controller. The Apple TV also doesn’t ship one with a game controller of any kind (or even have the option to). This posses potential problems and downsides since the only controller you are guaranteed to have is the Siri Remote.
On a positive side you can require the extended profile game controller for any particular game (these are 3rd party controllers similar to any PS3/4, Xbox 360/One controller) which is a welcomed departure from iOS which requires all apps to use the touchscreen.
On the negative side... App Store Policies (shocker!).
Oh, App Store
One of the interesting choices made by Apple is how games will be displayed in the Apple TV App Store. From my understanding of the documentation, if you require a game controller, and if a game controller was never synced up to your Apple TV, then you will not see any of the games that require a game controller.
This decision grates with me on so many levels. There are so many ways that you can clue a customer in that this game will require a game controller that it shouldn't be an issue just listing them with the rest of the games.
For example, these games could have an icon or color outline that indicates that a controller is required. In addition you could just warn the customer before they buy the game that it will require a controller if they have never synced up a controller before.
This can also negatively skew sales of game controllers (and thus the games requiring them) by hiding them away. If people saw that some games require a game controller they may actually go out and buy one. Apple could even jump them to a page on their own store with several controllers listed that they could just buy and pick up at the local Apple Store or have shipped. Win, win!
Yes, I know Apple is loathed to do things like this, cosmetics, design, experience, etc. I just believe that there are very valid reasons to do this, and that it could be done within Apple's strict guidelines.
Update: Apple has revised it’s policy and no longer allows the requirement of a game controller. Everything must be at least playable with the Siri Remote. To be honest this is not a surprise given Apple’s track record and desire to have everything just work. Oh well.
200 MB Limit
In order to keep space for plenty of apps, streaming data, and general caching, Apple is instituting a 200 MB limit for app downloads. You might be thinking that this kills the ability to have games on the platform, but that would be mistaken. This is where Apple’s new APIs from WWDC come in. With App Thinning, On Demand Assets, and the like, you should be able to get a lot of executables below that limit and just stream in the rest as needed (which have no restriction as far as I can discern). If done poorly this will give a negative experience, but that’s the challenge.
Keep in mind that unlike the iPhone, the Apple TV can be reasonably assumed to have a decent internet connection. You should avoid thinking this means everyone has a 40Mb or higher connection, but at least reasonably sized asset chucks should pose no problem.
Also, even though there is no persistent local storage on the Apple TV, unless someone downloads a lot of apps or games, there is a good chance that assets for your game that you need will still generally be there since they are only removed when space is needed.
Or, what the hell Apple, why not the A9?!
I have seen some argue that cost is the primary reason they choose not to include the brand spanking new A9. The difference between the cost of those chips, especially at the capacity they are being produced in, is not very significant for that to be a deciding factor in my opinion. It could affect profit margins a little, but I don’t see Apple wanting to price a thing at say $159/$209 to make up the difference.
There is only one logical reason I can figure as to why Apple would skip the A9 in the Apple TV. Manufacturing.
The A9 is the new hotness that is going into the iPhone 6s, and the iPhone is always supply constrained during its launch. Since the Apple TV will be coming out at the same time, even Apple with it’s great manufacturing skill and capability would be hard pressed to include enough chips for both product lines.
I’m sure there are other, secondary, reasons as to this decision. For example, I’m sure Apple wants to leave the A9 as a signifier of the iPhone 6s (a marketing concern). I’m also sure that this product was almost launched during WWDC, which means that the choice for hardware was decided a while ago and doing a last minute change could affect it (though it has happened before at Apple).
Why Did it Grow?
How much you wanna bet that the increase in height of the Apple TV is due to an over large heat sink or a fan?
I’m thinking that the Apple TV will indeed sport a very quiet cooling fan, à la Airport Extreme. This can be helpful in multiple ways, such as a custom A8 chip with multiple cores and/or an overclocked A8 chip. I’ve seen Apple indicate different core counts with prior Apple TVs and iPod Touches, so I think it unlikely that this A8 has more cores. An overclocked A8 seems more likely.
How powerful is this thing?
Until we get some benchmarks it’s impossible to say. Given what we know, we have information from the iPhone 6 which uses effectively the same chip.
I’m guessing that they do indeed have a fan in the Apple TV, which I think they have clocked higher then the chips used in the iPhone 6. Since a power source and battery life are not concerns with the Apple TV, I’m guessing that other optimizations (or the removal/gating of optimizations) to potentially draw out more power from the chip is in place.
Since we don’t have to account for older devices like on the iPhone or iPad, the A8, especially a modified A8 like I’m guessing, should give us some very nice potential. Not on the scale of a PS4 or Xbox One, but games that in some aspects rival the PS3 or Xbox 360. In many aspects, such as RAM, texture quality, and bandwidth, excelling those older consoles.
I know for one, I’m very excited to get my hands on the Apple TV. I’ve been waiting for a replacement for over a year, and with these new features this could be a very exciting box to have. Still so many questions…
Here’s hoping Apple took gaming at least a bit more seriously and gave us enough power to do some really cool things on this box.
1: Forever after referred to as Apple TV. The old ones will just get plastered with their generation number or the dreaded “old” moniker.
I currently use Squarespace for hosting this site. Squarespace is an awesome service and if you need web hosting you should always check them out.
At this time it was not worth the cost for me to stay with Squarespace. I’m not using any of the features, I designed the look and wrote the code for the site myself, and I want non-costly options for secondary sites if I need them.
So this week I made the decision and transferred the site to GitHub Pages.
I’ll save you the details, but some of the background technologies that each use required me to peck at the code and do a bit of trial-and-error. If you visited the site over the last couple of days and weird things happened, that would be way.
Suffice to say, the transfer is done and everything should be working fine. The only missing feature currently is the podcast element to Forgotten Tales. That requires me to hook up to another service which I will save for tomorrow.
Over the last decade, it has become painfully obvious that Nintendo is ill-equipped and mentally incapable of competing in the hardcore gaming market.
Like many of us, Iwata was resistive to leaving that market. He went up on stage and lambasted the mobile market and the effect on game prices and quality.
Either out of fear of being ousted, or from a personal revelation, Iwata has now decided to take Nintendo and transform it into something new, and wholly different.
Nintendo is now becoming the company of “fun” and “games”. No longer worried or shackling itself to the bounds of what was (a recurring motif at Nintendo), but instead heading off in a new unproven direction.
Last year’s E3, the surprise announcement of a new system and the development of mobile games, and this year’s E3 go a long way to show us just how far Nintendo has changed and opened up.
Like never before, Nintendo is allowing people outside of the company relatively free rein of some of their properties. Even as far as encouraging them to do something new. Take the case with Browser and Donkey Kong for Skylanders.
Looking at this year’s E3 Digital Event, most of the games were not about story, or grit and grime. They were games. Purely simply games designed to be fun and happy.
The most interesting thing is that the core of Nintendo has never changed, and remains intact. It’s just everything around that core is transforming. Iwata is betting that what makes Nintendo great will always keep Nintendo great regardless of platform or business model.
Nintendo is embracing this new world, and only time will tell if they have chosen wisely.
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.
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).
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.
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.
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 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?
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).
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.