» Joyride Junkyard Rocket

Category Archives: Joyride

Week 3: Actors and Controllers

Last week, I left off with a sprite on on hex tilemap. I didn’t feel this really entailed “The player starts in the center of hex field“. There was no actual concept of a player or any other sort of entity in the code. Well, this week I have accomplished just that and this task is done. I’ve decided on a three-part model of any given agent in the game.

The entity: A collection of transient and intrinsic properties that contain the data of an agent.
The controller: The brains of the agent. A player controller interprets input from the player to control his agent. A controller issues high-level orders, like move-there and shoot-that, to the agent.
The actor: Takes orders from the controller and translates them to alter the data in the entity, like position, facing, animation, and whatever else it takes.

This structure gives a strict rules in who owns/modifies what. The entity only contains data and no logic. The controller only reads data and issues orders (temporal data only) and contains minimal state. The actor modifies data and only contains only enough logic to carry those orders out. It does no real decision making. The arrangement is fairly object-oriented, but if I wanted to do a data-oriented design, I think this could swing it later.

Next up is “The player can move to adjacent tiles“. This should be pretty simple and is rated a one-point task. Seeing I have a controller and actor for the player, it’s just a matter of getting input from the player and making and interpreting those orders. I’m also going to take a crack at “The player can see that different tiles have different aether densities“. It’s already mostly much done because I have a tilemap being displayed. This task will just be a matter of iterating through the tiles and building an array of tile info. It is also just a one-point task.

Week 2: Damn you Xcode!

This week I did not make a lot of progress. I probably only got 3-4 hours in and most of that was spent struggling with Xcode. Somehow, the project got corrupt? My Hello World compiled and ran last week and this week I try to get a simple tile map running, and the program would never run. It would compile, but whenever it tried to send it to the iPad simulator, it would sort of hang. This is apparently a known issue in the Apple dev forums, but no solution presented worked for me. So, I updated the Cocos2D branch, installed their templates, and made a new project based on one of them. It works now.

I also made a hex tile map and I can load the game with it showing. There isn’t a concept of a “player” yet; no representation on the screen or in the code, so I can’t say the next task is complete. That’s going to be next week. I’m also going to push “The player has a homebase” back to a later sprint. It’s not an intergral part of the gameplay loop to have one, so I’ll focus on that later. That means the next task up to bat will be “The player can move to adjacent tiles“.

Week 1: Xcode, Cocos2D, and Git! Oh my!

Week one, I hope, will be the least exciting of weeks. I got my GitHub repo set up (sorry, I’m keeping this closed source for now), added a clone of the Cocos2D git repository as a subtree of my main project, and got Xcode set up to build Joyride and run a simple hello world. It’s not much to look at, but it scratches “The Player can start the game” of the list. Look!

Hello World!

With Cocos2D sitting in my repository, it should be easier to pull down patches from them, which was a huge pain last time. I’m a little worried though. I made a change to one of the Cocos2D files to remove a warning in Xcode and pulling the latest changes from the Cocos2D git overwrote those changes. I’m hoping it is just because it was binary file and the diff’ing doesn’t work in those cases. It’s something I’ll need to look out for. I think I might also need to look into getting a visual client for git. Working on the command line hasn’t been too bad, but I could see it getting annoying.

The next task is “The player starts in the center of hex field“. This will probably take a full week or two. I have to make some assets in Tiled using hexes. Last time I tried this, support wasn’t 100% in Tiled or Cocos2D for hex tiles, but I’m hoping the last year saw some improvements. There is sample code that has hex tiles, but I remember making some changes to the underlying engine to get it to work the way I wanted. This task has 3 points, just because I expect there might be a lot of little gotchas along the way.

Time to Put Up or Shut Up

There’s been enough talking about Joyride. It’s time to make actually make the freakin’ game! Next week, I’m actually going to start working on this thing. How is this going to go?

Tracking the work

I put my task list for everyone to see on Pivotal Tracker. This makes sure my account there is free and I’ve been very open so far, so why not continue with this? Pivotal Tracker is probably a bit overkill for this stage of development, but I like the way it works and matches my own personal workflow pretty closely. “Sprints” right now are at 4 weeks and each week I’m going to put in 5 hours of work.

Yes. That’s not a lot. I’m sure some indie devs are scoffing right now. Look: I have a day job making video games. A job I like very much. I have a wife. A wife I love very much. I have friends. Friends I like to hang out with. And then there is the other items of joy such as playing other people’s games or watching TV or reading or whatever. Joyride is a hobby and as such and I cannot let it be too consuming. 5 hours. Right now, no more and no less. I can revise as I go, but it’s a start.

Weekly progress reports

Each week, I’m going to briefly go over the work I have done, what work I will tackle next, and any issues or observances. This is like a weekly standup for my “sprints”.

No feature creep

I’m going to come up with new ideas. I will probably get great ideas from people following me here. I will not attempt them in the first version. I will right them up and add them to Future Ideas.

And here we go!

Wish me luck! This is going to be a lot of fun.

A Hex Tile Implementation

I’m making a game with a hex based grid. These are my notes on my implementation (so, far). This is dry and without much explanation, but if you want to do the same, maybe this will help you.

Moving between tiles

Now, a hex grid is a 2D so one might think that 2D coordinates would work best. It is my opinion they don’t. You don’t have the same X-Y movement in a Cartesian environment. It’s actually more like three directions of movement: up-down, NW-SE, and SW-NE. So, how about 3D coordinates?

trans

It may seem a bit odd, but trust me, it’s really nice. This system has some handy properties:

The sum of coordinates (a,b,c) will always equal zero. Handy for validation.
Distance from origin is max(abs(a), abs(b), abs(c)). I think that might be cheaper computationally than Cartesian distance mostly because I don’t have that square root.
Distance from p1 and p2 is max(abs(a2-a1), abs(b2-b1), abs(c2-c1)).
(a',b',c') = a+Δa, b+Δb, c+Δc
(x', y') = x+Δa, y-floor(x/2)+Δb+floor((x+Δa)/2)

Line 5 is the sort of reason why the 3D coords work so much better. That math is just ugly. My first implementation had something much like that and it just causes so many bugs and brain twisters figuring things out.

Storing the tiles in memory

While this system is nice, it fails memory storage. It still has to be shoved in an array. Thankfully, translating from hex coords (a,b,c) to 2D coords (x,y) is straight forward. First, some basic principles.

(x, y) 
    = (a, b+floor(a/2))
    = (a, b + a >> 1)
(a,b,c) 
    = (x, y-floor(x/2), -(a+b)) 
    = (x, y - x >> 1, -(a+b))
    = (x, y - x >> 1, (x>>1)-x-y)

Pretty simple code that can be optimized; just adds, subtractions, and bit shifts. But still more work needs to be done to get it into an array. First, let’s define some spaces:

even odd

Any tile could be considered a playable space in the game, but for Joyride, I was thinking having the colored tiles be the actual play space and the clear tiles would just be unused space. I like it because we have a hexagon made from hexagons! The pictures also indicate how a even-radius hex space and an odd-radius hex space would fit into the space. With this, I can translate into an array.

w = h = HexSpaceRadius * 2 + 1
(xMax, yMax) = (w-1, h-1)
Array length = w * h
Array index 
    = (x * h) + y
    = (a * h) + b+ (a>>1)
(x,y) = floor(i/h), i%h

That will get me a hex grid with the following coordinates:

coord

The “origin” in my hex space isn’t the same as my array, but here is the translation:

2D origin 
    = (x0, y0)
    = (floor(xMax/2), floor(xMax/2))
    = (xMax>>1, xMax>>1)
3D origin
    = (a0, b0, c0)
    = (x0, y0 - x0>>1, (x0>>1)-x0-y0)

To demonstrate through example, here is the stuff we would pre-compute for the 2-radius hex space above:

w = h = 2*2+1 = 5
xMax, yMax = 4, 4
Array length = 25
2D Origin = (2,2)
3D Origin = (2, 2 - 2 >> 1, 2>>1 - 2 - 2) = (2, 1, -3)

There’s is a lot of conversion to and from the different coordinate systems. I’m planning hide most of it away though convenience functions, type converters, and caching. I haven’t give that much thought yet. I can also figure out my wasted space (those clear tiles). The number of tiles use for my Hex Space is calculated as thus:

totalTiles = 1
for ( i=1; i<=r; i++)
    totalTiles += i*6
waste = Array length - totalTiles

Just to put some real numbers on it, for a 3-Radius Hex Space and a 20-Radius Hex Space:

3-Radius
- Array Length = 7*7 = 49 tiles
- Total Tiles = 37 tiles
- Waste = 12 tiles (24.49%)
20-Radius
- Array Length = 41*41 = 1,681 tiles
- Total Tiles = 1,261 tiles
- Waste = 420 tiles (24.99%)

Interesting that the waste is always about 25%, but not too surprising. That’s quite a bit of memory that could end up being wasted and that might be something I’ll need to be wary of going forward.

Converting Screen Space to Hex Space

I have implemented this, but I haven’t done a write up on it yet. When I get back around to doing this again, I will fill this out. This is one of the things that’s pretty easy to find in a google search. It was one of the first topics I found when researching this. But, if for some reason you need this before I get to it, leave a comment and I will write it out.

More Wormholes, More Problems

An idea just occurred to me and I want to write it out. This is a note to myself, so I don’t forget, but I wanted to share, too. So, HexSpace is Burmuda Triange of space travel, right? What if, instead of the player being sucked in, he is a daring (even foolish) treasure hunter that purposely enters HexSpace for loot? Normally, the unlucky have something go wrong while traveling through a wormhole to survive. These treasure hunters have found a way to force the relative safety of faster-than-light travel and inject themselves into wormholes voluntarily. They cannot exactly control where they will dump out of the wormhole, it’s practically random! And there we have a handy little fictionally consistant reason why the maps are different each time. Bonus idea: wormholes in different regions of space have different feeling HexSpaces. No one knows why, but the danger, loot, and affinities are more in-sync with some wormholes than others. This gives a good additional mechanic for player progression and preference. As they player levels, additional wormholes are opened up, allowing tougher maps or new gameplay hooks. Also, players might prefer HexSpace sectors from Wormhole X as opposed to Wormhole Y and can keep playing sectors there.

Joyride: The Actual Freakin’ Game

It’s about time…

I’ve gone on enough about the background. Don’t get me wrong, it was important to get all my thoughts about this project sorted out so I could see through it all. But the goal here is to make a game, dammit. Consider this the first design doc, the blueprint for Joyride. At least, the first iteration. I see two things I need to have a version v0.1:

1. A Place to Explore

Hey! I know! How about HexSpace? Great, let’s use it. My HexSpace, let me show you it:

Hexspace

I consider this programmer art but graphically isn’t a bad start. Also, the actual sectors will have many more tiles than this. The tiles themselves will probably be larger, too. So, what’s actually going on here? On the outside of the grid is just un-explorable space. Inside the grid is where the player explores. The orange stuff is nebula/clouds/fog/aether that obscure the monsters and loot. In this image, it comes in four varieties: clear, light, medium, and heavy. I might play with more levels of nebula density, but that’s the start. The nebula density of a tile affects everything from sight ranges, movement speed, and weapon effectiveness. Broadly speaking, the heavier the nebula, the worse it’s going to be for the player, but loot hides everywhere, and the player needs to dive in.

Sight Lines

The denser the nebula, the less the player can peer into it. Each tile has an interference level of 1, 2, 4, and 6 for clear, light, medium, and heavy tiles. The player’s tile has half the interference. The player has sensors with a penetration level of 8. To find out if a tile is visible, sum up every tile’s interference from the player’s tile to the target tile and if that value is less or equal to the player’s senor’s penetration, that tile is visible. If there is more than one path to a target tile, take which ever path has less interference. That might make for weird situations later, but I suspect that this particular game mechanic will be revisited many times. Here is an image with sight lines from a few different locations. The green circle is the player’s location, colored tiles are visible, and the numbers are the interference for that tile.

Hexspace

Some observations about this system. It’s easy to sidle next to heavy tiles and see what’s in there, but going into that tile really obscures what the player can see. If there is a large grouping of heavy tiles, the player can be flying blind for a while. I could see some serious strategy coming from this. Also, there is a “bug” in the middle picture in the bottom tile with the ’9′. That tile isn’t visible to the player, but they way I showed the hue left that tile looking visible. It wouldn’t be.

Movement

For this iteration, I think movement will just be simple and turn-based. The player taps an adjacent tile and he moves there. Then, everything else takes its turn. In the future, I would like to have an action point system and different tiles would have different action point costs. Clear tiles might take one action point and heavy tiles would be three.

Weapon effectiveness

I think the player should be able to fire his weapon further than he can see, but the chances of hitting are reduced by the interference and distance. Say the player has a base 50% chance of hitting. Before rolling to hit, the interference in subtracted from this value for the new modified chance. A different weapon, like a laser, probably wouldn’t miss, but the interference would reduce the damage. I’ll probably have to play with just how much the effectiveness is reduced by interference, but this will be the basic mechanic.

2. Risk and Reward

Any game worth its salt (e-salt?) has risk and reward. The more risk you take, the greater chance of reward but in turn a greater risk of failure. It makes things interesting. I’m sure people could argue me on this point and I invite those people to go away. I’m not interesting in exploring the deeper meanings of play here, just making a damn roguelike! So, what’s the player going to put everything on the line for? Crystals! (Also, need a better name than crystals).

Bejeweled

Yeah, ok, that’s just Bejeweled, but I wanted something evocative of what I was going for without spending all day making actual gems for you to look at. What are these crystals? They are the solidified essences of the aether that makes up HexSpace! Scattered about the sector are deposits of these crystals just waiting to be picked up. What do these crystals mean for the player? Well, the crystals are his…

Score!

More crystals means more points and games are all about the points. But that is just a simple metric of the player’s success. Here comes the real twist. They are also his…

Ammo!

Well, crap. So, I’m saying player effectively reduces his score to kill enemies? That’s right! But the enemies want to kill the player and dead player can’t get more crystals. Dead enemies also drop more crystals. I also really want the player to think about every shot they take, that’s why I am giving the crystals and enemies affinities. Right now, it’s simple stuff, a rock-paper-scissors relationship. Red crystals hurt green enemies more than other colors, for example. To start, there will be four colors, red, green, blue, and white. White is generic. It’s not strong or weak. It’s what the player will find the most of and what he starts with. Red is strong against green, green against blue, and blue against red. Go the opposite direction for weaknesses. So, now does the player use that level three blue crystal against that really big, bad enemy or bank it for points? But wait! There’s more! Crystals are also the player’s…

Buffs!

If the player uses that crystal on himself, he’ll get a temporary buff. I… don’t know what the buffs will be yet. This will be a later iteration, but will add depth. Speaking of depth, crystals aren’t the only loot. There are also…

Artifacts!

When a player starts, he is practically just chucking these crystals at the enemies. HexSpace, though, is strewn with fantastic relics of others that have been sucked in and the player can shove a crystal in these and really cause some damage. To start, artifacts will provide different sorts of attacks and buffs from the stock ones and later that can allow more in-depth mechanics like mixing crystals to make hybrid attacks or damage. Those enemies won’t know what’s coming! Speaking of enemies, the game will have…

Enemies!

I’ve mentioned them, but what are they? I still don’t know. For this iteration, they will be really simple affairs. They detect the player, they move towards the player, they hit the player with damage until he dies. As I iterate, enemies will get different strategies and special abilities. For now, they’ll just be cannon fodder. There’s just one last part. In between sectors is the…

Home Base!

I always want this game to play in short 10-minutes sessions, but I would still like a longer sense of progression. The player dives into a random sector, kills a bunch of fools and harvests all the crystals, but what does he do after that? I’m thinking the home base is where the play goes to spend those crystals on upgrades, new ships, and other perks. I don’t have anything designed yet, but I wanted to get this idea out there so people know about it. To start, the home base will be where the player goes to get his score and start a new sector.

Next Steps

So, that’s my design doc. There is enough here to have a game that people can play. There is a bit more than I want in my first iteration, but I think needed to be said. I am going to use an agile system for making this, so my next step will be breaking this design doc into user stories and prioritizing them into a backlog. I already have made some headway into this and I will post them when I have it finished. I also need to do some investigation into what tech I would like to use. Cocos2D is might leading candidate, but since I last played with it, there have been more releases. There are also other game frameworks like Corona and Sparrow which look interesting. I will also write-up my findings with those. Meanwhile, if you have suggestions or ideas on any of this, leave a comment or send me an email! I’d love to hear it and I would like to incorporate your ideas I like earlier rather than later.

The Problem with Space is all the… Space

Wide. Vast. Empty. Boring.

Ok. Again, back to Rogue. You go down the stairs and you find yourself in a new room on a new level in the dungeon. Each room might be only a few tiles across to something more like 20 tiles across. At most, it might take you a minute to explore the room, more if there are some nasty monsters or traps you have to deal with.

How does this work with our translating Rogue to space? First issue we need to solve is an issue of scale. Let’s start with a star system. Is each planet a “room” from Rogue? If it is, how do you scale down everything that’s on a planet to something that takes less than a minute to explore? And how does your spaceship factor into that. To really give that planet character, you’ll need to spend a lot of time down there. Heck, you could make each planet a roguelike unto itself. Space is what I want to focus on with Joyride, so interactions with planets should be minimal, like a treasure chest almost. Fly to one, perform a scan, create some random loot or encounter, and move on.

Alright, that could work. We won’t make planets rooms because that will open a can of worms I don’t want to deal with. We’ll make them encounters. But what happens to the room metaphor? We no longer have something that we can consider a room. We have a vast open space with 9 (or so) encounters in it. Some of that space could be filled with things such as space stations or large battle ships or other exotic space doodads. We could also remove some of the intervening space to increase the density of the things you find. We don’t have rooms, but we at least have things to do that will make the game interesting.

I just can’t shake the feeling that it would be boring. You enter a new system and move around a whole bunch of black space until you find the 5 to 15 points of interest, which are probably going to be a lot like the systems you have been to. It’s here where the theme of star systems break down. There isn’t a compelling reason why the systems you explore should get harder or weirder. In Rogue (and even more so NetHack), the further you go down in the dungeon, the nature of the dungeon changes. In NetHack, you’ll go through regular dungeon, Gnomish Mines, Hell, Heaven, and everything in between. It’s all nicely explained by the fiction for the game. Moving further from Earth just doesn’t justify the variety of gameplay and spaces that Rogue and NetHack to get away with. What we need is a fiction that gives us the sci-fi, space exploration feel we’re looking for, but not pinned down to any sort of expectations resulting from classic space travel. We need justification to make up whatever crazy crap we need to make Joyride varied and interesting.

Welcome to Hex Space!

Common tropes in sci-fi are things like subspace, hyperspace, wormholes, and other dimensions. Many stories involved the places between space. Star Trek has many times posed the question of what happens when technology they depend on fail. Went too fast with the ol’ warp drive. Teleporter broke. Wormhole broke. Reality broke. You name it, and it went wrong and weird shit happens. That’s a trope we can build a game upon.

I see Hex Space as a Bermuda Triangle for space travel. Many unfortunate souls have found themselves lost here after Something Went Wrong. Hex Space if weird. Physics doesn’t quite work right. All manners of things have been sucked in. There is rumor that a whole Star System is in here hidden among the clouds. Clouds? Yeah, that’s right. Also, Hex Space can support life and has organisms that grow and evolve here that can be found nowhere else. Empires have risen and fallen, ancient space faring races leaving nothing but their ruins and powerful and poorly understood tech. Life in Hex Space is brutish, short, and always changing.

You see what I did there? I can make up whatever the heck I want and it’s all explained away. The turn-based and hex-based movement exists because physics here is strange. But some truly dire things living have found a way around all that and move about as they will ignoring the usual turns and hexes. Now there’s a gameplay twist. Procedurally generated spaces are natural. Random loot is limited only by our imagination and not the fiction. Same with monsters. Fighting a giant space shark in the remains of giant, rusted out space station as you pilot a weaponized zeppelin is an average day in Hex Space. I can start with a small section of Hex Space and then release content packs until I die and it will all fit right in. It moves away from Star Control 2, but I’m pretty sure that this is awesome enough that I don’t care.

Of course, having such a flexible fiction can get me into trouble if I don’t nail down some specifics. Having too broad a scope is what got me going down this road in the first place. But Hex Space is only as vast as the work I put into it. And just like deciding on hex tiles and turn-based movement in the first place, I have to pin down some specifics of this new universe and how it ties into those gameplay decisions that I have already made. Don’t worry folks. I know this is the fourth post in my Joyride story, but I think I have laid down enough ground work that I can finally define my first deliverable. Next time on Junkyard Rocket: 10-minutes of Joyride: Journeys in Hex Space!

The Story so Far (Not, like, plot, but work I’ve done)

The first iteration (Starting with Star Con 2)

My first work on Joryride was simple really; boil down each game to their specifics, find parallels, and combine! Rogue has a dungeon made of levels. Each level has multiple rooms connected by hallways. Levels are connected by stairs. Rooms are filled with monsters and loot. Now Star Control 2 is a galaxy of star systems. Each star system has multiple planets connected by, erm, space. Systems are connected by hyperspace. Systems are filled with aliens and resources. The parallels are easy to draw.

So, I made a bunch of star systems and filled them with space (that step was pretty easy; I’d fill in planets and stuff later). The top, bottom, left, and right sides of the map were “wormholes” (or something) that connected systems to other systems. It was working pretty well. Navigation was a take on the Flight Control game mechanic. Flight Control has the player guiding airplanes to runways by pressing on the plane then drawing the path you want it to fly.

Flight Control HD

In Joyride, I expanded the mechanic so that holding your finger at your destination for a second or so before releasing would have your spaceship stop there. Otherwise, it would keep traveling in the direction it was going when the path ended. Ending the path on the edge of the sector (or allowing the spaceship to travel off the edge) would cause the ship to travel through the wormhole into the next system.

Let me say, it was a really cool mechanic. It gave you a lot of control on where your ship went without needing some on-screen joystick or other constant fiddling. I think an interesting game could be built around it. And, uh, many have, I guess, like Flight Control. I feel like it isn’t a good fit for this game, though.

There are many aspects in roguelikes that really appeal to me, but three are near the top. First, it’s turn-based. You have as much time as you like between turns to consider your next move. Second, because of that, it’s trivial to pause and save state, making it a very mobile friendly game. Someone calling you? Progress saved. Only have a few minutes standing in line? Crank through a handful of turns. Third, the map starts unexplored, so each step you take reveals something new.

As I had the game implemented, it had none of that. The only exploration was through entering a new system. The whole system started revealed (I mean, if you’re advanced enough to travel through space, decent sensors seems like a sure thing). I tried to fix the exploration issue by putting in a fog of war for each system, but you could just trace a line around the map and your ship would reveal all while on auto-pilot. It really removed the tension and I want my exploration to be more deliberate. Everything was in motion, so although saving state wasn’t too hard, when you came back, it was very hard to get your bearings as everything kept going about its business. I could have the game pause on restart, but that didn’t feel right either.

The second iteration (Moving to Rogue)

So, the decision was made to transition to turn based. It’s hard to have turn based without moving in discrete steps and if you have discrete steps you pretty much tiles. You know, like Rogue? A quick aside, I know that this isn’t the only means of turn-based movement, but it’s the most roguelike and the sort that I am interested in.

I also decided that square tiles are played out (and I think I like pain) so I will use hex tiles. I always liked hex tiles. Yes, movement on them is a little odd. Yes, defining an array that holds all the tile state is hard. Yes, placing them on the screen is hard. Yes, doing distance checks is hard. I admit, there is not a single thing about hex tiles that makes my job easier. But there is a prestige about them. Moving around in space feels (in my head) so much more natural on a hex grid. Diagonals are no longer an issue. They are just cool.

Hex Grid

Also, I’ve already worked through much of those issues above in my second iteration. It wasn’t easy, and if memory served, I still have a bug with distance checks, but I did it and it was pretty cool! Although, I saw something the other day that looked pretty slick. It’s still hexes, but a different representation. Place a dot in the center of each hex then connect them. You’ll get a bunch of triangles and each intersection has six lines coming out. Movement would be along lines instead of between tiles. I’m still rolling it around in my head. Here is the game that inspired me called Wizard Hex.

I don’t know a damn thing about it except it looks cool and is some sort of board game. Each of those tokens would be your ship or a baddie or something. I have no idea how I would tile the triangles. Man, now that I mention, it sounds like a nightmare. But look! How cool is that? I like the flush edges at the sides of the play space and not what you get with more traditional hex grids. I’ll probably skip out on this idea, but I wanted to get it out there.

And now, the next iteration (Something else entirely)

So, that’s where I have been. In the next post I’ll cover some of the themes, and more importantly, some of the constraints I have come up with for my next design. For example, I would like the game to be played in 10 minutes chunks. And that maybe pure turn-based isn’t what I want. WHAT?! But I just said? I’m changing this already? Well, calm down and come back next week (or so).

The idea’s simple! It’s just Star Con 2 meets Rogue!

How hard could it be?

At least, that was the inspiration that got me thinking just over a year ago. There are those who probably have no idea what I am talking about. These games are old and probably no longer universally known. Allow me to describe just what about these games inspired me to go down this path.

Star Control 2

Star Control 2 is one of my all-time favorite games. I’ll save the book report for some other day. For now, I invite you to read up on it at Wikipedia or just go play it right now. All caught up? Great! What I want to take from StarCon 2 is it’s fantastic exploration gameplay. See this map?

That’s the galactic map from the game. Each one of those dots is star system with multiple planets and moons. That’s a lot of exploration. It’s not all aimless, though. The game does a good job of telling you about your next story-driven goal but it is vague in where to go to complete that goal. No waypoints or breadcrumb trails here, kids. The game might say the next alien race or plot point you need to find is in so-and-so quadrant, but that might be halfway across the map and have 20 systems in it. Your ability to travel to them is only limited by your fuel and you will run out of that quickly. Luckily, each system you explore is loaded with resources (things like iron, uranium, calcium, and so on) that you can collect and sell back to your home base. That in turns allows you to buy larger fuel tanks and faster engines allowing you to push out and continue your trek around the galaxy. You can also buy weapons that help kill the things that wish to harm you around the galaxy.

This explore-gather-improve cycle is the key feature I want to build upon. Star Con’s only “failure” is this large map is static. It’s always the same systems, aliens, and resources. Even though the sheer number of locations out there makes it difficult to memorize where everything is, after a few times through it you’ll know the critical path and the game loses a lot of its wonder. The universe needs to be procedurally generated. Every time you play, it’s a new galaxy. That’s where Rogue comes in.

Rogue

Rogue was a game designed to offer a single-player Dungeons and Dragons-like experience. Every time you play, the dungeon is generated randomly. You explore turn-by-turn, gather loot, and then usually die. Rogue is also a very hard game. It can be beaten; I’ve just never done it. Rogue inspired its own genre, funnily enough, called Roguelikes (some Wikipedia there for you). I want to give the gameplay of Star Control 2 a roguelike twist. That’s my inspiration and I’m not the first. Games like Weird Worlds: Return to Infinite Space and Transcendence have beaten me to the punch. Thankfully, they prove that it’s a fun model. But…

Turns out it’s pretty hard

One, there is a lot of depth to both Star Control 2 and Rogue. Mashing them together is just even more content for me to make and that’s hard for just one little engineer to manage. Two, I keep changing my mind on every little bit of the game design while I am making it, usually meaning I have to start over. These are reasons why I have made this blog and why I came up with my Four Step Plan. This project is large undertaking. It’s the sort of game that could constantly be expanded with new content. It will never be finished. All this makes it hard to define just what the minimum is needed for a version 1.0. Or for that matter, version 0.1.

I want to nail down the core game experience; a “complete” ten-minute (or so) session that embodies what I am trying do. Some people in the audience might be chuckling to themselves, saying this is just basic prototyping and iteration. Well, yeah, but I’ve never made my own game from scratch before, so shut up! My projects have always had design docs and task lists provided by talented designers and lead engineers. Now is my time shine as I learn more about the process and grow my skills. But I’m not done with the background material yet. I have been mulling this around in my head for over a year and there have been prototypes. The next couple posts will deal with what I have tried and I’ll discuss my current vision of the game. Stay tuned!