Category Archives: Blog

Out On Safari

For the last several years I’ve been a Google Chrome man.

I used to use Firefox until the Google published it’s own browser, and then there was a slow but steady transition from using primarily Mozilla’s browser to Google, and I’ve been using Chrome as my primary browser ever since.

One of the main things that I’ll use Google Chrome for is to work on what iOS Apps I’m currently working with, which lead this past week to something of a tiff between myself and the Apple Support Staff.

This weekend I began tinkering with In-App Purchases, which I feel every App developer eventually does. One of the things that is needed before one even begins cutting code is to register yourself with Apple and sign Apple’s various legal documents. So I sat down to read through Apple’s license agreements and fill out the various forms they require.

Only I couldn’t.

I couldn’t seem to enter any of my contact information, or banking information, or any of the sundry tidbits of personal data. For some reason, I was completely cut-off. I couldn’t even see their drop-down menus. I was utterly flummoxed.

This led me to call the Apple Support Team for their assistance; and after reading through the prescripted responses, they informed me that:

“iTune Connect may have limited functionality on browsers other than Safari”.

And I’ll be honest, this statement confused the hell out of me, because what I’d witnessed was not something that I would label “limited functionality”, it was “no functionality”. The site did not do what it was required to do. There is only one objective, and iTunes Connect doesn’t accomplish it in Chrome.

My mind boggles!

Although, I have to hand it to apple Support, no functionality is a hell of a limitation.

Positioning the Platforms – Y Now!?

Last time we nailed down the X-Coordinate of our Platform Nodes, and this time we’ll dig into the much more difficult task of picking a Y-Coordinate. In our last post, we just left the Coordinate as a value of 4, which will make a single unbroken platform. (Pretty boring right?)

But now it’s time to add a little challenge!

The primary aspect of platform games is the ability of the player to jump from one platform to another, essentially making an obstacles course. Sometimes there can be monsters, or treasures, or traps, but at their heart, platform games really come down to that simple premise.

So to procedurally generate this feeling, our first step is to start programmatically carrying the height of our platforms as they scroll across our screen.

To do this, we’re going to take some time to do a bit of design effort that will save us some time down the road.

What we’re going to do is add a new class to our project that encapsulates our height calculation algorithm. This design principle is called the Strategy Pattern, and is the best pattern to encapsulate complicated algorithm that might change over time. For now, we’ll be keeping our algorithm simple, but we may want to change it over time, and this design pattern will help make that easier.

So we’ll make a new class in our project and call it  EEPlatformGenerator.

Now that we have our strategy class, we can get to work.

But, there’s no sense getting ourselves wound around the axel immediately, so we’ll implement the simplest possible algorithm that we can. The simplest way to vary the height of our platforms is to just make it random. To do this, we’ll spin a quick helper function to generate a random number between two values, a maximum and minimum value:

Method - Random Number

Now all we have to decide what those maximum and minimum values are going to be. So we’re going add some data to our new class:

Class - EP Platform Method

What this data does is:

  1. currentBlockHeight – This datum will track the Block Height of the last platform.
  2. jumpHeight – This datum is the height our player can achieve when he jumps.
  3. dropHeight – This datum is the height form which a player can fall without taking damage.
  4. platformCielingHeight – This datum will provide the maximum height of a platform. We’ll use this to prevent our platforms from climbing to ridiculous heights, we wouldn’t want a platform with a height of 145,057.

Now we’ll use our new data to build a method to determine the height of our next platform:

Method - heightOfPlatform_01


Ta Da!!!

Prototyping the UI

Right now we’re prototyping some of the UI designs for Project Red Sun.

Being that we’re all visual folks here at Electronic Graffiti, it helps us to really have a vision that we can really aim towards. So I wanted to share our first UI sketch to show the feel of our UI for now.

iOS Simulator Screen Shot Feb 12, 2015, 12.28.27 AM

Platform Generation

Now that we have our Grid Laid out, we can move on with our Platform Generation Methods.

Our platform generation algorithm will break down into 5 Steps:
1. We will create a new sprite node for our Platform.
2. We will use the methods we developed last time to determine the position of our Platform.
3. We will set the Physics attributes of our Platform (in our case we will treat our Platforms like SKPhysicsBody).
4. We will add the Platform to our PlatformNode.
5. We will add the Platform to our Platform Buffer of our PlatformNode.


Here’s our code for this algorithm:

– (void) generatePlatformAtPosition:(CGPoint) mapPosition
// 1. Create a new SKSpriteNode
SKSpriteNode *newPlatform = [SKSpriteNode spriteNodeWithTexture:self.platformBrickTexture];

// 2. Set the Position by converting the grid coordinate system to the coordinate of the Scene
newPlatform.position = [self convertMapCoordinateToWorldCoordinate:mapPosition];

// 3. Set Up the Physics Attributes
newPlatform.physicsBody = [SKPhysicsBody bodyWithRectangleOfSize:CGSizeMake(self.platformBrickTexture.size.width,
newPlatform.physicsBody.dynamic = NO;
newPlatform.physicsBody.restitution = 0.0f;
newPlatform.physicsBody.friction = 1.0f;

// 4. Add the SKSpriteNode to our Platform Node
[self addChild:newPlatform];

// 5. Add the SKSpriteNode to our Platform Buffer
[platformBlockBuffer addObject:newPlatform];

Now we can add a platform at whatever position we want.

Next time we’ll start adding and removing the platforms dynamically.


Jupiter in the Scarlet Robe

This weekend I went to see the new movie Jupiter Ascending, and I have a lot of mixed feelings about.

First off, Jupiter Ascending is a movie I could just stare at for hours. The visual style and the art is just overwhelming and it perfectly hits that grandiose Sci-Fi sweet-spot for me. It’s exactly the kind of thing I could spend hours staring at, like some computerized rendering out of an old issue of Heavy Metal. Of the movies I’ve seen recently, Jupiter Ascending best drives home for me the fact that film is very much a visual medium. If they took this movie and turned it into a series of panoramic shots of the scenery and the spaceships with Sean Bean’s voice-over narration of what everything was, I would have still walked away happy. That being said, the story of Jupiter Ascending is one of the most fucking disappointing things I’ve ever seen.

But here’s the kicker: the story isn’t bad. No really hear me out on this one, because I’m about to say something that I rarely say about anything.

This movie should have been a trilogy. Unlike the Matrix films which were unnecessarily stretched out over three films for ostensibly poor reasons, Jupiter Ascending tried to do too much in a single film.

Boy are the Wachowskis bad at their pacing.

Jupiter Ascending sets up with three incredibly powerful galactic siblings who, over the course of the movie, each vie to manipulate and control, through various means, the main character Jupiter, Mila Kunis. Because each sibling needs time to interact with Jupiter, her encounters with the three siblings are each very abridged and rushed so that the film simply has Jupiter awkwardly stumbling between her encounters. The Wachowski’s could have easily broken this up across three movies, and I know this because the work was literally already done for them, because Jupiter Ascending’s plot actually follows the same story, almost point for point, as a trilogy by pulp writer Michael Moorcock’s Sword Series of book from the early 1970’s.

I’m not even joking. Michael Moorcock pretty much wrote Jupiter Ascending for the Wachowski Brothers in 1971.


Moorcock wrote about the Hero-Prince, Corum Jhaelen Irsei, and his struggle to defeat a trio of incredibly powerful, god-like siblings. Corum encounters each sibling in turn and defeats each one through varying means before freeing his world from their creepy, Big-Bad-Evil-Guy Tyranny. Moorcock broke his work into three easily digestible pieces, that would have translated easy-peasy to screenplays, and the parallel is pretty uncanny to Jupiter Ascending in both the weird Ambience and the story structure.

So I can see exactly how the movie could have been stretched, see how the gaps could have been filled, and how the pacing should have worked. As it stands, I’m just left feeling hollow at seeing a story I read as a child regurgitated to me in a condensed, rushed, and hap-hazard manner.

Positioning the Platforms – Dos Equis

Last time we built a function to add Platforms to our Scene at a specified point, so we can place our platforms wherever we want! All we need is an X-Y Coordinate in our tile grid that we’ve already developed here:

But just getting the platforms scrolling along our scene is really the easy part; the tricky part is developing a procedure to place them in order to make our game looked like a pre-designed platform level.

There are two parts to this issue: getting an X-coordinate, and getting a Y-coordinate. The first part will be fairly easy, and the second part will take a bit more design work.

To select our Platform’s X-Coordinate, we’ll use the platform buffer we developed previously.

If you recall, the entire point of our platform buffer was to hold all of our Platform Nodes as they scroll across the screen. This means that if  we can visualize our platform buffer as a line of Platform Nodes positioned across the screen, with the first Platform Node in our Platform Buffer as being the first Platform Node in a line of across the screen and the last Platform Node in our Platform Buffer as being the last Platform Node in a line of across the screen.

This is a pretty key concept, here! What this concept allows us to do is simply use a Platform’s position in the Platform Buffer as it’s X-Coordinate.

We’ll implement this in a new method below:


This method will add a new platform, using the generate platform method we developed previously. We place the platform at the end position of our platform buffer.

For now we’ve got the platform’s X-coordinate sorted out, and we just place at a height of 4 four now, but we’ll be changing that later.

History of the Hyperiad Empire

Marcus Valerius Solus stood beside the Promethean Emperor at the Hyperion Nova when the First Emperor bent space and time to destroy the Hegemony home world. Marcus watched the star burned and and the 100 billion people that burned with it.

-Plinny Primus

The Promethean Fire

Coordinate Conversions

Last time, I held off on going over our method to add Platforms to our SKScene. The reason I did this is because I wanted to take some time to go over a bit of background before diving headfirst into the code.

This time I’m going to go over the coordinate system that we’ll use to place our Platforms.

The strategy that we’ll use is to break our SKScene into a grid. Every column of our grid will have exactly one Platform, so the width of our grid will be the size of our  Platform Buffer and the size of each square of our grid will be the size of our Platforms.

The trick is going to be finding a way to change the coordinates of our grid to the coordinates of our SKScene.

To do this, we’ll add two new methods to our PlatformNode  class:

- (CGPoint) convertGridCoordinate ToSceneCoorindate:(CGPoint)gridCoordinate {return CGPointMake(gridCoordinate .x * self.platformBrickTexture.size.width,
gridCoordinate .y * self.platformBrickTexture.size.height + self.platformBrickTexture.size.height / 2);}
– (CGPoint) convertSceneCoorindateToGridCoordinate :(CGPoint)sceneCoorindate
{return CGPointMake(roundf(sceneCoorindate.x / self.platformBrickTexture.size.width),
roundf((sceneCoorindate.y – self.platformBrickTexture.size.height/2)/self.platformBrickTexture.size.height) );}


These two methods will convert a CGPoint between the coordinate system of our grid and the coordinate system of our SKScene.

The Black Star

Te namesake and capital of the Hyperiad Empire is the Hyperion System, revolving around the remains of the main sequence star, Hyperion.


Before the founding of the Hyperiad Empire, the Hyperion star system was the capitol of the Titanic Hegemony, the ruling body of mankind. During the Astromachy, the Promethean Emperor waged a war against the Titanic Hegemony that spanned across the galaxy and culminated in the Hyperion Nova, when the Promethean Emperor forced the sun of the Hyperion star system to go Super Nova and then rapidly collapse in on itself forming a black hole. Most of the remaining Hegemony forces, as well as the majority of the remaining Titan, were dragged into the gravitational pull of the remains of the Hyperion sun, ending the Astromachy.

After stabilizing the remaining black hole, the Promethean Empire decided to establish his capitol in the remains of the Hyperion system, constructing several artificial satellites to orbit the gravitational singularity at the center of the system.

History of the Hyperiad Empire

After the Standing of Holdencourt, Titus Furius and his 13th Legion were left stranded deep behind the front line. Without support of Hyperion Command, Titus was forced to lead his Legion through 112 Lightyears of Hegemony occupied space. Throughout the 10,000 year long  history of the Hyperiad Empire, such a feat has never since been accomplished. The march of Titus Furius and the Abandoned Thirteenth has become almost as legendary as the rise of the Promethean Emperor.

-Tantillius Varus

A March Across One Thousand Suns