Pre-Order the Game!

Desura Digital Distribution

Tuesday, February 28, 2012

Line and Circle working!

I sat down and looked at the screenshot from previous post, and saw something suspicious. I then took a look, and my suspicions was confirmed.

I changed from this:

X, X

to this:

X, Y

And lo and behold! The line vs circle collision works perfectly with that one change! A bug from copy/paste...

Now I can finally show what I'm talking about! Here's a bunch of screenshots:

A ship's shield is powerful enough to withstand a beam:


A ship's shield is barely strong enough to stop the laser on its second penetration:


A ship's shield is unable to stop the beam at all:


Multiple ships lined up are able to stop the beam after several shield penetrations:


A ship with two different shields (one short and one long range):


Whew! There's still two more things I need to add: cooldown between each particle (if you have 10 laser cannon, have it fire 10 times with about .1 second delay, instead of firing it all at once), and ability to set spawn conditions from inside the script (position and angle). For now, I'm done with this, next up is the tutorial system!

Monday, February 27, 2012

A hit! Or is it?

While I grappled with the idea of rectangle vs circle collision (which was kinda demotivating...), I decided to scrap the rectangle, and only have line vs circle. The reason is that with rectangles, it's possible to hit one circle more than two times, and there's no easy way of making it only two hits (entry and exit points). A line is guaranteed to have at most two points of intersection with a circle, which simplifies my life a lot. The downside to this is that if you have a huge laser cannon of doom that fills up half of the screen, it'll only collide with ships that are in middle of the beam. You can go around this by spawning a lot of lines close together, the neat side effect will be the visual effect of some ships blocking part of the beam.

With this decision made, I then added line vs circle collision, have it detect all points of impact, then sorted the list of collisions. I then added script support for "OnHit" on the equipment being hit, and "PostHit" on the particle doing the hitting. It's not done yet, the line vs circle collision isn't working quite right, and I need a way for the particle to tell the game "The shield was too strong for me, I'm done here", so it don't continue processing the rest of impacts.

OnHit is done by calling the equipment that's being hit, and have it modify the values (for example, shield would reduce the damage) of the particle, and spawn any visual effects (shield ripple effect for example)

After the OnHit call is made, it then calls the particle's "PostHit" with the new values, and see if it's done or should spawn any other particles (such as a fragmentation shell that bursts into shrapnel). If it's not done, then the loop continues with the next round of "OnHit" and "PostHit" with the next equipment in list. It continues until the particle is done, or there's no more collisions.

Now for the screenshots of this in action! First one is the laser beam particle missing as a reference:



The next screenshot is of it "hitting" (line vs circle algorithm isn't correct, will need to fix that), it shows that it spawns two shield particles (was supposed to be "entry" and "exit" points, with exit eliminating the remaining damage from the beam) and the beam was cut off:



I can almost taste the victory! This scripting system is almost done! Just need to polish up a few things, fix the line/circle collision algorithm, fix the sorting algorithm, then add a simple projectile weapon to test a projectile-type weapon, then this part is done! There's still a lot more to be done, but for the purposes of "playable", it'll be done until I come back to add missiles and other goodies.

After that, it's tutorial, then I'll release a new version for the pre-orderers!

Thursday, February 23, 2012

Plans for release and afterwards, and other tidbits

I hope that you guys don't mind me posting posts without screenshots! I like to share both progress on the game, and my ideas/plans for the game. So if you guys just want the pictures/videos, then I'll reduce this kind of posting. The reason why I post this kind of posts is that I don't like long periods of silence from developers on games that I'm following, and I don't want to be like them :)

Now for the release. I'm about to reveal the reason why I've chosen May 31st. According to my doctor, I'm dying. He estimated, using the average lifespan of male Caucasians, I have about 60 years left to life. :(

Actually, the real reason is because of my wife's pregnancy with our second child which is due in end of Summer or beginning of Fall. I'd like to have the game released, and all the associated work related to publishing the game done by then, so I can focus more on my family. I will continue adding features and bug fixing, but I wouldn't be stressed or worried about releasing the game.

Since I've set the release date, I've been evaluating my progress, deciding on what goes in, and what can wait. I want to detail this out so that there's no surprises or disappointments at release. My goal is to get the game PLAYABLE, where people can actually win a game, with basic functionality of 4X games.

I realized that I'll have to keep the technologies basic for now, so this will mean that there's no radar in galaxy map (you'll see all ships from beginning), same in combat (all ships are visible). All empires will be in contact from the beginning. There won't be any fog of war. However, you'll still need to explore star systems, which is the "eXplore" part of 4X.

There are three major features I need to add to space combat: Collision detection (using rectangle/circle collision and circle/circle collision), Ship Damage/Death, and Ship Movement (using Navigation Graph due to it being free-form). Now, the collision detection itself isn't too bad, but the problem is, I need to retrieve the exact points of impact for script processing, which is a bit tricky, instead of just a true/false if something impacts something. Also, I have no experience with Navigation Graph, but I hope that it won't be too hard to implement. Ship Damage/Death will be handled by scripts, so I'm not too worried about that. I've decided that to keep things simple, you attack one planet per turn, and combat will occur with that one planet, instead of the whole star system, similar to MoO 2. So there will be a prompt asking you which planet to attack/bombard.

In order to keep things simple, there will be only beam and projectile weapons. No missiles, torpedoes, bombs, or shockwaves yet :(

Once those three features are done, I will put space combat on hold, and add conflict checking (two empires in same spot results in space combat), then I'm done with space combat until after release. This will be the "eXterminate" part of the 4X, as well as the ground combat.

Colonization/population transfer are done, which is "eXpand" part of the 4X game. Pollution/terraforming are part of the game already.

Now for the "eXploit" part of 4X, you can build ships and terraform planets. Most of the research system are done, but there's no prompts for selecting a new item to research. I will need to add that, and make sure that the basic research works, then I'll leave it until after release. There's no way of scrapping existing ships, I will also need to add that, as well as fleet management screen where you have an overview of all visible fleets (which at this moment includes all ships in the game). Then this will be good enough for the "eXploit" part.

When the above are done, I will add checks for victory/loss, and add the Winner/Loser screen, then focus on polishing the existing features and adding any necessary features that I may have missed.

However, there won't be AI or Diplomacy (which need to be overhauled) until after all the above are done. If I have extra time before the release date, then I will focus on diplomacy.

I'm also adding tutorials to help people learn how to play the game.

This is the list of features that will be in the game, and in the order that I will add them, and estimated time to complete each feature (feel free to copy this and check off each item when I finish them as a count-down to release):

Collision Detection/Handling in Space Combat (Hopefully one to two weeks)
Tutorial System (A day or two)
Ship Damage/Death (Should be one week at most)
Ship Movement/Navigation Graph (Unknown, no experience with navigation. Hopefully just a week, but may take up to a month or so)
Conflict Search in Galaxy (A day or two)
Prompt for which planet to attack/bombard (A day or two)
Research Prompt for new item to research after completing current item (A week)
Ship Scrapping (A day or two)
Fleet Management Screen (A week at most)
Victory/Defeat checking and display (A week at most)
Saving/Loading of games (Hopefully two weeks at most)
----------------------------------------------------------------
At this point, the game is fully playable, and ready for release. The worst case would be 12 weeks if you add up all the weeks/days/months, and it's 14 weeks to May 31st, giving me about 2 weeks of leeway for polishing and fixing bugs. However, if the above features are not done by then, then I will have to push the release date, which I hope won't happen.

The following features will be added hopefully before release if all goes well with the previous features. If not, they will be the first items I will work on next, in order:
----------------------------------------------------------------
Diplomacy (A month, most likely)
AI scripts/processing (Unknown, depending on complexity of adding AI functions to various aspects of game such as combat, diplomacy, planet management, etc)
All the missing extra features of space combat (missiles, torpedoes, etc) (A month hopefully)

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

At this point, I will then focus on adding extra features, such as stacked ships, radar, ECM/ECCM, tactical star system movement (think of Space Empires IV movement/view inside each star system), space-based races (yes, this won't make into the release, it requires the tactical star system movement feature), different movement systems (starlanes, free movement, star to star only, and maybe others), and so forth. Those extra features will be added to no cost for those who've bought the game. The only "paid" DLC will be cosmetic items such as new races, technologies, data sets, and scripts. Those can be created by modders, and does not affect how the game work, so they're not necessary to obtain all the features of the game.

If you see a feature not listed in the list of items before release, that means it's not going in before release. Again, the goal is to make the game playable, then go from there. This way, I'll avoid the feature creep problem until after the release.

I hope this explains everything about the release plan! If you have any questions, feel free to ask!

Sunday, February 19, 2012

Combat Progress!

I've managed to fix the display issues, and fleshed out some more of the scripting system. Spawning and updating of particles are mostly done. Drawing of particles are done, however there's no shaders yet. I will add shader support later on.

I'm a bit unsure how scripting system will work in multiplayer, due to randomization. I don't want the players to go out of sync (a player sees his enemy's ship dead, but the other player see it still alive for example). So I will have to figure that out later when I get to multiplayer. Note that network multiplayer is planned for after the game is released, so I'm not worrying about it too much now, but just something to think about for now.

While working on the script system, I realized that it's hard to manage two different coordinate systems in scripts. One is grid based which is for the ships and their positions, and another is free-form which is for particles. After some thinking, I decided to convert the ship to use free-form system. This means that ships are not locked to a grid cell, they're free to move anywhere. This simplifies a lot of things in the script system, but will be somewhat different in terms of gameplay. No longer do you move ships on a checker board. I think this will make things more interesting, as it opens up possibilities for me.

I can now add in a good kamikaze system without worrying about how to handle it in a grid-based system. I can just simply do mass vs mass collision and calculate the ramming ship's thrust, and have the ships bounce off of each other and apply damage to both ships (or more if ramming a big ship into a bunch of smaller ships). I can add free moving asteroids that you need to avoid or they'll ram into your ships. There's a lot of other potential (blowing up a planet would generate a lot of debris that you need to avoid for example) with this system, I'm excited about this.

With the spawning, drawing, and updating done as much as possible, the next thing on list is collision detection/handling. I've made the laser go pew pew, now it's time to make the ship go boom boom.

Now for screenshots! Since light don't have a limited range, I've made the laser to have an extremely long range. This will be similar to X-Com, you can either miss or hit, and you can see it visually hitting or missing, instead of some behind-the-scene number crunching. You can see the laser "missing" (quotes because collisions aren't done yet) here (first is zoomed in image, second is zoomed out to show the laser's range, which extends even more than that)



Thursday, February 16, 2012

So close!

I've set up spawning of particles, updating of particles (mostly), and part of drawing of particles. Not everything's working correctly yet :( It've been a marathon the past couple of weeks for me getting the whole scripting system set up, so I think I'm going to take a break this weekend. Here's what I have so far:



First bug is the placement issue (the beam should be on right of the leftmost ship, not on left)
Second bug is that the sprite isn't repeating the image, it's stretched instead.

There's no spacing between particle spawning (if you have 10 cannons, it will spawn all 10 at once), nor collision detection, or damaging. No ship effects yet as well. But visible progress!

A lot of code just to make a laser go pew pew... :)

Monday, February 13, 2012

Combat plans - no pictures sorry!

This will be the last "technical" post, I promise that the next one will contain screenshots and video of the combat screen!

I've started on the scripting system for space combat. So far, I've implemented part of technology and particle scripts. I'm also working on the UI for space combat screen.

The plan for UI is to have two different lists for your ship, the "Passive" systems and the "Weapon" systems. Passive systems are the list of equipment that are either passive (such as shields), or are part of the ship without doing anything directly (such as armor and engines). Some of them you can turn off/on such as shields and cloaking. "Weapon" systems are the list of equipment that you can fire or activate manually. They are the weapons and some special equipment that you have on your ship.

Another part of the UI is to show the amount of time units remaining, and how many power you have left in your capacity. Each turn will have 100 TU (time units) automatically, those are not carried over. Each turn will also have your reactor add power to your power capacity, left-over power from last turn will be carried over.

Let's use an example of how this system works. You have a ship with a shield that drains 20 MW (Megawatts) of power per turn, and a cloaking system that drains 50 MW per turn. It have a laser cannon that uses 10 MW, a photon torpedo that uses 100 MW, and a plasma cannon that uses 30 MW. It have a reactor that generates 100 MW per turn, and have power capacity of 1 GW (Gigawatts).

If you have both shield and cloaking active, each turn it will add 30 MW to the capacity (100 - (20 + 50) = 30). If you want to fire the laser cannon, you can do so three times, or you can fire the plasma cannon one time, or wait four turns before firing the photon torpedo, with 20 MW left over. However, if you want to fire the torpedo as soon as possible, you can turn off shield and cloaking, which will enable you to fire the torpedo next turn, but leaves your ship exposed to direct fire and scanning.

When you want to move your ship, you hover over a position, and it will tell you how much power and time it will require to move your ship there, then you click on it. To use an weapon or special equipment, you click on the desired weapon, and click on your target, similar to X-COM, minus the firing options. If you want to teleport using an teleportation equipment, you click on the equipment first before clicking. It's possible to teleport more than once in the same turn, provided you have enough power and time to do so.

I also have plans that will make the combat more tactical than just having the best weapons. One is the detection range. Ships that are out of detection range will be not visible to you on your turn. You can try and fire in their general direction in hopes you'll hit something, or move closer and try to detect them. This will make ECM and ECCMs equipment valuable. ECM (Electronic Counter Measures) will increase the detection range required to detect the ships. ECCM (Electronic Counter Counter Measures) will decrease the detection range. Let's say you have a ship with an ECM that adds 5 to range. The enemy ship will have to move 5 units closer to detect your ship than if your ship didn't have one. However, if they have an ECCM that reduces the range by 6, they will have the same detection range (ECCM don't magically reduce the range below its actual range, you'll need other special equipment for that)

Ships that are not in line of view (hiding behind asteroids, planets, or big ships) will also not be visible normally.

This will make ships designed for scouting and detection very valuable in combat. If an enemy ship have cloaking equipment, you will need a scout with a special cloak-detector to be able to detect that ship. Otherwise, it'd be a similar situation with an iron-clad vs a wooden ship. Cloaking don't magically disappear when you fire weapons, since it'll be a constant effect.

This system will greatly reduce the advantage of being the first player in the space combat, and offers some very interesting tactical decisions.

Now, on the last item for today, data handling in the scripts. So far, I've explained how the combat will work tactically, and part of the scripting. I've left out one important detail. How do you handle special attributes in weapons and equipment? For example, shield-piercing modifier on your laser cannon?

Here's how it will work. The game don't care about special values, it only cares about a few things: The size of the target reticle, the power and time consumption in using an equipment, whether or not an equipment is passive, whether or not ships are visible to certain ships, and how much damage is dealt to a ship on hit from an equipment. However, it will store the special values for equipment's script logic.

Let's say that you have a laser cannon with a 50% shield piercing modifier. In the script, when you fire that weapon, it will create a list of values that may look like this:
Damage=20
Shield=50

When the laser beam hits a shield, the shield's "OnHit" is processed with above values passed in. This shield normally reduces damage by 6. In the OnHit function, it looks for "Shield" value, and if it finds one, divides it by 100. The result is 0.5 with the above values. It then subtracts (6*0.5=3) from "Damage", leaving it with the following values:
Damage=17
Shield=50

Then when it hits the ship, all of the range 0 equipment's OnHit will be processed, modifying the above values. Let's say the ship's armor have damage absorption value of 5. Since there's no "Armor" value to process, it modifies the "Damage" by reducing it by 5, and ignores "Shield" value completely, resulting in Damage=12.

After all the equipment are processed, the game then grabs the "Damage" value, which is 12 at this point, and applies it to the ship's components. All other values are ignored.

It's possible with this system to create a ship that have a huge shield (range 10 for example) that is solely for protecting other ships by reducing any damage that passes through this shield. Note that all values other than "Damage" are custom and defined by your technology script. So you could create an item called "Wacky Cannon" with 50% chance of just making the ship disappear. On fire, you add a value of "Wackiness=50", and on hit, the particle's OnHit processes this value (which could be modified by other equipment), and if it does make the ship disappear, modifies the damage to be 0 to avoid showing damage number, spawns the "Wacky Disappear" effect on the ship which makes it fade out, then removes the ship from combat.

When I finish the scripting system, I will show the above examples (huge shield, shield piercing, wacky cannon) plus some others. So if there's a lengthy period between this post and the next post, it's because I'm working on making it all work. I think this and last posts pretty much cover the whole scripting system and how combat will work, so I won't bore you further with picture-less posts before I finish combat :)

Tuesday, February 7, 2012

Technology Scripts

Warning, this post will be highly technical and is not for the faint of heart!

My goal is to make the technology very flexible in the game. In order to do this, I need to create a consistent scripting system that all technologies can share. So a shield technology will share the same system as a beam weapon for example.

I realized that I can't have one script that handles both input from user and particle/ship effects. If I were to fire a laser cannon 10 times, and the delay between them is not enough for one to fade out before firing another, how should the script handle that? So I will split the scripting system into three parts:

The technology script
The particle script
The effect script

I will explain what each of those does, starting with the technology script. This is the backbone of the whole system, it handles input from the user, as well as collision checking/detection. It also determines the target crosshair size - For example, if it's an engine or teleporter, it would return the ship's size resulting in the current ship's size for target movement. If it's an weapon, it would return 1, as a normal crosshair. If it's an effect such as auto-repair, it would return 0, no crosshair.

Why the collision checking/detection? Let's say that you have an shield technology with a range of 1 (about 1 grid cell around your ship). Anything that overlaps this (including ships and weapons) will trigger collision handling. So if a shield technology is triggered, it would call "DoCollision" and reduce the item's damage by a specified value. However, it's not limited for shields. One example is that you have an anti-missile equipment, and it have a range of 4. Missiles entering this range would trigger the anti-missile's "DoCollision" which in turn fires a weapon at the missile. Or if you have a repulsing weapon, it will automatically trigger and spawns a repulsing beam at the target ship, pushing it away.

Most items won't have collision, so they'll have range of -1, meaning no collision at all. Armor will have collision of 0, meaning that it's triggered first before hitting the components in the ship. But what if you want to add an technology that absorbs some of the damage and converts it into energy for the reactor or a weapon? Then you'd put range of 0, moving it up into the "armor" position therby triggering the "DoCollision". Any remaining damage will be distributed among the internal components, including armor and shield. So if no damage reaches -1 range, no components are damaged. The order of DoCollision processing are done using the order of components in the ship. So if you put an item that converts part of the damage into energy above the armor, that item will be processed first, otherwise the armor will be processed first before that item. It don't affect how much damage actually hits the ship, because all of the range 0 components will be processed before reaching the -1 range

Now, the particle script. This will handle the "visual effects" and data of weapons, shields, and any other non-ship graphics. It is called from the technology script, and expires after a certain time period. For example, if I have an laser cannon, and I fires it at a ship, the game would call the Laser technology script's "DoAction()" and it would spawn a "Laser Particle" with values passed in. The game will draw and update all particles simultaneously. So if a laser beam hits a ship's shield, that shield script would spawn a "shield particle" that's basically just eye candy to indicate that it hit the shield, and both shield and laser would be drawn at the same time.

Each particle will be a separate instance, so if you fire 5 bullets at a ship, each bullet are handled individually. A particle script also handles the updating, so if a particle moves in an oscillating fashion (wave weapon for example), it would update the position of the particle. So you could create a weapon that fires a "blinking" bullet that phases out and teleports to the other side of the map using the script's update functionality. It also handles collision, so if it impacts something, it will call 'OnHit' function. If it's a fragmentation weapon, it would spawn 10 "shrapnel" particles in random directions.

Now finally, the last script: Effect scripts. This is different from particles in that it's for ships. It handles the visual effects for ships, as well as other data related to the ship. Let's use a couple of examples to illustrate:

If you have a teleporter item, activating it when clicking on a position will spawn "StartTeleport" effect that adds the visual effect of the ship fading out or disappearing. When the StartTeleport expires, it spawns "EndTeleport" which handles the "fading in" or re-appearing of the ship, as well as moving the ship to that position.

Another example would be cloaking. It would use a particular shader to make it partially invisible to the owner, and completely invisible for others. It does not change the ship's position or anything.

Last example, if you have a statis weapon, and you hit a ship with it, it would spawn a "Statis" effect on that ship, rendering it frozen and unable to perform any actions.

So in sum:
Technology Script - Handles input from users/AI, handles collisions, can spawn particles or effects
Particle Script - Manages one particle (beam, shield, etc), and handles that particle's position, collision and visual effect - can spawn other particles or effects.
Effect Script - Manages one effect (frozen, cloaking, etc), can spawn other effects.

I think this will be a very robust system allowing people to create very creative technologies. The only limitations would be the memory and speed of the computer handling the game :) If limitations are encountered in the future, I will look into expanding the functionality. The goal is to not write a specific functionality for just one item in the game itself, but to have that supported through the script system.

In a unrelated topic, I've submitted my game to Desura for review last night, and am now awaiting their response. I will let you know as soon as I find out the result!

Sunday, February 5, 2012

Polishing

I've gotten feedback from one tester about various things. The feedback was very helpful in seeing what need to be fixed in terms of user friendliness. He was lost as what some of the buttons did, so I implemented tool-tips that pops up when you hover over a button.

I also tweaked how it shows the selected path and current path. Selected path is now just a crosshair to the desired destination, while current path shows a line where the fleet will go.

Since capturing a screenshot didn't show the mouse cursor, it is on the top-left of the tooltip. Here's the screenshot:



I've fixed some other annoying bugs (invisible stars and crosshair not showing up). I think the game should be a bit more stable now.

I'm going to add some more tooltips to the buttons, then send this version off to Desura for review. Let's hope they accept this game! *crosses fingers*