Development Updates

[Christian Knudsen]

Below is a list of the stuff I want to implement for the 0.7.x versions of the game. This list will be updated and changed as development progresses.


Fleets:

- Each faction has persistent fleets (a group of ships), except merchants and bounty hunters.

- Factions can take control of systems by having a fleet in that system (and no other faction has a fleet there).

- Randomly generated ships in a system is partly based on the faction controlling it.

- Abstraction algorithms to determine outcomes of fleet battles (when the player isn't present at the battle).

- Information about faction control of systems in the player's Quine, as well as news updates when fleets clash and systems change hands.

- If pirates, retros or Kilrathi control a system, production on all planets and bases in that system will drop considerably.

- Procedures for a fleet returning to a base and getting destroyed ships replaced (and damaged ships repaired) after it has won a battle.

- AI for controlling fleets and making strategic choices.

- Fleets in your system should show up in the nav computer and you should be able to select them as a destination for the autopilot.


Stuff before persistent ships:

- Fix AI issue when a ship's path is blocked by another ship and they're flying in approximately the same direction.

- Fix AI issue with an enemy ship that has a damaged maneuvering jets and therefore just circles the player at high speed instead of slowing down in order to point at the player.

- Shots fired from rear turrets should have their range decrease the faster the ship is moving. Likewise, shots fired from front guns should have their range increase the faster the ship is moving. This is so that when ships are chasing another ship with a rear turret, the chased ship's rear gun won't have a longer relative range due to the movement of the ships.

- If an enemy ship has "run off" once, the chance of it doing it again should be very small (to stop the AI from sometimes annoyingly continue to run off until its shields have recharged, then return for a single attack or two).

- Commodity event balancing: When simulating commodity sales, take commodity events in same and adjacent systems into account (i.e. decrease amounts of commodities in systems at and adjacent to a commodity event).

- If a Confed/Milita ship is under attack, it shouldn't start scanning the player for contraband.

- Not completely full Ultimate and Brilliance canisters should be able to be combined like ammunition.

- Add a check when you start a conversation with a fixer so that he'll tell you if his mission has expired (instead of the player being able to accept already expired fixer missions).

- For transport/deliver cargo missions to ships, you shouldn't transport more cargo than the target ship can carry.

- Shouldn't be able to transfer captives to the casino ship.

- Five new systems.

- One of the new systems will be the sector's capital planet, where the player will be able to pay off fines.


Persistent ships:

- Storing information about persistent ships across systems and scenes (quest ships, wingman, bounty hunter nemesis).

- Controlling persistent ships in other systems and moving them throughout systems.

- Bounty hunter nemesis sent to kill the player if fines are high and haven't been paid in time.


Remaining stuff:

- Be able to purchase a temporary ID hack that will change your ship's faction (if you for example need to move through a pirate controlled system).

- NPCs should be able to throw grenades.

- NPCs should move away from grenades thrown at them.

- Different AI tactics for character combat instead of all hostiles always just rushing towards you.

- Be able to ask friendly ships to not attack your target (if you for example need it alive for a bounty mission).

- If you're being scanned and attempt to land or jump, a message box will tell you that you'll be fined and ask for confirmation.

- 'L'ook should list things on the ground as well as names (ship types) of landed ships.

- For "intercept cargo" fixer missions, you should be able to board the target and transfer the cargo as well.

- New character combat weapons. Some with poison effects.

- Medkits!
 

[Christian Knudsen]

Retros and militia will most likely switch faction colors in v0.7.

I've played around with displaying the faction control of systems on the quadrant map. This has required me to change up the colors of the map a bit. A confed controlled system is dark blue, pirate controlled red, Kilrathi controlled yellow, and retro controlled purple (and player controlled will be green, but that won't be added until v0.9). The white color for retros didn't work very well as it was hard to distinguish from the gray of systems not controlled by any faction. The player's current system and route is now in light blue, as the yellow color belongs to the Kilrathi.



If a system is disputed, its marker will blink in the colors of the warring factions.

(Cheops controlled by retros and Halfway controlled by Kilrathi in the picture are just examples. They won't initially be controlled by those factions in v0.7.)
 

[Christian Knudsen]

I've completed the basic framework for fleets: placing them when entering a system and storing information about them when exiting. I had a weird bug with fleet ships not firing their turrets, and it took a long time before I figured out that it was because their experience and morale wasn't set.

I'll be doing the placement of the initial fleets next. These are the fleets that are hardcoded into the game and will be the same whenever you start a new game. What happens to them and what new fleets get built to replace destroyed fleets will be somewhat random. There probably won't be all that many fleet confrontations in v0.7, as fleets will pretty much stick to their initial systems, probably just moving to an adjacent uncontrolled system or if an initially controlled system gets taken over by another faction. It won't be until halfway through the main storyline (when the player gets the chance to buy his own base and start building up a fleet) that the factions and fleets will start working to take over the entire sector.

Another thing that's popped up that I'll likely do for v0.7 is improving the ship AI. I don't want the player being able to destroy a fleet on his own, so the AI needs to get better. One thing that I'll probably add is AIs not always firing directly at the target ship, but taking the target ship's velocity and direction into account. It should be a fairly simple calculation.

But I'm still working on fleets for now...
 

[Christian Knudsen]

Here's a movie of an encounter with a Confed fleet moving from one nav point to another in the New Beijing system:

fleet.zip (0.4 MB)

I've made it so that fleets will ignore single hostile ships unless they attack them or are part of another fleet. Fleets will only attack other fleets (unless provoked). This means that you'll still be able to land at pirate bases, for example, as any pirate fleets won't attack you unless you attack them. The randomly generated pirate ships will still attack you, so it'll probably be pretty much as hard/easy as it is now.

When that fleet in the movie turns hostile on me, it also becomes pretty clear that the AI really needs improving. And friendly missiles shouldn't hit you (I think 5-6 AI ships are taken out by friendly missiles without me doing a thing!). Maybe friendly gunshots shouldn't hit either. That'd definitely make it easier for a group of ships to engage a single target, as they wouldn't have to worry about friendly fire.
 

[Christian Knudsen]

Today I completed most work on assigning orders to fleets and having the fleets carry them out. I had a Confed fleet in Loye system that I gave the order (in the code -- you won't be able to order around Confed fleets in the game, of course) to go attack a Pirate fleet in TC-101. I followed the Confed fleet as it navigated to the jump point to Vortex Prime, jumped through (one ship at a time, but as soon as the first ship has jumped through, you can jump to the next system and the entire fleet will already be through), then navigated to the jump point to TC-101 and jumped through, and on the other side navigated to the Pirate fleet, engaged it when close enough and wiped it out.

This should have resulted in TC-101 becoming Confed controlled, but I haven't added that yet. It should be pretty easy, though. I'll just run a check whenever a fleet ship is destroyed; if it's the last ship in its fleet, I'll check if there's another fleet in the system and change the system control if necessary... and then have a news item in the player's Quine informing him that the system has changed control (I'll probably also have a news item about the Confed fleet entering the Pirate controlled system, so you'll know that something is going to happen and can decide to go have a watch/help out if you want).
 

[Christian Knudsen]

I've got the news entries for fleet events pretty much working now:



There's a minor issue with a fleet engagement news entry being posted twice -- once for each faction in the battle -- but that should be easy to fix. Systems now also change control correctly when the fleets move around and destroy each other. The system faction control still doesn't have any effect on the randomly spawned ships or the production of bases, though, as I haven't programmed that in yet.
 

[Christian Knudsen]

I managed to make fleets automatically rearrange themselves if one of their leading ships gets destroyed today. It was a bit of a hassle, but I finally just got it working. Fleets are made up of a hierarchy of ships, with the first ship not escorting anybody, but carrying out the fleet's order, and then every other ship in the fleet escorting/following either the first ship or one of the other escorting ships. The problem was that if one of the leading ships (a ship that has escortees) was destroyed, the escorting ships would no longer follow the fleet's order as their "link" to the first ship was destroyed. So I had to make it so that another ship would take the place of the destroyed ship and give the escorting ships a new ship to follow. It sounds simple in theory, but it proved a lot harder to program than I thought.
 

[Christian Knudsen]

With persistent fleets and ships that can move about in systems that you aren't in, some things are beginning to happen that the game wasn't designed with in mind. For example, ships will now be able to jump into a system you're in, not just jump out of it. This presents some extra design/coding challenges that I haven't initially thought of. How do I for example make sure that there isn't a ship inside the jump point about to jump out when another ship jumps in? The way I've done it with the wingman is that he'll only jump in when nobody's in the jump point. If you have a wingman, you'll notice that you can stay in the middle of the jump point as long as you want after having jumped to a new system. The moment you move out of it, your wingman will jump in. This has worked fine for your wingman, but it won't work for fleets. If a fleet won't jump in if there's a ship in the jump point, you'd be able to block enemy fleets from jumping in simply by sitting in the jump point. So, a ship in a jump point shouldn't be able to block a ship from jumping in. But how then to avoid a ship suddenly jumping in on top of you when you're about to jump out? Traffic lights!

I'm currently playing around with having colored traffic buoys around jump points. If it's green, you can use the jump point, but if it's yellow, another ship is about to jump in and you should clear the jump point. You'll get a fair bit of warning, so it'll be yellow for a while before turning red a few seconds before the other ship jumps in. A ship that hasn't cleared the jump point will either be destroyed or severly damaged when the other ship jumps in on top of it.
 

[Christian Knudsen]

I've now got fleets moving about in systems that the player isn't currently in. I've also managed to implement fleets jumping into the system the player is in. Here's a movie showing me following a fleet part of the way to a jump point, but going on ahead, jumping into the other system, and then waiting for the fleet to jump into the system:

injump.zip (0.7 MB)

Unzip the file and place it in the "movies" folder of your game directory. The movie will also demonstrate the new traffic buoys around jump points and a fleet jumping in with a group of ships at a time.

Next, I'll probably start work on the abstraction algorithms of fleet battles in systems the player isn't present in.
 

[Christian Knudsen]

The algorithms and procedures for assigning damage to fleet ships in a battle in a system the player isn't present in (or if the player isn't in space in that system) have now been implemented. I can now sit on a base while a fleet battle rages in space, and when I read in my Quine that the battle is over, I can launch into space and check out the damage inflicted upon the victorious fleet.

It still needs a bit of tweaking, though, as the battle results that these procedures result in don't exactly match those that happen when you're actually present at the battle and the ships really fight each other. Specifically, the most powerful fleet doesn't suffer quite as much damage through a calculated battle as through an actual battle. But it's working and it shouldn't be too difficult to get the results to match better.
 

[Christian Knudsen]

I got the results of calculated battles to resemble actual battles a bit more. As I said in my previous post, the problem was that an overpowered fleet would wipe out an underpowered fleet during the first "round" of the calculated battle, which meant that the overpowered fleet would receive practically no damage and lose no ships. This didn't match what would happen when these fleets met in actual battle, where the overpowered fleet would actually receive some damage and lose some ships. I implemented a simple fix today (the simplest solution is often the hardest to think of!): For the first two "rounds" of the calculated battle, all fleets won't deal more damage than the lowest powered fleet does. This will allow for all fleets to receive some damage before the battle is over. I'll probably still have to tweak it a bit when I improve the AI, as that will likely change the outcomes of battles a bit, but that should only be a matter of changing a couple of numbers.

I've also changed how ship variables are stored in the code. Before, there could be a maximum of about 60 fighters and 20 capitals active at the same time, I think. That's much too small of a number when fleets will be flying around, so I've now increased that to 250 for both fighters and capitals and may have to increase it even further. This means that the procedures for controlling AIs and autopilot are really slow now, so I'll have to do some optimization for that. One thing I plan to do is divide the space map up into smaller squares and track which ships are in which square. That would mean that I wouldn't have to for example check a ship's proximity to all active ships but just the ships in the same map square, which should speed up the process a lot. I'm also currently storing the ships in dynamic arrays, which means that the memory usage is never higher than the number of active ships, but dynamic arrays are notoriously slower than static arrays (which on the other hand always take up the max amount of memory), so I'll probably switch to static arrays.
 

[Christian Knudsen]

The randomly generated ships are now based on the faction controlling the system. This means that if the pirates decide to move their fleet from TC-101 to Vortex Prime (which won't have a Confed fleet in it at first), they'll take control of Vortex Prime and that system will be swarming with pirates the next time it's generated. That situation will also mean that all production of goods on Hooper's Hope will stop, as I've now made it so that when a system is "occupied" (meaning that it is controlled by a faction different from the faction it starts out with being controlled by) it'll no longer produce goods. Consumption of goods will continue though, so the stores will eventually be emptied. At some point the Confeds will of course launch a counter-offensive and hopefully take back the system and return production levels to normal. I may change it so that production won't halt entirely but just decrease considerably, but that's all for future balancing.

Next up is having fleets replenish and repair their destroyed and damaged ships after a battle. One way is to return the fleet to a faction base (retros and Kilrathi will also have bases at some point), but I also need to figure out a system that doesn't require a fleet to return to a faction base -- otherwise a faction that has lost control of all its bases will be unable to rebuild fleets and will effectively have lost.
 

[Christian Knudsen]

Fleet repairs are now working. The way it currently works is that after each fleet battle has ended, the game will check how much damage and how many destroyed ships each remaining fleet has, and based on that and a random factor for some fleets it will be decided that they need repairs and their destroyed ships replaced. The fleet will then first check if there's a base belonging to its faction (i.e. naval bases for confeds and pirate bases for pirates) anywhere nearby. If not, it'll check for any base in a system its faction controls. And if it can't find that either, it'll just go to the nearest system it controls and do its own repairs. How fast the repairs happen is also determined by this: The fastest is at a faction base, then at a controlled base, and then just in a controlled system without a base.

Replacing destroyed ships is still not in and neither is rebuilding completely destroyed fleets, but that shouldn't be too hard to add now that I've got repairs working. For now, the fleet will just be motionless next to the base when it is being repaired, but for some future 0.7.x version, I'll probably add small repair ships that go from ship to ship to indicate which ships are being repaired.

Another thing I've noticed while testing this new stuff is that it can be quite a problem with fleets taking over systems as soon as they've destroyed all other fleets. At one point, I went to sleep in a hotel and when I woke up, the system had been taken over by pirates, so when I launched into space, it was swarming with pirates. That can be a problem. So what I'll probably do is have the system be "occupied" for a period of time before it becomes completely controlled by the new faction, giving the player ample time to leave the system before the hordes of pirates/retros/kilrathi start spawning.

Oh, and I think I encountered my longest variable reference name today:

Fleet[FleetNumber].Ship[Fleet[FleetNumber].Repairing[I]].Damage[Fleet[FleetNumber].Ship[Fleet[FleetNumber].Repairing[I]].Damages - 1].Value

I could clean it up, but I think I'll just leave it as is.
 

[Christian Knudsen]

Time for another update. This fleet stuff is taking longer than anticipated, mostly because of bugs that are hard to fix. I thought I had fleet repairs/rebuilds working, and repairing does works fine, but I'm currently trying to track down a problem that happens when the lead ship of the fleet gets rebuilt. The way it works is that if the lead ship (or actually any ship that has escorts) gets destroyed, another ship in the fleet will take its place. That part works fine. The problem is when the destroyed ship gets rebuilt, the ship that took its place should go back to its original position in the fleet hierarchy and all the ships that were escorting this ship should now escort the rebuilt lead ship instead. For some reason, when the lead ship gets rebuilt, this doesn't happen like it should and all the ships of the fleet go zooming off towards some undefined point in space. It's a bit of a puzzler. I'll run some more tests to see what orders and targets the ships are given to make them zoom off like that.

Beyond that, I got everything related to fleets, fleet battles and system control to save correctly. This should make it a bit easier for me to test stuff, since so far I had to generate the situations I'd want to test from scratch each and every time. Now I can just reload the save game with the situation and replay it until I've fixed whatever bugs there may be.

I've also made some optimizations to how NPC ships see and react to other ships. Previously, an NPC ship would cycle through all other active ships to check for new targets and imminent collisions and stuff, which was a pretty big waste. Now, the playing field is divided into smaller squares and each ship's position is tracked within these squares. So when an NPC ship has to check for imminent collisions, instead of cycling through all active ships, it just cycles through the ships in the adjacent squares. This has improved CPU usage quite a bit. Autopilot is still a bit too slow, though, but I believe that's because I'm still using a dynamic array for storing ships. I'll change that to a static array (which will use a lot more RAM, but be a lot faster) so hopefully the autopilot will run at an acceptable speed.
 

[Christian Knudsen]

Finally figured out what was wrong with the fleet rebuilding stuff that caused the entire fleet to go zooming off into deep space. As is the case most of the time with these things, it was something different from what I thought it would be (which is why it took so long to find a pretty simple bug). The lead fleet ship was getting placed at some random spot in space because the code couldn't figure out which nav point the fleet was repairing/rebuilding at. I had just had the code cycle through the nav points in the system and check which one was within 8000m of the fleet, since the fleet will come to a stop somewhere around 6000m away from the nav point when going there for repairs and rebuilding. However, when you leave the system or land and then go back out into space, when the fleet is spawned, it's not spawned at the exact same spot it was saved at (this is on purpose). If I did this a couple of times, the fleet would no longer be within 8000m of the nav point, which is why the code couldn't figure out which nav point it was at and where to spawn the new ship. So, instead of having the code cycle through all nav points and check which one is within 8000m, I now just get the nav point by looking at the fleet's orders (which contain info about which system and nav point to go to for repairs). I'm glad it's fixed but also slightly annoyed that I spent a lot of time on a pretty simple and stupid bug. But that's programming in a nutshell, I guess...
 

[Christian Knudsen]

A quick update from New York (I'll be heading back home to Denmark tomorrow). The procedures for building new fleets are now done. The size and makeup of the fleet is randomly generated for now, but when I get to the part of the game where the player will have to build his own fleet and fight these other fleets, there will be various tactical choices added to the AI fleet building decisions (such as how many resources the faction has available and how fast they need to build a fleet and stuff). I'll probably begin work on the overall faction AI next -- this decides what fleets should do and where to go and what other fleets to attack and when to build new fleets and so on...
 

[Christian Knudsen]

I've got the overall fleet AI working now. There won't be a lot of fleet stuff happening all the time, as that will be saved for the second part of the game where the different factions all try to take control of the sector. For now, fleets will just move around a bit, sometimes trying to occupy an adjacent system or engaging another fleet that's encroaching on the faction's territory. During the tests, so far I've had Pirates and Confeds fighting over Primeval 1 and Vortex Prime a lot, the Pirates trying to take control of New Frankfurt (but being wiped out by the Confed fleet), and the Confeds successfully occupying and taking control of Zepyranth.

Fleets also don't automatically and immediately take control of a system when they're the only fleet in it anymore. They now have to occupy it for a period of time. This is primarily to avoid having the player going to sleep in a hotel and waking up to find the system taken over by Pirates and being unable to leave the system before being destroyed by a swarm of Pirates. The number of Pirates in the system will now instead steadily grow the longer it's been occupied by the Pirates, meaning that the player will have a chance to leave the system before it's completely taken over.

One thing that I've noticed during testing is that you very rarely come across the fleets in the game, since the fleets are moving about and the systems are all relatively large. Because of this, I'm going to try to have fleets show up on the system map in the nav computer. This will allow the player to select a fleet (in the same system) as the destination for the autopilot (or just navigate to the fleet manually).
 

[Christian Knudsen]

Fleets now show up on the system maps in both the nav computer and the Quine. I've also made some changes so that the maps in the nav computer and Quine look and function completely the same (meaning that mission nav points will now also show up in red in the Quine, among other things) and work a lot better with the fleets being displayed and the various faction coloring of systems:





In the bottom image, I've selected the Confed fleet as my autopilot destination (it's currently heading towards the Pirate fleet at Nav 1). I've done a bit of testing and seem to have fixed all the bugs I've encountered so far. Now I just need to do a few minor things (such as making sure that non-fleet ships stay far away from fleet ships, as they have a tendency to get in their way), and then go on to a thorough bit of testing where I just play the game a lot and make sure everything is working as intended... and then v0.7 should be good to go.
 

[Christian Knudsen]

I've updated the first post with a list of the stuff I want to add before I start working on persistent ships. This will probably be split into 2-3 releases (not counting any serious bug fix releases that may be necessary).
 

[Christian Knudsen]

So... As you may have noticed, development has been pretty much non-existent for a while. This is because I was working on some rather difficult stuff for Hostile Takeover that left my brain drained (http://laserbrainstudios.com/2011/02/development-video-10/). That work is mostly done now, so I'm back to working on Ascii Sector a bit every day. I'm currently continuing work on improving the ship AI and fixing some bugs that have been reported.
 

[Christian Knudsen]

I've been doing some tests on this item:

[Christian Knudsen]

Here's a sneak peak of the sector map with the five new systems:



As you can see, there's now a system controlled by Retros and one controlled by Kilrathi. I've also added the capital system (Crydon).

I've been thinking about whether or not the player should always be able to land at Retro and Kilrathi bases. Common sense would dictate that there's no way they'd let you land, but I feel it'd be a bit of a letdown if you're not able to land there. So I've been considering adding a risk of character attacks on hostile bases. The more hostile a faction is towards you (and maybe also the more members of that faction you've killed), the higher the risk of a Retro, Kilrathi or Pirate "recognizing" you and attacking you.
 

[Christian Knudsen]

It's been waaaay too long since the last development update. As some of you know, I've been looking for a job for about a year or so now and that's been stealing a lot of time from working on Ascii Sector (I also kinda got very hooked on finishing some stuff on Hostile Takeover). But, I've now got a job, and it's pretty much the most game dev friendly job I could imagine. I'm now a freelance translator working from home, so I can take on as many job tasks as I want and switch freely between translation work and game work. I'm a happy camper!

I'm currently working to fix all the bugs that CheeseshireCat and other players have been reporting lately. Then I want to finish the five new systems and the payment of fines at the capital planet. Maybe add a few more items from the to-do list. Then it's about time for another release!
 

[Christian Knudsen]

You know what feels really great? Having spent two hours programming in a new feature, then it just compiles without any errors and when you try it out, it runs perfectly. Feels gooood!

The new feature is that for quest dialogues, replies/questions that you've already said/asked will now be grayed out. You can still choose them, though, it's just a visual aid. Also, you can now have a conditional for each individual reply option, like this: