All posts by Charlie Cliff

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.

corum

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:

AddPlatform_01

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.

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.

blackhole2

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

Buffing Up Our Platforms

Last time we built a quick class to get our scene moving, but that’s not particularly helpful until we have something to move. In this post, we’ll add a set of platforms to our scene.

This first step is to create a new class that sub-classes our ScrollingNode that we built in the last post.

#import “ScrollingNode.h”
@interface PlatformNode : ScrollingNode
@end

This will ensure that whatever we add to this whatever we add to our PlatformNode will be able to scroll at whatever speed we decide, which was the point of our work in the last post.

Now that we have a class to get things started (or scrolled), we will build a way to keep track of a set of platforms.

One of the advantages of using a procedural level generator, is that it can lower our overhead when it comes to keeping a number of  large map or level in system memory. So, as we build our platform side-scroller we have to keep in mind that we want to limit the total number of platforms that our program will need to keep track of at any given time.

To do this, we’ll build a platform buffer to limit the number of platforms we track. Change our PlatformNode.h file as shown below:

@interface PlatformNode : SKScrollingNode
{
NSMutableArray *platformBlockBuffer;
}
@property (nonatomic) NSUInteger platformBufferSize;
@end

 

What we’ve done is to add:

  1. A Mutable Array that can store any number of objects. We’ll use this to store our Platform Nodes.
  2. An Integer to track how many Platform Nodes we’ll keep track of.

The next step is to make sure these two variables get set up correctly; in our PlatformNode.m file, change our init method as shown below:

- (id) init
{
if (( self = [super init] ))
{
platformBlockBuffer = [[NSMutableArray alloc] init];
self.platformBufferSize = 10;// Generate the first set of platform tiles on the Ground
for (int i = 0; i < self.platformBufferSize; i++)
{
// Generate a New Platform
}
}
return self;
}

 

All this code does is to:

  1. Instantiate our Platform Buffer array.
  2. Set our Platform Buffer size to a default value (I’ve just used 10 here because it’s easy.
  3. Added a loop that will fill up our Platform Buffer.

Now all we’ll need to do is to come up with a way to Generate our Platforms, which we’ll do in our next post.

The Horatians

redSunSign

The Bridge of Piles almost afforded an entrance to the enemy, had it not been for one man, Horatius Cocles; he was the bulwark of defence on which that day depended the fortune of the Armies of the Hyperiad.

-Livia Auguria

Horatii

The Familius Horatius is one of the more prominent in the Hyperiad Empire. Counted among the Twelve Greater Houses, the Horations carry significant political influence, and several of their members have risen to the rank of Consular over the history of the Empire.

The founder of the family, Horatius Cocles, was an accomplished military commander who led the defense of the Bridge of Piles, during which the Titanic Hegemony almost over-ran the Imperial Armies. But through his skill and bravery, Horatius was able to disengage from the battle and make an orderly retreat, saving the lives of many of his soldiers. Although his descendants have never shared Horatius’s military inclinations, the Familius Horatius has maintained one of the larger and more capable fleets in the galaxy.

A fleet that must either be destroyed or co-opted by any of the galaxy’s would-be conquerors.

Side-Scrolling

If we want to build a procedurally generated level for a side-scrolling platform game, then the first step is to get it to scroll to the side.

Crazy notion, right?

This is a pretty easy task when it comes right down to it, and takes only a few lines of code.

To accomplish our task, we’re going to take full advantage of the way Sprite Kit handles it’s scenes. Every object in Spite Kit is basically a sub-class of the SKNode class, and every SKNode has a parent and a bunch of children, forming a hierarchy or tree.

So what we’ll do in order to get our platforms to scroll is to create a new class: an ScrollingNode that is a subclass of an SKNode.

@interface ScrollingNode : SKNode

 

We’ll have to manage some way of determining how fast we want our platforms to scroll right? So we’ll have to add a property to track that.

@property (nonatomic) CGFloat scrollingSpeed;

 

Since the only functionality that we really want from our ScrollingNode is to scroll (it is in the name after all), we’ll only have a single method, which over writes the update method that’s already present.

- (void) update:(NSTimeInterval)currentTime
{
[self.children enumerateObjectsUsingBlock:^(SKSpriteNode * child, NSUInteger idx, BOOL *stop)
{
child.position = CGPointMake(child.position.x-self.scrollingSpeed, child.position.y);
}];
}

This method is what takes advantage of the SKNode’s design.

The only thing this method does is to enumerate through every child of our ScrollingNode, and move them by the scrollingSpeed that we’ve already added.

And that’s it.

…I told you it would be simple…