Over the past few months, we’ve been designing Predestination’s main races and working on core gameplay mechanics like ship design, tactical combat, galaxy generation, and planetary colonisation. A lot of really cool features are now in the game, but it’s difficult to show how they work without a user interface, so this month we’ve been working on building a solid UI framework into the game engine and rolling it out on the galaxy map screen.
Our goal for the Galaxy Map is to make it look and feel like an advanced astrometrics lab, with all of the information your race has about the galaxy at your fingertips. We want you to be able to do most of your turn-to-turn empire management without leaving this screen, and to be able to immediately tell what’s going on in the galaxy by keeping an eye on the map. When designing the Galaxy Map interface, we had a few rules in mind:
Every window or information pane should have a specific place in the UI, so that your screen doesn’t become a mess of open windows.
The player shouldn’t be overwhelmed with information. Information should only appear when necessary and text should be kept to a minimum.
The UI must be scaleable and easy for players to mod.
Every UI element has to have a smooth animation or transition and a corresponding audio cue. The audio is not currently in the game, but placeholder cues have been inserted into the code for every action.
Dev update video:
Feedback:
We’re still finishing up parts of the galaxy map UI, such as the quick fleet movement and mini-map, and will then begin rolling out the new UI framework into the planetary colonisation and tactical ship combat parts of the game. Head over to the official UI feedback thread to let us know what you think of the UI so far, and to let us know ideas you have for the UI or problems you’ve noticed in other 4X game UIs that you’d like us to avoid.
I haven’t posted an update in a while, but rest assured I’ve been making a lot of progress on ship combat system. Ships now have armour, regenerating shields, structure hitpoints and weapons; they can shoot at each other and destroy each other. I’ve also implemented the reactive strike system that lets ships fire when an enemy flies through their firing arcs and players can hit a button to highlight all the squares the enemy’s reactive strikes cover so you can make tactical decisions quickly. There are firing animations for beam weapons and projectile weapons, which I’ll put a video up of once I’ve built the hotbar user interface to show it off properly. Below is what I’ve been working on this week:
Nebulae and asteroids
This week I added asteroids to the ship combat system and built a new system for creating gas nebulae, dust clouds, area-effect weapons, warp effects and explosions. Any fight taking place in an asteroid field will have asteroids moving slowly through the map, disappearing when they reach the edge and new ones periodically entering. The video below shows a few example nebulae using different colours, amounts of luminous gas and amounts of dust.
Nebulae will add some tactical variation to fleet combat, some being dangerous areas to avoid and others providing a tactical benefit. If you live in a system surrounded by a nebula you could even build a specialised defense fleet to take advantage of them. A few of the things I could use this for are:
Sensor disrupting nebula – Attacks on ships inside the nebula have a chance to miss, or all ships inside are cloaked unless you come close. This could be a huge nebula covering most or all of the battlefield.
Shield dampening nebula – Shields don’t work at all inside the nebula. This could also be a huge nebula.
Ion storm – Ships inside the area take damage every round.
Slipstream – Ships gain bonus movement speed while inside the slipstream.
Wormhole – Two wormholes connecting far-away points on the battlefield.
Charged plasma – If a ship inside this nebula fires or is fired upon, the nebula discharges a bolt of lightning on a random nearby ship.
Explosive gas – If a ship inside this nebula fires or is fired upon, nebula explodes, dealing damage to everyone inside the nebula and dissipating the gas.
Most of these should have a small random chance to spawn, and if a solar system is surrounded by a nebula there will be at least one of that nebula in battles there. Certain weapons could even leave behind charged plasma fields or ion storms.
Science vessels
Recently the team and I have been discussing whether there’s a role for science vessels and non-combat ships in a combat encounter. Some of the most awesome moments from Star Trek all involved on-the-fly science using equipment that wasn’t meant for combat, and we’d like to do that in Predestination. The idea would be to let you research a suite of science modules that can be used in combat, like a scanner that probes enemy ships for weak points. Some of these might have uses outside combat, so you might build an asteroid belt mining ship to gather resources and still be able to use it in combat when the system is attacked. A few ideas we’ve had include:
Nebula scanner – Reveals the properties of the nebula. The nebula may have a hidden property that you can reveal using this, or scanning it may increase its existing positive effects and decrease its negative effects. For example, scanning a charged plasma nebula might reveal the plasma’s frequency, giving your ships immunity from the lightning discharges.
Gas harvesters – Let you suck up a nebula and deploy it elsewhere on the battlefield. This could be hilarious fun
Asteroid scanner – Reveals the composition of the asteroid. Asteroids may have hidden minerals that could be used in battle. For example, it might contain explosive material that you could detonate or add to a missile, or a rare element you can use to increase weapon damage temporarily, or something that boosts your shields.
Tractor beam – Alter the direction of an asteroid.
Slipstream/wormhole generator – Creates a slipstream/wormhole between two locations on the battlefield.
Shield harmonic probe – Missile that determines an enemy ship’s shield frequency when it hits, letting your fleet ignore its shields.
Impulse disruptor – Creates and area effect slow or decreases an enemy ship’s movement speed.
Electronic counter measures – Could decrease an enemy ship’s attack range, give it a chance to miss, or disable its reactive strike.
If you have any ideas of your own for nebulas, area-effect weapons or interesting ship modules, please post them in the comments! We’re at the point where we can start making practically anything and I’d love to see what kind of ideas people come up with.
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
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!
Thanks to the guys at Digital Circle, we had the opportunity to show off Predestination last weekend at QCon XIX, Ireland’s biggest anime and gaming convention. The game isn’t in a playable state yet, but we put together a special trailer showing some of the game’s main features and had an open signup sheet to get into the beta when it arrives.
I expected to get a few people interested, but was absolutely blown away by the level of support and enthusiasm people had for Predestination. I really can’t thank everyone at QCon enough, over a hundred people signed up for the beta in just two and a half days after seeing the trailer below:
If you didn’t see the trailer and signup sheet, or if you didn’t want to write your email address down on paper, you haven’t lost your chance to get into the beta. We’ve launched a secure online signup page and will be extending signups to the general public for the next few weeks. We’d really appreciate it if you could pass the signup link to any of your friends who might be interested in the game or post it on your Facebook page.
If you want your say in how the game is developed, don’t forget to follow this blog and comment on any game design posts we put up. We rely on your honest feedback to make sure we’re on the right track, and will be posting details of features as we implement and iterate on them. With your support, we can make Predestination the best sci-fi 4X game out there.
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.
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?
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:
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.
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.
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.
