April Dev Update: New aquatic race, ship combat update, battlefield generation, and more

Posted by Brendan Drain on May 8, 2013

April is over and development on Predestination is going well. This month we completed the internal workings for the ship design and weapon technology systems, finished hooking the tactical combat system into the main game and tidied that system up. We implemented tons of your ideas into the ship combat system, like smart-missiles that deploy mines around the target, weapons that fire clouds of charged plasma, and deployable minefields for planet defense. Thanks so much for all of your great ideas and feedback!

Character artist Connor Murphy has finished our final core race (the yet-to-be-named Aquatic race) and completed a fantastic visual reboot of our first robotic race, The Starforged. You can see the new artwork for both races below! We’ve also been working with Connor on figuring out the best way to approach the backer-sponsored race artwork.

Based on your feedback, Connor has already started to revamp the feline race we showed in last month’s update with more realistic artwork that matches the rest of the game’s visual style, and I think you’ll be pleased with the results when it’s finished. Once that’s finished, we’ll be in touch with all of our race designer backers to get started on getting them into the game.

The yet-to-be-named Aquatics are our sixth and final core race apart from the backer races, and we’d love to hear your ideas on what they should be like in-game. We see them as aggressive militarists who see ownership of every ocean planet in the galaxy as their sovereign right. We see them as a dictatorship that interacts with other races through intimidation and military threat more than diplomacy. Industry and research would probably take a hit from working under water, but their natural hunting instincts would make them excellent ship pilots.

The Aquatic race will definitely start the game with some kind of mech suit that grants bonuses to ground combat, as they needed this technology to achieve space flight and interact with other races. They are just as at-home on Terran planets as Ocean, but would probably actively flood Terran worlds to make them less useful to other races. They may also have developed technology that can thaw out a tundra planet by injecting radioactive elements into the planet’s core and flooding the atmosphere with greenhouse gases.

Rather than deciding on the race’s abilities and name ourselves, we’ve decided to open the Aquatics up to the community! We’d love to hear your suggestions for a name for this race, stats or traits you think they should have, and any special technologies they should start with. We’d also love to hear your ideas on what technologies and special traits you’d like all aquatic races in Predestination to have. Leave a comment here or head over to the aquatic race feedback thread on the forum and let us know what you think! We’ll publish a full race reveal in two week’s time when we’ve picked our favourite suggestions!

Above is the rebooted artwork for The Starforged, the first race we revealed during the Kickstarter campaign. Connor felt that the art needed an update to match the visual quality of newer races like the Sauros, and I think he’s done an amazing job on the reboot. The Starforged soldier unit is on the left, the scientist is in the middle, and the worker/civilian robot is on the right. We’ve nicknamed the worker the “Espresso machine”

Combat resolution: One of the things we implemented this month was the combat resolution system that decides when fights happen and what the battlefield looks like. Fleets in Predestination move in FTL once per turn and only meet each other at destinations like stars and temporal rifts. When two fleets meet, both players can select from four courses of action and the combination of options selected determines what happens:

Attack Planet: Attempt to attack a selected enemy planet in the system. The enemy must have a planet in the system for this option to be highlighted. You start on one side of the battlefield, and the enemy planet is visible in the background on the other side. Planetary defences like starbases and orbital cannons are automatically placed on the enemy side.
Defend: This puts your fleet into a defensive posture and does not engage the enemy fleet. If the enemy fleet selects to attack a planet in the system that you own, your fleet automatically defends that planet and is included in the combat against that planet.
Intercept: Attempts to intercept the enemy fleet early and engage. If the enemy fleet selects Attack a planet, this option will instead engage the enemy in open space (no planet bonuses). If the enemy fleet selects to Defend, there’s a 50% chance that you’ll catch them in open space and start combat and a 50% chance that no combat will happen at all.
Retreat: Attempts to retreat and set course to the nearest friendly star system. If the enemy fleet selects the Intercept option, there’s a 50% chance of catching your fleet and beginning combat in open space and a 50% chance they get away safely.

Battlefield generation: The battlefield will now take into account the star system you’re in. Battles in systems with asteroid belts are likely to take place inside the belt, while battles inside a nebula will be filled with nebular gas clouds. Battles over a planet will also display the planet in the background behind the defending fleet, and orbital cannons and starbases will be placed on the battlefield.

We have a few more ideas up our sleeves for more natural battlefield modifiers, like pirate hideouts in a system or even space monsters interrupting your battle! The battlefield size will also scale up with the number of ships involved and the maximum range of the ships involved. This way every battle will start with the opposing fleets placed between one and two turns worth of movement away from each other. This should stop snipers from dominating as nobody will be in range to fire on the first round.

Ship placement round: Before each combat begins, you’ll place your ships and structures on the battlefield. We plan to make it possible to pre-design a layout and save it with your fleet for future battles, but right now that feature is not implemented. Battles in orbit of a planet will have starbases and orbital cannons in fixed positions if the planet has built them. Researchable technologies will also add deployables like mine fields, shield bubbles, cloaking fields and nebulae so you can come up with a clever strategy for system defense and design your ships around them. The ship placement phase is a blind phase, so you don’t know where the enemy has placed his ships or structures until you submit your layout. Think of this like setting up a chess board, except you get to decide where each piece goes.

First combat round: The first round of combat after placing ships in Predestination will be mostly movement. The longest-range ships will not be in firing range of the enemy fleet yet; missiles and drones can be fired but will take at least two turns to reach the enemy. This lets you set up strategic positioning to counter the enemy’s selected fleet layout. For example, you may notice that the enemy has laid a minefield in front of its snipers and decide to send ships around the side to avoid them.

The rest of the combat: The player’s and enemy’s ships will will take turns as usual for the rest of the game, like a game of chess where each move is a reaction to the other player’s. For example, the enemy may fire missiles at your large battleship and you may move some point defense frigates into positions where they can shoot down the missiles. Combat ends when all of one side’s ships have been eliminated or are no longer on the battlefield. Ships can retreat at any time during the battle by activating the Warp Drive module (built into all ships). This has a charge-up time of one full round, making the ship leave the battlefield on its next turn.

We’ve been working on a lot of the core planetary and fleet combat code of Predestination so far, but it’s difficult to show off interesting ship weapons or galactic exploration without a good user interface. The next step for us is to work really hard on those user interfaces and get as many of them into the game this month as possible. As a side-effect, we’ll be able to show you more of our progress in videos and live demos, giving a clearer impression of how the game will actually play when it’s finished.

So far we’ve focused on trying to put together one big monthly update for our Kickstarter backers and fans following the Predestination development blog. We’re doing a lot of work steadily throughout the month but then trying to cram it all into one roundup article like this or a race reveal post. We’ve had a few requests from backers for more frequent updates and more community engagement, so I wanted to put this question out to the community. Would you like to see more frequent updates containing earlier work-in-progress artwork, game development, user interfaces, buildings etc? Our options are essentially:

Monthly updates: One big update every month summarising that month’s progress (like this post).
Frequent updates: Posting early work-in-progress artwork, buildings, gameplay and user interfaces separately with just a few lines or paragraphs of text explaining each one.
Both: Do the smaller updates, and then summarise them each month in a smaller roundup article on the blog and Kickstarter.

We’d love to start doing more frequent updates if that’s what the community wants. The updates would be a lot more rough and subject to change, but it would let us collect feedback earlier in the development process. Please let us know in the comments or head over to the official update poll on the forum and vote!

Cheers,

– Brendan, Lead Developer

New colony system, what do you think?

Posted by Brendan Drain on February 10, 2013

In last week’s development update, I showed recent work on the planetary colonisation that made the exploration grid visible from orbit. This week I updated it so that you can even direct your exploration efforts from orbit and developed a new resource distribution algorithm, but I ran into a small problem: If you add in enough resources to keep exploration interesting, you’d end up with a ton of colonies to build on each world. To solve this problem, I decided to try out a new system inspired partly by Civilization.

The old system:

Planets are currently covered in randomly distributed resources and pre-defined city locations. Cities are residential colonies with lots of building space that is used for housing and big buildings like shipyards, while resources are small colonies with 6 building locations. Resources are only accessible in the resource towns themselves and the materials collected are stored in material silos. You’d need to design separate blueprints for each resource and for residential cities, and there’s not really much choice in where your colonies go or what they’re set up to do.

The new system:

The new system covers planets randomly in resources as normal, but players can decide where to build their cities! You can set up a city in any suitable location (on flat land for most races). Resources are no longer mini-cities with building spots, instead you set up an extractor like a mining drill and then tell it which city to ship the materials to. It’s up to that city to use all the resources that are linked to it. There may be a logistics cost for linking a resource to a colony far away, and you would be able to set up trade routes between cities to move resources around more efficiently.

There’s only one type of colony in this system so it’s up to you to decide how to lay it out and balance housing space with industrial output etc. You would only need to design blueprints for the different types of colony you want, for example you could have one for a production colony that uses 4 ore per turn or a residential colony that needs 20 food and 2 coal per turn. To keep things balanced, we would simply impose a limit to the number of cities you can have on a planet based on its size. Instead of having 5 residential cities and 30+ small resource towns pre-placed on a planet, now we’d just have 5 manually placed cities that split the 30 resources among them.

What do you think?

Which system do you prefer, and are there any other issues you can see with the new colonisation system?

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

Posted by Brendan Drain on November 18, 2012

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.

Planet exploration update and terraforming idea

Posted by Brendan Drain on August 27, 2012

The Predestination team gained three new members this week: a new concept artist, a 3d modeller and a composer have officially joined the crew. The artists have been working on new animated buildings for the colony screen this week, and our composer has been producing some awesome sci-fi music for the game. I’ll properly introduce the new and current members of the team in my next update and can hopefully show you some of their handiwork soon.

This week we’ve been working on fleshing out the designs for the races we plan to have at launch, and I’ve been implementing a hex-based planet exploration system to go with the hexagonal colony system described in the previous update. Players now have to explore outward from the starting colony as you can only explore hexes on the border with unexplored areas. Exploring a tile reveals what’s on that tile (if anything) and pushes your borders back, letting you see what all the surrounding squares look like. Below is a screenshot of the new system in action:

This is the way it looks in-game right now and this is how you’ll explore your planet at the start of the game before you develop scanning technologies and satellites.

Terraforming:

If you saw our QCon trailer, you probably noticed that terraforming is listed as a major feature in Predestination. Our planet engine can morph a planet’s surface and environment in realtime, which we can use for things like bomb craters, raising and lowering sea levels, changes to how rocky a planet is, and gradually changing terrain types. We’re currently discussing how to use these capabilities for terraforming, and I want to publish some of our current ideas so people can provide feedback:

Each race type is happy on one particular type of planet: Aquatics on ocean planets, Robots on ice worlds, Reptiles on Desert etc.
On your race’s preferred planet type, there are multiple suitable locations for cities and all resources are visible and can be colonised. On the wrong type of planet, a race will have penalties, and will only be able to find a small number of city locations and resources.
You’ll be able to research technologies to convert some planet types into others, such as a massive reactor or greenhouse gas generator that can slowly transform an ice world into an ocean planet. Each use of the device will require a massive burst of stored energy, so the player will activate it every now and then when the colony has built up enough energy and see the change instantly.
As a planet gets closer to your race’s favoured environment, new resources and city locations will be revealed.
Terran planets contain ice, ocean, desert and temperate climate areas, and all races are happy on these worlds. Every race can colonise all the resource and city locations, but will still have the ‘wrong planet’ penalties in cities in unfavourable environments.
Terran planets will be delicately balanced environments, so heavy fossil fuel use could cause the planet to heat up and the ice caps could slowly melt, raising the sea levels and destroying valuable coastal towns. Nuclear bombs could also trigger a nuclear winter and turn it into an ice world, and heavy industry could pollute the oceans and destroy resource towns under the water.

If you have any feedback or ideas of your own, please feel free to leave a comment!

A brand new planet colonisation system!

Posted by Brendan Drain on August 12, 2012

This week we did a major design iteration on the planet colonisation system. In the previous design, the planet was split into a huge square grid and you could send scouts anywhere to find resources. Extractors were built on the resources and they were piped to the planet’s main colony for use, so if you found a mineral deposit you’d build a mining station on it and the colony would then have +1 minerals/turn for use in factories.

After some testing, I found that it felt like I wasn’t really colonising the planet; I was just exploring it because I had to get it out of the way, and that’s not fun. Since I could see the terrain and knew where resources would spawn, I tended to go straight for those areas and there wasn’t much left to find in the entire planet. There were also unanticipated problems with designing a reusable colony blueprint: How do you know how many fossil fuel power plants or factories to build if each planet has a different number of resources? And what happens if the blueprint finishes building all your factories but you haven’t found the minerals to supply them yet? This week’s design iteration solved all of the above problems.

Residential cities:

The new design splits the planet up into a hexagonal grid and you can only scout hexagons adjacent to currently explored areas, so you have to explore outward. Unexplored areas are black so you can’t see the terrain, and the hexagons for scouting are huge so you won’t spend forever exploring the planet. Most hexes will be empty, but some will contain resources or suitable locations for additional residential cities. Below is a mocked up image of the city planner:

Tiny planets will have just one viable city location, and larger planets will have several. These cities will be fully independent colonies on the planet, each housing its own population and requiring its own energy generation, military protection etc. All of your important buildings will go in the cities, but it’ll be mostly residential and military. You can have multiple of every building and their effects stack, so you could build nothing but power generators and orbital cannons or mostly housing and entertainment centres to generate tax, it’s up to you. Later in the game, new technologies will give you more space in every city.

Resource gathering towns:

When you find a resource like a mineral deposit or research artifact, you now colonise it with a small industrial town. The town starts with just the extractor building (such as a mining drill or research outpost) and 6 empty hexagons around it that new buildings can be built on. Rather than always sending the resource to the main colony to be used, you can use buildings here to refine it locally and either use the refined product immediately or send it elsewhere for stockpiling. Below is a mock-up of an example town:

In a mineral mining town, you might build an ore refinery, a metal factory, a few power plants and a transport link to an orbital shipyard. This little self-contained town would then send metal to your shipyards each turn, where it’s stockpiled to be used to build ships, missiles, etc. You can build your towns manually or design blueprints to save your designs and help update them later. So you could colonise a uranium deposit and select between blueprints you’ve designed for nuclear power generation, uranium processing for sale, or a nuclear weapons factory and missile silos.

With limited space to build buildings, you’ll have to make tactical trade-offs between money generation, military defense, research and ship production. Do you sacrifice a valuable square to build a shield generator in each towns to protect it from orbital bombardment, or a weapon to help in fleet combat above the planet, or more industrial buildings? I’m leaving it entirely up to the player to decide how to use the system. When it’s done, it’ll have to be tested extensively to make sure there are no clearly overpowered strategies and there’s no single best way to build a colony.

Population control:

Your colonists live in the cities most of the time and are rotated into the towns for work. Cities start with a colony base that houses 1 million colonists and provides food and water for them, and towns start with an extractor that does the same. In cities, you can build houses to increase the maximum population at the cost of using squares. You can’t build housing in towns to increase the population limit, they always have 1 million colonists. It costs 1 million colonists to establish a new town so all of your population growth happens in cities.

Each town links to its closest city and decreases its connected city’s morale because people really hate working in harsh industrial environments. Each unit of population in the city increases the city’s morale because more people in the city means people have to spend less of their time working in the industrial towns. You can build entertainment centres, police stations and other services in the city to increase the morale bonus each colonist gives, so balance the morale on your planets with their industrial output.

Morale affects the amount of money that population can be taxed for and the chance of a revolt or worker strike. Robotic races would be immune to morale but also can’t tax their population. Communist races would force people to work in the towns, while democratic races might be able to pay their workers to reduce the morale penalty. There’s a lot of potential for race picks and new technologies in this system, and we’re still throwing a lot of ideas around about it.

I’ll implement the new colonisation system this week and will get a video of it up to show you the results, then I’ll get back to working on the fleet combat system .

Dev update: New planet exploration features

Posted by Brendan Drain on May 8, 2012

I got to work on the planet exploration a bit more this week, and added in a lot of the planet exploration features I described last week. You can now queue up as many scout missions as you want and they will be executed in sequence. When a mission starts, it takes an energy cost from the planet’s reserves, and if that energy isn’t available the mission will wait until you have enough energy before starting. You can now delete scout missions, and they are now sent from the nearest settlement you own for reduced travel time. Below is a video showing some of the new mechanics:

Resource Distribution:

I want players to be able to figure out the most likely places for resources to be before they start scanning, so there needs to be some kind of visual clue in the terrain. In the final game each planet will be randomly generated and put together from a large set of continents and islands, so whatever visual clues I use have to be obvious to players looking at unfamiliar terrain too. My solution was to pull in data about the height, slope, and environment type of points on the map and assess them for suitability. The new system works like this:

Ore deposits: Found in elevated areas with a high slope (mountains, crater rims etc). Each planet has a certain number of ore sites based on its size and mineral richness. So a small mineral poor planet may only have two or three of them but a large rich one could have 20 or more. You’ll build mines on these to extract them, which produces one ore per turn. Certain buildings (factories, shipyards etc) will require ore each turn to function.

Fossil fuel deposits: Found on land in terran, swamp and gaia worlds, sparse and randomly distributed on ocean and tundra worlds, and not available on any other planet types. You’ll extract these with a mine/drilling station, providing 1 fossil fuel per turn to the colony. You can use this to run fossil fuel power plants, and certain types of factory will require both fossil fuel and ore to work. Fossil fuel power plants will output more energy per unit of space than renewable resources, so they’re more efficient but at a cost. These deposits might have a finite number of units in them.

Uranium deposits: Very rare, and found on land. You’ll extract this with a uranium mine, and will need a special storage facility to keep it in. You can use it to fuel nuclear power plants, which output more energy per unit of space than fossil fuel plants. It’ll also be required as a resource to build certain things, like long-range nuclear missiles that you can launch at an enemy planet.

Food sources: Found around the coastlines. The number of these has a random factor but is based on the planet’s climate, so terran planets will have more than ocean or swamp. There are none on desert, barren, molten, toxic, or tundra worlds. You’ll build farms on these, each one increasing the food output of your farmers by a certain percentage.

Research materials: On terran, swamp and gaia worlds, these are found just off the coast and in icy regions. You’ll build a research station on these, increasing the research generated by your scientists by a percentage.

Ore, fossil fuels and uranium will all have intermediary storage buildings that you can use as a material buffer to store production up when you aren’t building anything. If you have 10 ore per turn coming in but your shipyards can use 20 per turn, you might want to store up materials for a while and then quickly burn it all on ships. The ability to store materials also opens up some interesting diplomatic options, like trading resources with other races. You could stockpile uranium and ship it to another planet to build weapons, or set up a trade deal to supply a neighbouring star with fossil fuels, or even just offer a trade of ore for technology.

Second iteration on planet exploration system

Posted by Brendan Drain on April 25, 2012

There are lots of software development strategies, but the one that comes naturally to me is rough iterative development. The process starts with an idea for a feature, which is then used to produce a gameplay prototype. I try the prototype out to see how it feels, and show it to people to collect feedback. That feedback is used to refine the prototype into a second iteration, which is then tested and shown to people again to collect feedback. This cycle continues until eventually I’m happy with the feature. Usually I do all the testing myself and only show the prototypes to a few real life friends, but over the past few weeks I’ve been showing the prototypes to people via the blog. Even with just a few people commenting, it’s been really useful.

Last week I showed a gameplay prototype of the planet exploration system and got some great feedback. This week I’m back with the second iteration on that system:

The new system works as follows:

There are now a lot more squares to scan on a planet, meaning a lot more exploration is required.
There are now buttons for sending out missions of different sizes: 1×1, 3×3, 5×5 etc.
The scout travels to the center square of the mission, spends 1 turn per square surveying, and then heads back to base.
On arrival at base, the area is revealed and a survey report pops up listing what has been found.
You can queue up as many missions as you want and they’ll be tackled in order.
Missions have a cost based on the distance and number of squares surveyed, which must be paid up front when you schedule the mission. This makes it really expensive to scout far away places.

I feel like the basic scouting mechanics are now very solid, but I need to add a few more things to the next iteration of this system:

Option to cancel any scheduled scout mission before it begins to get a refund.
Some way to have multiple scouts? Maybe they’d just speed up the surveying process itself, and reduce its cost.
Scanners that can instantly scan squares in exchange for energy reserves.
Colonising settlements, and scout missions being sent from the nearest settlement.
Try out different “fog of war” effects for the squares. It might be better if unexplored squares were dark and opaque, and it’d work better on ice worlds than the current pale white.

Once those features are in, I’ll begin work on a system for placing extractors on resources. I should be able to get that done within just a few days if nothing comes up that stops me from working. I’ll post a video of it when it’s done. If you have any feedback on the planet exploration system described above, please leave it in the comments as it’ll be very useful as I do the third iteration on the feature this week. For example, should scout missions cost money at all or should the balancing factor in scouting far away places be just time?

Gameplay prototype: Planet exploration & resource discovery

Posted by Brendan Drain on April 18, 2012

This week I’ve been working on a prototype of the planetary exploration feature discussed on the Colonisation page. The plan was to split each planet up into a grid, and then have the player survey squares to find out what’s there. Exploration only needs to be done once for every planet, and it’s the only way to find resources or increase a planet’s maximum population. The idea is that every time you colonise a new world you’ll explore it and decide how to capitalise on what you’ve found. You might find the planet has a lot of ore deposits, for example, and build extra factories to take advantage of it. Or you might find ancient ruins to build research outposts on, or a uranium deposit that would let you put up a nuclear power plant.

As you progress in the game, you’ll get technologies that make scanning a planet faster and easier, like scanning tech that can spend reserve energy to scan a square, several squares, or a full screen instantly. Ultimately, you’d get the tech to automatically scan all planets from orbit so that when you’re in the late game war stages you don’t have to deal with the micromanagement of exploring new planets. Below is a video of the current gameplay prototype of this exploration system (using massive placeholder models for ore deposits etc). Watch in 1080p fullscreen if possible:

Things you can discover:

Ore deposit — One required per factory.
Ancient Ruins / Scientific curiosity — Build research outpost on this. Not sure if it’ll increase research output of colony by a percentage or if you’ll need 1 per lab like ore deposits for factories.
Food — Particularly good food source that you can build a farm on. Not sure how I’m going to implement this bonus.
Settlement location — Start settlement here to increase planet population. Cost of gathering resources is based on distance to nearest settlement.
Coal/Oil — Required for fossil fuel power plants, which output more energy than solar/geothermal.
Uranium deposit — Required for nuclear power plants, highest energy output.
Random discovery — Find new technology, stuff you can salvage for money, or something else.

What I’d really like feedback on is the exploration/scouting system itself. You currently send scouts out from the nearest colony/settlement, and they travel to the location, survey it, and return home. This doesn’t feel very fun as the scouts all come home at different times and you have to send them out individually again. If you go for a few turns without sending one out again, it’s a waste of a limited resource. Being forced to send them out constantly isn’t really fun, and I don’t want the player spending a lot of time in this screen.

So I’ve been thinking of removing the limit on the number of scouts and just charging the player a fee to send a scout mission. That way it becomes a financial consideration, and you don’t feel obligated to send a new scout mission out every few turns. You could wait a few turns, build up some money, and then send 10-15 scouts at once. It also means that when you colonise a new planet you can spend a large amount of cash to rapidly survey the surrounding area. and start building factories etc quickly.

Anyone have any ideas or suggestions on making this exploration process more fun?

Planet graphics preview

Posted by Brendan Drain on March 30, 2012

I’d like to thank Adam at SpaceSector for his awesome introduction post on Predestination. I’ve been a bit quiet this week, but have been working on the project. We’re getting forums and a website set up, and making progress on the trailer for the kickstarter campaign. I’ve also been putting together a few videos to show off various parts of the game. Below is a preview of the planet graphics in the game:

This week I started experimenting with a full-screen system window that allows for up to 12 planets instead of the standard 6, and gives more room for UI elements. When I’m done, I’ll post a video of the the normal sized one and the fullscreen one in order to get some feedback and decide on which is better. My gut feeling is that having 12 planets won’t really add much in the way of gameplay and would just take up valuable screen real-estate, and that too many planets per solar system might make the game too slow-paced.

Predestination – an indie space 4X game

Just another WordPress site

Tag Archives: planets