Clickfest and how to avoid it

In my previous post, there were comments about how it looks tedious in the space combat where you have to click on a weapon, then click on a ship to fire at it.  This has led me to brainstorm ideas for reducing the clickfest.  The goal of Beyond Beyaan is to provide an enjoyable experience with minimal tediousness and bad kinds of micromanagement (repetitious orders, etc), and I'm not accomplishing that with space combat.

Another thing is why does firing 2 weapons take more time than one?  Why can't you fire both your plasma and laser cannons at the same time, reducing the time used?  Right now an equipment (for example, 14 x laser cannons) will take the same time to fire, but what if you want to fire two weapons that have similar time requirements at once?

And why can't you move and fire at the same time?  I was basing the system off of X-Com, where a human can't really move and fire at the same time unless you sacrifice accuracy, but now I'm thinking that it might not be the best system for space combats with ships and computer-assisted targeting.

So I'm proposing some ideas, and would like to hear your feedback:

For the ship design, you can add weapons and stuff as usual, but you now can add "groups" of selected equipment, with max of 10 groups per ship.  Each group can share the same weapons as other groups.  You will have a group selected at all times, right clicking will activate that group and give it your mouse pointer's coordinates.  You can change the group by either hotkey (0 - 9 on your numpad/numberic keys), or clicking on the list of groups.  You can name each group for each ship design (Long Range, Short Range, Missiles, Falcon Punch, Death Blossom, etc) for easier quick glance when choosing a group.

For example, let's say that your ship have three weapons:
10 x Laser Cannon
5 x Laser Cannon
3 x Plasma Cannon

You have 3 groups that consists of each weapon (first group is just 10 x Laser cannon, and so on), 4th group is both 10x and 5x laser cannon, 5th is all three combined.

A group will take the longest time of any equipment included (if Plasma takes 10, and laser takes 5, it will use plasma's time), and take the sum of all equipment's power required (if Plasma uses 5, Laser uses 2, and all weapons are included, then it'd be 5 x 3 + 2 x 5 + 2 x 10 = 45)

A weapon must be included in a group in order to be used.  There will be a warning when confirming a design if there's any items that's not included in a group.  There will be a flag in the technology table whether or not an item should be included in a group.  For example, Sub Space Teleporter won't be included in a group.  In space combat, the left part of information display will be for this kind of items, and right part will be list of groups.

I think this should reduce the clicking required, and allows you to combine weapons into an impressive firework display (all weapons in a group will fire at the same time, unlike MoO 1/2 where it fires each weapon in succession)

------------------------------------------------

Now for movement/firing.  I'm thinking of splitting those two, so that moving will use a separate point system from the weapons.  There will be "movement points", the faster your engines are, the more you can move.  You already sacrifice a lot of space to engines, so if you slap two system engines on your ship, you don't have much room for weapons, so why should you be punished twice by having to choose between moving and firing?

With this change, each ship will now have three separate point systems: Movement points (this doesn't consume power or time because engines generate its own power, and movement points is technically time), power points, and time units (the last two is for any equipment unrelated to moving).  The time units are there to prevent overpowered ships that have massive reactors to just fire all of its weapons repeatedly due to its massive energy reserves.

I think this should make the combat a lot more simpler for the players, and making it less of a click-fest.  I would like your feedback on those two changes!

Minimum Spanning Tree

Since having every star have starlanes to all of its neighboring stars be hard to defend, and no surprises while exploring, I implemented randomized starlanes.  How it works is that it creates all the adjacent starlanes as usual (my previous post showed a screenshot of visible starlanes connecting to my two systems, note that there's no star without a starlane connecting).  Then when all the legal starlanes are created, it then goes through the nodes and activating the next starlane with the shortest length.  After this is done, every star is connected with the shortest starlane, or in other words, a minimum spanned tree.

Since this often results in one route to most of the stars, I added in a percentage of unactivated starlanes at random, which adds some alternate routes.  I can modify the percentage value (10% will barely add anything, while 30% will add a lot) to alter the number of starlanes, this will be an option in galaxy setup.

I'm quite pleased with the result, this reminds me a lot of MoO 3's starlanes!  Here's a screenshot showing all the activated starlanes, notice that not all stars are connected to all of its neighboring stars, resulting in possible strategic strongholds:

Next up is replacing the line drawing with a thicker line using a different rendering system.  The current line is too thin, and is slow.  There's some other improvements that needs to be done, then I can finally focus on fleet/squadron movement and combat resolution.

Starlanes

I was thinking of how to implement star-to-star travel, using supply range, when I realized something.  This will be basically a node graph with all nodes connected to all nodes for a star-to-star system.  Not much difference from Master of Orion 3's starlane system in functionality.  So I thought, why not do the hard part first, by setting up starlane system in the game, then I can convert it to use star-to-star travel?

The only difference between starlanes and star-to-star is that with starlanes, some of the connections are the "express" meaning faster to travel, and is visible, while other connections are "off-road" or slow, and invisible lines.  With star-to-star, all lanes have equal travel cost (multiplied by distance), and are invisible.

Another additional benefit of this system is that I can add a flag to each object in the galaxy "BlockPath", which if set to true, will remove any starlanes that intersect with this object.  So for example, you can't travel through a black hole like in MoO 2.

Stargates will be a special value stored in the starlane class.  Each starlane class can hold a list of empire's modifications.  So if you have two systems with stargates, you can use them to travel in one turn, while other empires can't use your stargate.  Or you could even slow down your enemies by increasing the travel cost of starlanes connecting to the affected system.

While the ships still use the grid-based system, I've started work on starlanes and visible drawing of them (will be improved in the future).  Here's a preview:

The goal is to support both starlanes and star-to-star, you select which one you want through game configuration.

0.5.4 Status and squadrons

I tried to upload 0.5.4 which contains the following changes:


Added five new planet backgrounds for ground combat: Desert, Ocean, Barren, Dead, and Jungle
Added icons for displaying information in ship design and equipment selection
Added special icons that players can interact with in-game (numeric up/down to specify an amount right now, in future sliders and drop-downs will be added)
Fixed projects screen so that it works with the new ship system

However, the missing files issue struck again!  It affected both full and demo versions on Desura, so I've sent an email to them asking them to resolve this once and for all!  I'm getting a bit tired of modifying every missing file so that it'll show up because it was different from the previous version...

I've uploaded new zip files, which will go live tomorrow morning.  If you download the standalone, you'll be able to try the new version.

Now on topic of star-to-star and squadrons:  I've started cleaning up the nebula/grid-based movement, and realized that there will be quite a bit of work involved.  But to start this off, I've removed the nebula, removed the varying sizes of stars, and a bunch of under-the-hood cleaning.  When I ran the game, I saw that the galaxy looks a lot better with small stars and no nebula background (there will be nebula, but they're objects in the galaxy, not the background)

Here's a screenshot of it (note that it's fully zoomed in, all stars are now their actual sizes from the graphic file):

Squadrons and 0.5.4 Details

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!

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?

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.

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:

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!

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.

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...