Energy as a tactical resource

I haven’t really talked about energy generation, energy storage, and what you’ll be able to do with energy yet, so in this post I’ll throw my current plans out there. Every building requires energy to operate, and if there isn’t enough energy some buildings will switch off until power is restored. There are several types of power plant available:

  • Solar: Basic renewable power source. Twice as effective on Desert and Barren planets. Doesn’t work on Toxic planets.
  • Geothermal: Basic renewable power source. Twice as effective on Molten planets. Doesn’t work on Tundra or Ocean planets.
  • Fossil fuel: Consumes fossil fuels, but outputs more energy than solar or geothermal plants.
  • Nuclear: Consumes uranium, and outputs more energy than a fossil fuel plant.

There’s limited space for buildings in a colony, so you’ll want to waste as few as possible on energy generation. Fossil fuel and nuclear plants will save you a lot of space, but will consume resources. You’ll be able to research technologies to improve power plants, and because we’re using a tree system for research, many of them will be mutually exclusive. You might have to choose between improving solar or geothermal power plants, or choose between renewable sources and fossil fuels.

Stored energy as a resource:

Any energy above the building requirements of the colony will be stored in any energy storage buildings you have. Stored energy will be a currency that is spent to perform tactically important tasks and take gameplay shortcuts. While resources like uranium, ore, and fossil fuels can be transferred between planets, energy can’t. If you need to use a lot of energy on a planet, you have to generate it there. Below are a few ideas for things you can spend energy on once you have researched the appropriate technologies:

  • Spying on enemy planets
  • Firing long-range missiles at enemy planets
  • Scanning planets
  • Firing ground batteries during a battle
  • Absorbing damage to the planetary shield
  • Creating wormholes
  • Destroying planets
  • Cloaking planets
  • Transporting material to other planets
  • Replicating material

Energy as an offensive/defensive tool:

Energy will be used to power offensive and defensive structures like ground batteries and planetary shields. During a battle in orbit of a planet, you will be able to spend stored energy to fire ground batteries at enemy ships, but if you lose the battle that will leave you with less energy for the planetary shield. If your ships are destroyed but you have a planetary shield, every turn the enemy can bomb the shield until it’s down. Once it’s down, they can either continue bombardment or send troops to capture the planet. When the shield absorbs damage, it draws an equal amount of energy from the planet’s reserves.

This siege mechanic will let players hold out for a few turns before their planets are taken over or destroyed, giving them time to mount a defense fleet or perform a counter-attack. It would be theoretically possible to make a planet with ridiculous energy generation capabilities and massive energy stores that could withstand a huge siege for a long time, but such a colony wouldn’t be very effective at anything else as all its building space would be used with energy storage and power plants.

 

Those are my current plans for energy, but as always they are subject to change as I start implementing the system and see how well it works. If you have any ideas for things you would want to be able to do with stored energy, please leave a comment with your suggestions. Nothing is off-limits right now as I’m still throwing ideas around.

Dev update: New planet exploration features

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

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

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?

Taskbar system and modular system windows

Every 4X game has a way to notify the player when something happens that requires his attention. Games will typically have a turn summary page reporting anything important, but I want a more direct visual notification that isn’t just a text list. The idea I’ve been prototyping this week is a taskbar that runs along the bottom of the screen and alerts the user to tasks that require their attention. If a planet has a building that needs to be placed or a problem that needs to be fixed, or if a discovery is made or a scout finishes surveying a planet etc, a small icon relating to the event will drop down into the task bar. When clicked, a window would open explaining the notification and with a shortcut button to go directly to the screen/window that will let you deal with whatever the notification is for. Either that or clicking the icon might bring you straight to the source of the notification.

For example, you could start building a colony ship and check a box that says you want to be notified when it’s complete. When it’s built, a little ship icon would drop down and land in the task bar. On clicking the icon, a small ship/fleet window would open and you could immediately give the ship orders. Similarly, if a survey mission on a planet completes, a notification could immediately appear in the taskbar and open the planet or solar system when clicked.

I got some great feedback on what type of system window to use, and have decided that a small self-contained window is the best option. This week I developed a modular window system that keeps track of all the windows that are open and has options to resize, close and minimise to the taskbar. The game now supports having multiple system windows open, which might be handy if you need to keep track of or compare multiple  systems. The video below demonstrates both the modular window and taskbar system:

System window view, full screen or small window?

I’ve tried out two different schemes for the system view: A small separate system window with evenly spaced planets like in MOO2, and a fullscreen version with more realistic full solar systems. I promise that I would put up a video of both to collect feedback, so below is a video with examples of each:

Small system window: This setup has the advantage that it doesn’t take up a lot of screen space,  so you can open it quickly while doing other things on the main galaxy map.  It’s limited to a maximum of about 6 planets/asteroid fields/gas giants, and would use the same kind of random distribution as Master of Orion II. The window can be used to quickly show information like fleets stationed in the system. I could easily make the window resizable, and there’s a possibility of having more than one open at a time.

Full-screen system window: This setup allows for more realistic solar systems, with up to 9 rocky planets, one massive asteroid field and up to two gas giants. The gas giants would orbit the system mostly outside the screen, and if gas giants are present an asteroid field can exist between the rocky planets and gas giants. Unfortunately, to get this kind of realistic planet distribution and still allow the user to click on planets this view has to take up the entire screen, meaning you could only have one open at a time and couldn’t have it open while watching other things on the main screen. It could allow for gameplay like exploring individual segments of an asteroid belt or moving fleets within a solar system, but it would also make it so gas giants couldn’t be used in any gameplay and would increase habitable planet density to up to 9 per solar system, which might be too much for large maps.

 

After testing both systems for a while, I’m still leaning toward the small system window. I’ve got a lot of positive feedback on it already and I don’t think the full-screen version brings enough to the table. I’m all for making the game look good and having more realistic solar systems, but I don’t want to do that at the cost of usability. Most of the game will be played on the galaxy map, and covering that whole screen up just to see what’s going on in a solar system or click on a planet might end up being a nuisance.

Planet graphics preview

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.

Head-tracking in Predestination, for a 3D perspective without expensive equipment

This week I’m working hard on putting together a Kickstarter campaign so I haven’t had much time to work on gameplay. But I wanted to show off an exciting development this week: Head-tracking.

Remember the video below from a few years back? In it, Johnny Lee showed off his awesome head tracking demo for games using a Wiimote connected to his PC. It turns a monitor or TV into a portal into a virtual room that visually reacts to movement exactly as viewing a real 3D box through a window would. Objects can even be seen to float out in front of the screen, providing a real 3D experience without the need for an expensive 3D monitor. In fact, all you need to pull this off is a Wiimote and a cheap pair of safety glasses with infra red LEDs in them.

I’ve always wanted to implement this in a game, but as I don’t have much of a grounding in Matrix mathematics I struggled with the code and usually gave up. This week I buried myself in code for a full solid day and finally managed to do it. It involved a lot of trial and error, and manually flipping values in the projection matrix, but the final version produces 100% mathematically and visually identical results to Johnny Lee’s version. Below is a gallery of a few screenshots using identical inputs for Johnny’s version and mine. The position of the ships and targets is random, but notice that the lines match up perfectly because the perspective is identical.

I plan to have this feature in the final game, hopefully for space combat but definitely for the ship designer. Imagine plugging ship pieces together like lego to design your own ship and being able to look around it in true 3D as you’re doing it. That would be awesome. I’ll upload a video of the head tracking in action once I get more batteries for my Wiimote.

Working on a trailer

I’m working on a trailer this week, so I’ve been programattically composing scenes in my engine and will film them when they’re done. The scenes all run in realtime so I’ll also be able to keep them in the final game as an intro. I’ve had to clean up the back-end code and build some new tools for this, but I’ll be able to use the new tools for other things like space combat and cutscenes. Below is a quick sneak peek at part of one of the scenes, which uses a new planetary ring system I developed today. The ring is actually drawn to the background, so I could add a lot more detail without slowing the game down at all. I may add more types of rock and ice asteroid, and make the whole thing much bigger or the individual asteroids smaller. I just thought the ring was too cool not to share.

Tomorrow I need to go back and check that I haven’t broken anything with all this back-end work, and then continue developing the scenes. When I have more screenshots or any video to share, I’ll post it up.

The blueprint system – Fixing the micromanagement problem

Every single 4X game has the same basic flaw — as the game progresses, the micromanagement that was fun gameplay at the start becomes a bother later in the game when colony numbers scale up. Building up one colony is fun, but building up dozens that are all at different stages of development is irritating. When you’re busy sending ships all over the galaxy and playing the political endgame, there’s usually no time for colonisation or to direct conquered worlds. The only game to solve this issue was perhaps Master of Orion III, and it only did so by putting an AI in control and making the game essentially play itself. That’s not a solution, it’s a disaster.

I propose a simple, elegant solution to the colony micromanagement problem that should let people continue colonisation well into the endgame, but without taking direct control away from the user.

The blueprint system:

Each planet will have one capitol colony from which everything is managed. This is where the important buildings like factories, defensive structures and research labs will be built. The capitol colony’s buildings will be arranged on a grid, and when you’re managing the colony down at this level you’ll be able to place buildings into a build queue by putting them on the grid.  The arrangement of buildings on a grid, and the order in which to build them, can be saved as a blueprint. New colonies can then be built using this blueprint, and they’ll automatically build all the recorded buildings in the specified order. A mock-up of a colony is below:

The clever part is that the blueprints will be updatable; Add a new building to the blueprint and all colonies using that blueprint will start producing it. So if you’ve just researched a new building and want it on every production planet, you can just edit the blueprint and add it. The area marked out by blue squares in the image above (including the ones currently occupied by red and green ones) is reserved for the colony’s blueprint, so you can’t manually place buildings there.

The squares around the outside that aren’t part of a blueprint can be built on manually, allowing customisation of a colony even though it’s following a blueprint. For example, you might have a “production colony” blueprint, and if your planet is close to enemy territory you might want to use the squares around the edges for defensive buildings like turrets or shipyards. If your planet has more mines than usual (if it’s mineral rich), you could build extra factories in these squares too. Blueprints could also contain population percentages assigned to particular jobs, spending decisions, and anything else a colony might need.

Maintaining control

This system solves the micromanagement problem by turning dozens of repetitive colony management actions into one single action and then propagating that decision across your empire. But because every action done to a blueprint is manually chosen by the user, he is still in direct control of every decision. There’s no AI calling the shots, blueprints are literally just a productivity tool to make control of an expanding empire much simpler. It’s also a completely optional system, I intend to let people play the game without ever using the feature, but I don’t really see a down-side to using it.