About eight months ago, I had an idea for an iOS racing game. It was going to be pretty cool, with some interesting new time trial mechanics, a mysterious atmosphere, a (hopefully) innovating control scheme, and some tough one-on-one AI opponents. Only one problem, though: I had no experience with AI programming. I let that idea keep baking until about a month and a half ago when I felt like I had reached a point where I was finally ready to begin development. With AI being my weakest point and the biggest risk factor, I decided to develop a proof of concept where I could test out both the Car/Track AI system and the SpriteKit/Objective-C++ environment.
The intended audience for this article is someone who has at least an intermediate understanding of C++, a strong understanding of object-oriented programming, and an interest in racing AI. This is not a tutorial, and will not walk you through every step of the process, but will cover the whole process and includes code snippets for the parts I found to be more challenging than others.
About a month ago, I participated in the seven day game jam, 7DFPS. My concept was to take the world of Super Hexagon into the realm of first person shooters. I participated in the jam solo, doing all programming, design, art, and music myself. For my first project in Unity3D, I’m pretty proud of it. Gameplay video below.
So maybe it was too big of a task. I feel like I could have finished it, but the last two months have been really hectic, and work on the engine has been slow, almost non-existent. In a pretty crazy turn of events, I won a scholarship that put me at Apple’s World Wide Developer’s Conference (WWDC) this year, and the application, planning, and attendance of this conference has taken up most of my May and June so far. Now that I’m back from California and beginning to get settled back on the East Coast, I’ve decided a few things…
If you’ve been following along with my “Building an iOS App” series of posts, then you can see the end result now! It took about 8 days from when I submitted my binary to being “In Review”. Once I was in review, it was approved within 20 minutes, and another 30 minutes later it was in the store. It’s now updated and available for purchase, just in time for WWDC. Feel free to check out the iTunes Preview page via the link below.
P.S. I also just submitted a bug fix that also has a slightly nicer icon.
My last update was about a week ago, and as of this post, my application is now finished and waiting for review in the App Store. Since then I’ve finished tweaking the main features, cleaned up all the bugs, tested on multiple devices, and went through the process of submitting the app via iTunes Connect and Xcode.
From where I left off last time, the first thing I had to do was fix my orientation issues. The way I had set up my application, I allowed rotation to both landscape positions in addition to portrait. Unfortunately, this caused my AVCaptureVideoPreviewLayer to get double rotated: the camera’s image was already physically rotated, and then again by it’s parent view being rotated this. I solved this problem by modifying the ViewController’s willAnimateRotationToInterfaceOrientation: method so that it could detect where it would be rotating to. Using it’s destination orientation along with it’s current orientation, it calculates how many degrees to adjust for and then applies an AffineTransform to the AVCaptureVideoPreviewLayer so it is oriented properly.
It’s been a few days since I posted the first part of this series, and the app has made considerable progress. With a few moments to spare, I’ll document what I’ve gone through, and what remains.
Since I’m away from my main computer, I haven’t been able to work on my game engine this week. Instead, I’ve been working on building an iOS app. I decided to revisit an app that I made in June ‘10, called Now iSee It. It was the first iOS app that I ever made, and it was essentially a digital magnifying glass, marketed as a replacement for glasses when you forget them. It was pretty light on features, which is forgivable since I basically taught myself Objective-C as I built it, but there was still some value in the idea. So now, three years later, I decided to give it a complete overhaul.
I know a particle system is probably a bit unnecessary at this stage in development, but what is a better way to test my graphics system? It actually made me go in and add scaling and tinting to my Graphic class, and that all works nicely.
Anyhow, the particle system works in it’s current setup, but I feel like I’m going to revamp it. For now, you read in the particle types and effect types from external files, and then create emitters with effect data. The emitter creates a pool of particles, which it then manages. Right now you have to tell it how large to make the pool, but I think I can set it up so that it reads the timing data to figure out how large it would need to be.
My current problem with the particle system, is that each particle has its own Graphic that it updates. I’d prefer it if the Particle objects just kept track of their position, rotation, scale, and color, and then the effect itself has a single (or set of) Graphics objects that it draws to the screen repeatedly using the data from the particles. I’d have to go in and rewrite parts of my Animation/Graphic classes to do that though, so I need to sit down and decide how I want it to fit together.
Unfortunately, I’ll be unable to make significant progress on the engine until next Saturday, so this might be my last update for a while.
On a side note: I just received a student developer scholarship from Apple, and I’ll be going to WWDC in San Francisco this year! (if money permits that is)
Today I spent a good 6-7 hours continuing work on my engine, focusing on trying to finish a basic graphics system. I finished up my animation class, and made a Graphic class that holds position, offset, and rotation information which it uses to draw the animation that it holds. Besides flipping and tinting, I’m mostly done with “sprite” type stuff. I also built a GraphicsManager class that loads up all of the sprite sheets and splits it into sprites and animations. You can then create Graphic objects from the animations, and assign those graphics to anything you want.
The next step was a particle system, since I’m working in the graphics anyway right now. I’m about a third of my way through that, and should probably finish it up in about an hour tomorrow… it’s not too special.
Recap: animation, anchor points, rotation, Graphics, GraphicsManager, and the beginning of a particle system.
Not sure if game engine is the right word, but that’s what I’m calling it. I’ve been wanting to make games for the iPhone for years now, and I feel like I finally have the technical skills to do it, so I’m building my own game engine using OpenFrameworks (openframeworks.cc). So far (since this morning), I’ve built out a basic graphics system that is composed of SpriteSheet, Sprite, and Animation classes, and with this system I can create and draw 250 sprites per frame at 30fps on the iPhone 4, so I’m finally going to have a tool with the level of performance on mobile that I’ve been looking for.
In the coming weeks, I’ll keep detailing my systems as I build them out, starting with finishing the graphics system (more robust manager classes to deal with keeping track of spritesheets and animations, and also a particle system), then moving on to an events system. At that point I’ll have the bare minimum functionality needed to start building games, so I’ll probably start on one of my projects and add to the engine as I go.
I guess we’ll see where this takes me.