I'm wrapping up the icons stuff for ships and design screen. When I fix the production screen so that it works with the new data system and add ship design validation, I will release 0.5.4, so expect it within a few days! 0.5.4 is mostly just reworking of ship design screen and equipment selection, so nothing too exciting, but it fixes the screens that was broken with 0.5.3 ship overhaul.
Now for the new exciting stuff! Since I've decided on the star-to-star movement, I've been thinking about finding points of conflict between turns, as well as UI for handling the attacks/defenses, and ship placement in space combat. There's also the issue with end-game having massive number of ships in space combat, and it taking forever to resolve in MoO 2 that I'd like to avoid.
I then thought, why not have the player pre-arrange their fleet in a formation, so when he attacks with that fleet, he don't have to set it all up every time with that fleet? Then I thought, what if he wants to attack a planet with a part of his fleet, and another planet with another part? So I came up with the idea of squadrons, and I realized that it solves a lot of potential design problems that I've been facing, so I'm going to implement them!
Here's how squadrons will work. Each system that you owns, when it builds a ship, it is put into that system's reserves (with reduced maintenance cost). To actually use that ship, you will hover over the fleet icon next to the system, and it will give you a list of squadrons as well as an option to create a new squadron. You click on the new squadron, and it will show an limited area (say, 20x20 tiles). You can then drag ships from reserves into positions within the area. Ships won't overlap, so if you have a huge ship, then you can only add small ships in the remaining free space. You then click "Confirm" and a new squadron is now active. You can then send it out as a part of group of squadrons, or by itself, to wherever you want.
When you attack an system, you can pick which squadrons to attack which planet. So it's possible to attack more than one planet in the same turn if you have two or more squadrons. Defenders will have the ability to pick which squadrons to defend a planet with, or even intercept the enemy ships if they're just visiting the system. However, there will be a limit to how many squadrons you can bring into a combat, so if you have 10 squadrons, and it's limited to 5 squadron per empire, you can bring only 5 into combat. This will help avoid the huge number of ships issue in MoO 2's endgame.
You can still control each ship individually in combat, but the starting ship placement will be already taken care of, using the ships' position within a squadron.
To scrap or disband a squadron, it must be next to a friendly system, which will avoid the issue with MoO 3's task force disbanding in one end of galaxy, then being available for service 5 turns later in another end of galaxy. Disbanding a squadron merely puts those ships into the adjacent system's reserves. When you retreat a ship in space combat, you're actually issuing retreat for the squadron in which the ship is a part of. When transferring population, it will bring up the squadron screen as well as the system screen, and you will need to specify which ship to carry which people. The reason for this is that during space combat, the game needs to know which ship has the people, so if that ship dies, the people dies with it.
And yes, you will be able to name your squadrons, for easy reference. You also will be able to specify how big a squadron area can be, and how many squadrons per empire can be involved in combat in the game config file.
All in all, I think this is a very good compromise for many issues that's plagued the old MoO games. It helps reduce micromanagement because you're now dealing with squadrons in galaxy screen, instead of individual ships. I will start implementing this after 0.5.4 is done, which means that 0.5.5 will finally include space combat!
A 4X space strategy game inspired from other 4X games like Master of Orion and Space Empires.
Pre-Order the Game!
Tuesday, May 22, 2012
Saturday, May 19, 2012
Design Screen update and future plans
It looks like I'm not going to get the basic gameplay working by May 31st :( That's not from lack of effort though, I just underestimated the amount of work required.
But I do have some good news. I updated the design screen to work with the new data-driven ship stuff. It now have icons displaying correct information. There's no ship validation yet (grey out the add button if too much items were added for example). So for now, I'm done with design screen and equipment selection. There's still some things to polish, but for now it's functional.
Here's what it looks like:
In my last post, I asked for feedback about travelling with grid or star-to-star. The decision is made. I'm going with star-to-star movement, and re-introduce "supply range". Yes it was in game previously, but I removed it because I felt that it don't make sense if two systems far apart can contribute to the same project. I just simply gave up with explaining why it's possible to build a death star at an outpost that's not in supply range. Let's just assume that it magically gets its supplies from the other systems :D However, each system still have capacity limits, so if that outpost is just a bunch of hamsters in a shack, then they can't build a death star :)
Here's how it's going to work. I'm going to implement two different options that players can toggle with the supply range. One option is if the destination is within supply range, you can move any fleets from anywhere to that destination, even if the route between start and end is not in supply range (aka MoO 1/2). Another option is to enforce supply range, which means the entire route have to be within supply range. So if your empire is in a crescent shape, you can't go directly from one end to another in a straight line. This can generate choke points on where arms connects to the cluster in a spiral galaxy.
I hear you say "Wouldn't that increase micromanagement? You'll have to click on a star, then wait for the fleet to get there, then set the next destination." My answer is that I will add "Navigation Graph" which will take all places where circles intersect (two points for each circle intersection), then generate a route using those nodes. The game will give you a route if it's possible, and the route will end at the desired destination, but it may not be straight.
For now, I will implement the first option, as it is simplest and requires less coding. Later on I will add the second option, then starlanes at one point (again, starlanes will be an option you can turn on or off). Sounds good?
But I do have some good news. I updated the design screen to work with the new data-driven ship stuff. It now have icons displaying correct information. There's no ship validation yet (grey out the add button if too much items were added for example). So for now, I'm done with design screen and equipment selection. There's still some things to polish, but for now it's functional.
Here's what it looks like:
In my last post, I asked for feedback about travelling with grid or star-to-star. The decision is made. I'm going with star-to-star movement, and re-introduce "supply range". Yes it was in game previously, but I removed it because I felt that it don't make sense if two systems far apart can contribute to the same project. I just simply gave up with explaining why it's possible to build a death star at an outpost that's not in supply range. Let's just assume that it magically gets its supplies from the other systems :D However, each system still have capacity limits, so if that outpost is just a bunch of hamsters in a shack, then they can't build a death star :)
Here's how it's going to work. I'm going to implement two different options that players can toggle with the supply range. One option is if the destination is within supply range, you can move any fleets from anywhere to that destination, even if the route between start and end is not in supply range (aka MoO 1/2). Another option is to enforce supply range, which means the entire route have to be within supply range. So if your empire is in a crescent shape, you can't go directly from one end to another in a straight line. This can generate choke points on where arms connects to the cluster in a spiral galaxy.
I hear you say "Wouldn't that increase micromanagement? You'll have to click on a star, then wait for the fleet to get there, then set the next destination." My answer is that I will add "Navigation Graph" which will take all places where circles intersect (two points for each circle intersection), then generate a route using those nodes. The game will give you a route if it's possible, and the route will end at the desired destination, but it may not be straight.
For now, I will implement the first option, as it is simplest and requires less coding. Later on I will add the second option, then starlanes at one point (again, starlanes will be an option you can turn on or off). Sounds good?
Wednesday, May 16, 2012
Grid-based movement vs Classic movement, and Empire Contacting
I'm almost done with the equipment selection, but there's something that's gnawing at back of my mind. Since the ships has converted to be data-driven, I'm pondering on whether or not it's worth it having a grid-based movement that the game currently have.
It's nice to be able to park anywhere in the galaxy, but is it really practical? Will you meet a fleet somewhere in space often? If it's a rare event, then grid-based movement is just something that detracts from the player's enjoyment because it's overly complex compared to a simple star to star movement from MoO series.
On the other hand, it's a bit more flexible in that I can create the background nebula and have it impact the fleet's route. It also opens up the possibility of black holes influencing the adjacent cells (random event that sucks in a fleet?). But is it really worth it?
If I was to implement a simpler star to star movement aka MoO 1/2, would it be a big difference? Would you miss out on parking your fleet in middle of nowhere? If the game is converted to be star to star, then I can run the fleet movement through your race's script so you can create an even more unique race (for example, a race will build up energy over several turns, then just zap to the other star in one turn, or one race needs to build stargates to travel, and so forth). The game would supply the fleet's current position, and its destination, and the script will then update the fleet's position between turns.
Another nice benefit of changing to star to star movement is that I can add starlanes aka MoO 3. It will be a game option, so some people can play with it on, and others with it off. It will be a simple check to see if the two stars have a starlane connected to determine if it's a valid movement route. This won't be added until the basics of game are done.
One another problem with grid-based system is the question of establishing contact with other empires. Since the game don't have fuel ranges, how should an race establish contact with another race? A special ship with "Embassy" equipment that is adjacent to one of their system? Or when one system falls under another system's radar range? Or have everyone be in contact from beginning?
With star to star, we face the same problems with lack of fuel range. In MoO 1/2 it was a simple matter of being within fuel range of other empire, and in MoO 3, it was being 2 starlanes away from another empire. How do we determine when two empires are in contact with each other? Should I add back fuel ranges?
I would like to hear your opinions on this, as I'm a bit undecided on changing to star to star, and how empires establish contact. The ships and space combat are starting to wrap up, and I'd like to have this issues resolved before I jump into them.
It's nice to be able to park anywhere in the galaxy, but is it really practical? Will you meet a fleet somewhere in space often? If it's a rare event, then grid-based movement is just something that detracts from the player's enjoyment because it's overly complex compared to a simple star to star movement from MoO series.
On the other hand, it's a bit more flexible in that I can create the background nebula and have it impact the fleet's route. It also opens up the possibility of black holes influencing the adjacent cells (random event that sucks in a fleet?). But is it really worth it?
If I was to implement a simpler star to star movement aka MoO 1/2, would it be a big difference? Would you miss out on parking your fleet in middle of nowhere? If the game is converted to be star to star, then I can run the fleet movement through your race's script so you can create an even more unique race (for example, a race will build up energy over several turns, then just zap to the other star in one turn, or one race needs to build stargates to travel, and so forth). The game would supply the fleet's current position, and its destination, and the script will then update the fleet's position between turns.
Another nice benefit of changing to star to star movement is that I can add starlanes aka MoO 3. It will be a game option, so some people can play with it on, and others with it off. It will be a simple check to see if the two stars have a starlane connected to determine if it's a valid movement route. This won't be added until the basics of game are done.
One another problem with grid-based system is the question of establishing contact with other empires. Since the game don't have fuel ranges, how should an race establish contact with another race? A special ship with "Embassy" equipment that is adjacent to one of their system? Or when one system falls under another system's radar range? Or have everyone be in contact from beginning?
With star to star, we face the same problems with lack of fuel range. In MoO 1/2 it was a simple matter of being within fuel range of other empire, and in MoO 3, it was being 2 starlanes away from another empire. How do we determine when two empires are in contact with each other? Should I add back fuel ranges?
I would like to hear your opinions on this, as I'm a bit undecided on changing to star to star, and how empires establish contact. The ships and space combat are starting to wrap up, and I'd like to have this issues resolved before I jump into them.
Monday, May 14, 2012
Equipment Selection Overhaul
Since I've changed the ship's internal mechanisms to be more data-driven, I've started overhauling the ship design screen. First up is the equipment selection where you choose an item to add to your ship design.
Everything in the old screen was hard-coded, including the icons. Since the game changed to use data-driven icons, I had to change how it displays information. It now use the new icon system, and I've started adding special kind of icons that allows users to modify its value. For example, if you want the player to decide how much bullets to store for a weapon, you add a special icon in the technologies.xml that tells the game to include that icon.
Here's the new equipment selection screen:
The top right box is list of custom icons that the player can modify. I plan on adding sliders and drop-down menus in this field. Drop-downs allow you to specify a certain value rather than a numeric value. For example, if you want to add an firing arc option to your mod, you can add a drop-down with different arcs. Right now I'm working on hooking up the controls to the actual data stored in the equipment.
Bottom right box is list of custom statistics. Again, you can specify which information to display. If you have a colony base selected, it could display a list of planets it can colonize for example.
Bottom left box is list of available modifiers for the equipment. Some examples include shield penetrating, increased range, or armor piercing. This is based on list of available technologies. What do you think of the new layout? Is it more clear than the old one? Here's the old version for comparison:
Everything in the old screen was hard-coded, including the icons. Since the game changed to use data-driven icons, I had to change how it displays information. It now use the new icon system, and I've started adding special kind of icons that allows users to modify its value. For example, if you want the player to decide how much bullets to store for a weapon, you add a special icon in the technologies.xml that tells the game to include that icon.
Here's the new equipment selection screen:
The top right box is list of custom icons that the player can modify. I plan on adding sliders and drop-down menus in this field. Drop-downs allow you to specify a certain value rather than a numeric value. For example, if you want to add an firing arc option to your mod, you can add a drop-down with different arcs. Right now I'm working on hooking up the controls to the actual data stored in the equipment.
Bottom right box is list of custom statistics. Again, you can specify which information to display. If you have a colony base selected, it could display a list of planets it can colonize for example.
Bottom left box is list of available modifiers for the equipment. Some examples include shield penetrating, increased range, or armor piercing. This is based on list of available technologies. What do you think of the new layout? Is it more clear than the old one? Here's the old version for comparison:
Saturday, May 12, 2012
0.5.3 Now Live!
I've uploaded 0.5.3 to Desura, and verified that it added the missing files to the demo installer. So the demo should now work!
In it, I've made the following changes: Equipment window now no longer closes when adding an equipment, this is to reduce tediousness as suggested by SpaceSector's author, Adam Solo. Icon framework - While it's not all implemented yet (design window is now not showing the stats correctly for example), the hard part is now finally done. I can now just add new icons and it'll take care of stuff itself. InfoTip display - Right now only weapons in space combat have this implemented, this shows a list of stats for an item you're hovering above. In the future, I want to expand this to the fleet window so it displays the ship's information when you hover over it. Some small bugs and issues that I can't remember.
While it don't really add anything new visually, it was a lot of work and was not easy to stay motivated throughout it. I hope in the future things will pick up with the tedious stuff done now.
Here's my plans for 0.5.4 (it will be 0.6 when the space combat is fully done including conflict detection, ship placement for combat, and movement in combat):
Flesh out the design window so it uses the new icon system Fix the production screen so that it works with the new cost system (cost are now data driven, not hard-coded, and you can customize different costs, for example you could have several different minerals and the ship may require those) Add InfoTips for fleet viewing Add fleet management window where you can scrap your ships Any bugs that I encounter will be fixed, so if you find any, please let me know!
In it, I've made the following changes: Equipment window now no longer closes when adding an equipment, this is to reduce tediousness as suggested by SpaceSector's author, Adam Solo. Icon framework - While it's not all implemented yet (design window is now not showing the stats correctly for example), the hard part is now finally done. I can now just add new icons and it'll take care of stuff itself. InfoTip display - Right now only weapons in space combat have this implemented, this shows a list of stats for an item you're hovering above. In the future, I want to expand this to the fleet window so it displays the ship's information when you hover over it. Some small bugs and issues that I can't remember.
While it don't really add anything new visually, it was a lot of work and was not easy to stay motivated throughout it. I hope in the future things will pick up with the tedious stuff done now.
Here's my plans for 0.5.4 (it will be 0.6 when the space combat is fully done including conflict detection, ship placement for combat, and movement in combat):
Flesh out the design window so it uses the new icon system Fix the production screen so that it works with the new cost system (cost are now data driven, not hard-coded, and you can customize different costs, for example you could have several different minerals and the ship may require those) Add InfoTips for fleet viewing Add fleet management window where you can scrap your ships Any bugs that I encounter will be fixed, so if you find any, please let me know!
Monday, May 7, 2012
Icon Progress!
I'm almost finished with the new icon system. I've also cleaned up some script logic so that it's more clean and simple. I mentioned that I added an "InfoTip" that is similar to a tooltip, but can list icons and their data. How it works is that icons are loaded from icons.xml. Then in "Laser Beam" in technologies.xml, it lists the icons that it will use for its information display. When the game loads the technology, it grabs the list of values as defined in the icons.xml from the equipment's list of values as defined in technologies.xml and its respective script, then displays it. What this means is that you can customize the amount of icons, which icons to use, how they look, etc for in-game modding purposes. I plan on replacing the planet's specials with this new system later.
One downside of this overhaul is that I've broken the galaxy travel and weapons firing. You can fire weapons, but it don't spawn particles. And it crashes if you try to move in the galaxy. As soon as I get those issues resolved, I will release 0.5.3 (both full and demo versions will be updated), yay!
Here's a screenshot of the "InfoTip", I'm hovering over "Light Plasma Cannon" and it's displaying its stats:
From top to bottom: Damage, Accuracy (should be 85%, not 0.85, I'll fix this as well), Time required, and power required.
One downside of this overhaul is that I've broken the galaxy travel and weapons firing. You can fire weapons, but it don't spawn particles. And it crashes if you try to move in the galaxy. As soon as I get those issues resolved, I will release 0.5.3 (both full and demo versions will be updated), yay!
Here's a screenshot of the "InfoTip", I'm hovering over "Light Plasma Cannon" and it's displaying its stats:
Wednesday, May 2, 2012
Apologies about the wait for 0.5.3
0.5.3 is turning out to be a bigger update than I expected it to be. The goal was to add icons where you can customize how information is displayed for your ships. Well, in order to do it correctly, I have to remove the hard-coded parts that handles space, cost, galaxy speed, etc, and have a different system handle them. So this is a major overhaul of the ship's mechanics.
However, the good news is that I've added a new "InfoTip" that when you hover above a ship, it can display that ship's list of stats in a pop-up window, similar to tooltips. So when I'm done overhauling the ship mechanics, adding information display for ships will be a snap. It also works for equipments, you can see how much time/power it requires by hovering above an equipment.
Another part of this overhaul is the future addition of "StartTurn" and "EndTurn" that are called once per turn. StartTurn allows you to handle regeneration, such as shield or power generation. EndTurn allows you to handle whatever you need at end of turn (I don't think it will be used in normal game, but some people might want it). I also plan on adding "CanUseEquipment" check in Ship script that takes in an equipment's values, and returns whether or not it can be activated.
For example, if your ship have 20 power remaining, and a equipment requires 25 to activate, it will return false, causing the button to be greyed out in-game. So you can create your own validation method for modding purposes. Such as, if a weapon fired once that turn, it cannot fire again (similar to MoO 1/2), or if there's a delay (fires every other turn) for torpedoes. Or if ammo runs out, and so forth...
I hope to have this done soon, for my sanity's sake...
Subscribe to:
Posts (Atom)