Kickstarter success! Wrap-up post with stats and graphs

kswrapup

Last week Predestination officially succeeded on Kickstarter! Thanks to a huge push in the last few days of the campaign, we managed to hit over double our initial goal and smashed the three biggest stretch goals. We’ll now have a full singleplayer story campaign, play-by-email and full online multiplayer for release.

We’ve decided to wrap up the campaign in the same spirit of transparency that we intend to keep up during Predestination’s development, so I’m releasing a ton of stats that are normally kept for the project creator’s eyes only and discussing some of the lessons we learned throughout the campaign. This kind of info from previous projects was invaluable when I was researching and putting together this campaign. I posted this originally as a Kickstarter update, but am posting it as a blog post so it can reach more future Kickstarter project creators. It’s a bit of a wall of text, but hopefully future Kickstarter creators will find it useful!

(More updates on the way)

Continue reading

90% funded on Kickstarter, help push us over our goal!

We launched Predestination on Kickstarter a few weeks ago and the response has been absolutely immense! Over 500 people have backed the project so far and we’re at around the 90% mark. There’s just 10% to go until we’re guaranteed funding and can press on into stretch goals. It’s very important that we hit 100% as soon as possible, because that guarantees we’ll get our minimum goal and we can take that guarantee to banks and government grant schemes. If you haven’t pledged yet, head over to Kickstarter and take a look at some of the rewards you can get for supporting Predestination.

Thank you so much to everyone who has pledged their support so far! If we exceed our goal, we’ll move into the stretch goals to let us add extra features like multiplayer, a singleplayer story campaign, tools to let players mod the game and design their own levels, and other features we can’t realistically fit into the $25,000 minimum goal. There’s still a long way to go if we want to make the ultimate 4X game, and with your help we’ll get there!

New screenshots: Galaxy map, planets, system window and planet exploration

There are some big announcements coming in the next week or so for Predestination, but until then we have some new screenshots of the game in action. These screenshots show the three main parts of the game: Galaxy Management, Planetary Exploration, and Tactical Fleet Combat. All three areas are still work in progress, but they’re really starting to come together.

Concept art: Robotic races

Not all the races in Predestination will be organic; The race below assembled itself from a crashed transport full of worker droids, service bots and military hardware. To survive, they had to adapt themselves  to their new home and fossil fuel energy sources. We haven’t named the race yet, but the population and ships will have a steampunk visual style. Different tasks like industry or research will be completed by specialised robots, so the military robots may look very different to the researchers or workers. Below is concept art for the race’s industrial worker droids, produced by our new character artist Connor Murphy:

Unique race gameplay

In the last post, I talked about the fact that each type of race is specialised for a particular type of planet: Aquatics on ocean worlds, robots on ice planets (so they can overclock themselves), lizards on deserts etc. But the differences between the races go a lot deeper than just their preferred planets and some stats. Every race type will have its own unique gameplay that suits that race, and a research field that only that type of race can access. Our current thinking for the robotic races is to give them:

  • Factories that build new population rapidly.
  • Population consumes energy instead of food.
  • Unique technologies let you upgrade the population or produce huge mechs and ships.
  • Terraforming technology lets you freeze over planets, turning them into ice worlds.

What kind of unique gameplay and technologies would you associate with robots? If you could have any feature in a robot race, what would it be?

Combat system update and prototype video

Made good progress on the combat system this week. It now has:

  • Movement mechanics: Left click moves ship to the selected square, right click turns toward the selected square, end turn button cycles to next ship in initiative order
  • A glowing line indicates the path ship will take to the square you have the mouse over
  • A ghost ship shows where your ship will end up and what diredction it will be facing
  • Ships smoothly animate along the selected movement path
  • Ships now have weapons
  • Weapon firing arcs are working and show on the grid when you activate the weapon

To see the system in action, check out the prototype video below. Please post any comments you have on it and I’ll use them to help refine the next iteration.

Next I will add:

  • Attacking other ships by clicking on one in range once the weapon’s active
  • Shield and armour hitpoint system and basic hitpoint meters (will develop a nice UI for this later)
  • Highlighting enemy ships in range when weapon is active
  • The Reactive Strike system
  • Togglable weapon view: See all enemy weapon firing arcs on the map, move mouse over square to see how much damage you could take in a reactive strike if you enter that square
  • UI buttons and hotbar system
  • Non-weapon modules: Shield/armour repairers, afterburners (add movement speed, has a cooldown) etc.

Why turn-based?:

A few people have asked me why I chose to go with a turn-based combat system, so I figured I’d answer it in this blog post. The reason I’m making Predestination is that I want to make the kind of game that I’d love to play, and one of the things I loved about the older generations of 4X games is the level of strategy and tactics involved. I think newer 4X games have lost a lot of the tactical gameplay that the classics had, partly because many of them focus on realtime gameplay and controlling massive fleets of hundreds of ships. So I decided to go with classic turn-based gameplay for the main game and combat based around directly controlling a small number of individual ships.

When it came to the fleet combat system, I was torn between turn-based gameplay or a system where both fleets give their ships commands and then all the ships execute their turns at the same time. The latter system has a lot of tactical potential, as you could limit the number of commands a player can give and ships can be destroyed before carrying out their objectives. I didn’t like the way it disconnects players from their moves, adding a lot of unpredictability to combat so that even if you win it might not feel like you really made it happen. I want a system where your commands are immediately carried out and you instantly see the result, which means it has to be turn-based.

Chess-like tactical gameplay:

The combat system will produce gameplay that feels more like a game of chess than an RTS. If you’re the kind of player who loves to strategise, you’ll have the freedom to sit and think about each move for as long as you need, weighing up the options and considering how the other player will react. You’ll be able to build strategies around clever positioning and blocking off areas of the battlefield, and to employ clever tactics to beat an opposing fleet that outnumbers and outguns you.

If you aren’t interested in playing intergalactic chess, you can design simpler ships that don’t use the Reactive Strike system or tactical weapons, or even disable Reactive Strike altogether when starting a new game. We might even make tactical combat optional for people who just like the colony management side of the game.

 

The response to the combat system has been really positive in the comments and I got some great positive feedback about the idea at QCon. It seems a lot of people are looking forward to tactical turn-based combat where you control individual ships of your own design. As always, if you have any suggestions or feedback, please leave a comment!

Tactical space combat: A prototype design

My original plans for tactical space combat in Predestination involved making a good attempt at turn-based 3D combat, which is something no game has done well yet. I had intended to make line-of-sight mechanics and area effects a big part of the gameplay, but every combat would have quickly become a chaotic mess. Our main goal with Predestination is to bring proper turn-based strategy back to 4X games, so after discussing the idea with the rest of the team we decided to use a classic 2D combat plane on which tactical decisions are much more obvious.

I started prototyping the combat system last week with a chess board and some coloured squares, but I quickly ended up with pages of complicated rules and movement/attack tables. The Art Director suggested a hexagonal grid and we quickly hashed out a very simple, intuitive system using that grid that we’re all very happy with. We prototyped the system using a big hexagonal gaming mat and paper cutouts and ironed out all of the flaws we could see. The end result is a tactical combat system I’m really excited about:

Movement on a hexagonal grid:

Each ship has a movement speed value based on its size and thrusters. I costs 1 move speed to move into any of the three hexagons in front of the ship, and 1 move speed to turn the ship by 1/6 of a hexagon. These two simple rules combine to produce the movement chart below, which shows the minimum movement speed required by the ship to reach each square. The turning costs make it faster to move forward than sideways or backward. You might be able to get special engine mounts that decrease turning cost or increase speed but make turning more expensive, which would produce very different results.

Attacking on a hexagonal grid:

Each weapon has a range in squares and a firing arc type that determines the area in which it can fire. The default is a standard forward arc the covers the three squares in front of a ship and those in front of it, and doesn’t spread out. Other possible firing arcs include an extended arc that spreads out, a focused arc that only covers squares in a straight line, and a 360 degree arc. You’ll modify weapons to use particular firing arcs by fitting them on a special weapon mount. For example, an artillery weapon mount might double the weapon’s range but reduce its firing arc to a focused line, or a point defense mount could half a weapon’s range but give it an extended firing arc and another bonus. 360 degree arcs would probably have to be restricted to starbases, stationary defense platforms and point blank area effect weapons. Two examples of firing arcs are below:

Reactive Strikes:

One of the main goals for Predestination is to add more strategy to today’s 4X gameplay, so for combat we knew we had to do something more strategic than basic move and fire gameplay. We drew some inspiration from chess to come up a system we’re calling Reactive Strike. When a ship moves into the firing arc of an enemy ship, that enemy gets a free automatic shot at him. Moving out of a ship’s firing arc doesn’t cause a Reactive Strike, but every square you move that ends with you inside someone’s arc will cause one. There’s no limit to the number of times a ship can fire a Reactive Strike, so if you move through four squares that are each in an enemy ship’s firing arc you’ll be fired on four times! These shots are free, they don’t use up a ship’s movement or firing for the turn.

In the image above, two Destroyers with 2-range forward arcs are blocking a Battleship’s movement. If the battleship moves into any of the light red squares, he’ll trigger a reactive strike from either ship. If he moves into the darker red squares, he’ll trigger a reactive strike from both ships as these squares are in both Destroyers’ firing arcs. In real game situation, the battleship would probably opt to stay still but turn and fire on either ship. This could be part of the red player’s strategy, to stop the battleship moving forward for one turn by sacrificing small ships. There’s also nothing stopping a player from doing this with larger and tankier ships.

The goal of this system is to make moving and positioning your ships more than just a matter of getting in range to shoot. Ships can group together to form barriers to enemy movement, areas that if the enemy moves through them he’ll be torn to shreds. You might decide that the chance of being hit and damage dealt on a Reactive Strike is low enough to take the hit, or use longer range guns to outrange the enemy’s firing arcs. There will even be special weapon mounts that increase the damage done by Reactive Strikes, allowing smaller ships to really threaten larger ones. I could also make weapon mounts that increase a weapon’s damage but remove its ability to fire Reactive Strikes.

 

Inititative system:

A problem that every turn-based game has is that the player who goes first gets a major advantage. I’ve tackled this problem with an initiative order system that merges both sides’ turns into a single action order list. Every ship on both sides of a fight rolls initiative and ships then take turns from highest to lowest initiative score. The initiative order of all ships is known at all times, so you can plan a combat strategy around knowing that certain enemy ships won’t be able to move and fire for a while. The initiative roll is a random amount plus the ship’s initiative bonus, with smaller and faster ships getting a higher bonus.

This means each side will reliably start the fight with its smallest ships, so you can build a strategy around those ships. For example, you could give all of your frigates point defense weapons and set up a perimeter to stop the enemy breaking through to your bigger ships. The battlefield will be big enough that players can’t reasonably get in range to fire on the first turn, so the first turn will be about moving your ships into tactically superior positions to the enemy. You’ll block off areas with your firing arcs, move to the sides to try to get in firing range of an enemy without entering his firing arc, etc.

 

I’m very excited about this system and hope to start programming an in-engine gameplay prototype soon (as free time allows). I find that the best tactical gameplay usually arises from the interaction between a few simple rules, and I think the system above captures that well. All the rules are simple enough to pick up in a few minutes, and yet in our pen-and-paper prototype play tests we found quite a bit of complex strategy coming out of them. Elements like firing arcs, turn order and valid movements can be easily shown via the user interface, and the Reactive Strike system turns the battlefield into a chess board. If you have any feedback on the system above or suggestions for ways it could be improved, please leave a comment and I’ll definitely take it on board.

Planet graphics update

I came up with a new terrain shading technique that combines some clever texture packing tricks with normal approximations in the pixel shader to produce some awesome results. The lighting on the terrain is now extremely highly detailed, and zooming down onto the terrain looks perfectly smooth. I can also feasibly add more lights for particular buildings or the cursor to make some awesome effects. Below are a few screenshots of the current work in progress:

Planet with new lighting:

I’ve gone back to the idea of having night and day on the planets, so sometimes your colony will be in night time. To help with this, I’ve added semi-ambient lighting for night time. When a colony is in night time, it will have its own light coming from it and you’ll see the city street lights sprawling out from it, once I get around to implementing those features. The water still needs some work and I need to develop an atmosphere layer with clouds.

More pictures after the break!

New lighting: Zoomed in closer

This is about the zoom level at which you’ll be searching for stuff. I’m thinking this area will be divided up into a grid and you’ll send scout ships to each sector on scout and survey missions to locate resources and random lucky finds.

Building placement level: Closest zoom

This is the level at which you’ll manage your colony, place extractors and so on. I’ve been experimenting here with a new camera angle — when you get down this far, the camera pans up to give a 45 degree RTS style viewpoint. This should show off the buildings a bit more, but it’s tricky to get right due to the way my terrain is implemented.

Zooming down from the planet to the surface is all done in realtime and the transition is perfectly smooth. My new shading technique makes zooming super smooth comes at the cost of some performance as it places a lot of load on the GPU. It still runs at 30-60 FPS on my five year old PC, however, and I’ve managed to claw back some performance through optimisations.

Planet view and placing buildings

Most of this week’s work on my space 4X game has been in putting together a good system for placing items like 3D models of buildings on a planet’s surface. Part of the difficulty is in the fact that the planet graphics are generated entirely on the GPU, so the CPU doesn’t have access to that data. I came up with a fantastic system that works around that issue and gives access to not only height data but also details like what type of terrain is on a particular spot or whether it’s in an ocean.

So now I can place buildings on the surface of a planet, zoom out, rotate the planet and the building appears to stay put on the surface. When placing certain buildings like a water extractor, I can make it only placeable on water or make it fulfil any other criteria I want. I could make mining drills that you move around to find the best spot, or geothermal power stations that can only be placed on fault lines. There’s a lot of versatility in the system, so it’s been fun to work with this week.

Right now you can go into the various planets in the generated galaxy and place buildings anywhere on the surface at all. The plan is to define specific colony sites that you can build a base colony building on, and then buildings must be placed on a grid surrounding that building. It’s a gameplay restriction that has to be done for balance reasons, and to make the city blueprint system work. Certain buildings will require extractors, like fossil fuel power plants will require a coal mine and factories will require a mineral mine. You’ll send scout ships out on survey missions to find resources and then place the extractors on them to make the building start up.

Graphics:

The main colony area is is where important buildings like factories and research labs are all placed, and extractors are placed far afield where resources are located. Graphically, I need a way to show the population increase in a colony. As the colony’s population grows, you’ll start to see a sprawling network of roads and houses emerging from the main colony area. By the time a colony is at its population limit, the area around it (example: most of the screenshot above) will look very developed.

I’ve been experimenting with different light angles for the planets, and although right now I have maintained authentic lighting angles based on the angle of the planet and its point in its stellar orbit, it often doesn’t look very good. A colony area might sometimes be in darkness, or glaring sunlight that makes the terrain look flat. Ultimately, graphics take priority over realism in a game like this, so I’ll likely lock the lighting to an angle that makes whatever’s in the center of the screen visually pleasing at all zoom levels. I’ll post some screenshots of this when it’s done.

http://www.youtube.com/watch?v=oRVbvG-TpJc Predestination 4X game Galaxy Map: System window demonstr

Predestination 4X game Galaxy Map: System window demonstration

Please watch fullscreen (1080p available). The video’s a bit darker and a lot blurrier than the actual game because YouTube is bloody awful at encoding videos, but you get a clear enough idea of the effect in fullscreen.

This is an update on the galaxy map. I’ve built the system window, and designed a smooth transition for opening it. When you click on a star, the star rises out of the background and its planets fade in, then the window around it fades in. When you close the window, the star shrinks again and visibly moves toward the star, even if it’s moved since the window was opened. So far all planets have terran graphics, but the distribution rules are already in.

I originally had a full solar system model with accurately modelled inner planets, gas giants, eccentric orbits etc, but for gameplay reasons I’ve had to simplify it down to a maximum of six planets. It would just be far too difficult to actually click on planets if I had proper solar systems, unless I made solar system view its own full screen and gave it zoom/scroll controls. I don’t think that would add much in terms of gameplay, and it would be irritating for people who want to quickly get to a planet. This is definitely one of those cases where I deferr to MOO2’s design, because if it’s not broken there’s no need to fix it.

After testing the system I displayed in my last video wherein the camera centers on a clicked star and the galactic plane comes up to the level of the star, I found it far too clumbsy. Trying to open the system view when you have to double click on a star that starts moving after the first click isn’t particularly fun. I’ve removed that mechanic and now instead just have the system plane right in the middle of the stars. I find it still provides enough perspective, and in terms of usability it’s a lot more friendly on the system window mechanics.

Like the system window transition effect?

http://www.youtube.com/watch?v=_QCmvsKSXic A video of the 3D galaxy map for Predestination. Please w

A video of the 3D galaxy map for Predestination. Please watch it in 720p fullscreen, otherwise a lot of important small details like the lines between stars and the galactic plane are lost. A video makes it much easier to see how the plane and lines help maintain perspective, and makes it possible to show off a nice new supernova graphical effect. The supernova effect is similar to the one used in the background supernova remnants, but modified to look good in 3D as you pan around it.

Anyone have any feedback on it so far or does anyone have a question they’d like answered?