SCG Development Blog


Just finished the SV5.1 beta this weekend and made it available for download.  The 5.1 release contains some significant new features:

  • DynamicEvents property - Dynamic Scenario programming is made easier with the DynamicEvents property of the Scenario class.  Call methods of the DynamicEvents property to perform dynamic actions in a Scenario's ProcessImpulse method.  Also, the documentation for Dynamic Scenarios and Scenario Programming has been beefed up.
  • UDOs - User-Defined Objects that you can program in your Scenario.  They can be created at the beginning of the game, or during the game.  UDOs can be picked up and carried by StarShips, and can be the basis for the Scenario's Victory Conditions.
  • PaintHooks - Scenarios now have hooks to render directly to the .NET Graphics object of the game map.
  • Transport order - Transports have now much more flexible order options.  They can pick up Resources from a group of StarSystems or BattleStations and deliver to a destination StarSystem or BattleStation.


I've started working on Solar Vengeance 5.1. There are some exciting new features that will make SV even more customizable for Scenario developers.

1) I'm cleaning up the "Dynamic Scenario" aspect of the system. I've replaced the "DS_" methods in the Game object with a new interface which is exposed to the Scenario developer via a property called DynamicEvents. So, all dynamic Scenario calls are made through DynamicEvents. For example:

DynamicEvents.DisplayMessage("Welcome to the Tutorial Part 1.");

This is a better way to organize this feature of the game, and is in line with what I'm doing in WinWar II.

2) I will add a new set of DynamicEvents methods that let you create, manipulate, and interact with "User Defined Objects (UDO's)". You will even be able to assign your own static or animated sprite to a UDO. UDO's will be able to be attached to other game objects like StarShips so they will move with that object when attached. This will make "Capture the Flag" style Scenarios more easy to produce.

3) PaintHooks! There are 2 new Scenario methods, PaintHooks that are called during the screen rendering process. If you override the PaintHooks you are passed the .NET Graphics object that represents the game's main playing screen. So, you will be able to render anything you want to the game screen! This will open up endless opportunities for creativity in Scenario programming for SV. Like I said, there are 2 PaintHooks. One is called after the background but before the ship and starsystem sprites are rendered, and one is called after the sprites are rendered.


After a seven month hiatus I am back working on WinWar II 5 full steam.  My previous effort became stalled due to a problem in the way I build the internal data structures that represent units in the game.  This led me into problems that I couldn't overcome, and I new a re-design was needed.  Inspiration struck a few months ago and I'm happy to say that my new design conquered the old problems and WinWar II 5 is moving forward more quickly and smoothly now.

I can build forces (land, air, and sea) and move them around the map, including loading land units onto transports.  The new design is efficient, flexible, and elegant.

I am anxious to play this version!  You will need to make sure that your forces are not isolated, that they have a clear path to a Supply Source.  Otherwise, their strength will degrade as they move around the map.  A Supply Source could be a land-based HQ, or a BattleShip along the coast.  This makes strategic use of fleets a vital part of the game.  Speaking of fleets, in order to re-Supply them, you need to dock them into a friendly land zone.  Of course, when they're docked they are extremely vulnerable (ala Pearl Harbor.)  I like how this Supply mechanic works in the background without burdening the player, but rewards players who understand the system and now how to properly manage their units.

Another interesting twist is the introduction of "character" units into the game.  These represent Heads of State, and top Military Leaders.  You can, for example, let Rommel lead the armored battle into Africa, or put Yamamoto in your strongest Japanese fleet to gain his combat bonus.

Another interesting twist is the introduction of Spy units into the game.  These invisible units allow you to see what your enemies are doing from far away.  They can also steal enemy Technology Points if placed in enemy zones that contains Labs.  Be careful though, if your Spy is in a zone that contains enemy Spies, there's a chance it can get captured and eliminated!

View a screen shot


  • With summer here I've been spending more time outdoors, and played volleyball on the beach yesterday.  But I'm still working a little every day on WWII5.  Today I worked through the issues of loading land units onto transports, then splitting the fleet and moving part of the forces to a new location.


  • WWII5 - Loaded the first land units onto transports and move them via sea from Africa to Ukraine.


  • WWII5 - Completed the vibrating effect for the tiles where combat is going on.


  • WWII5 - Retreat command now working for units that have advanced into enemy occupied zones!  I've also implemented (but not yet tested) much of the MultiPlayer state change synchronization of the game.


  • WWII5 - Completed the interface that allows you to select a specific number of forces in a unit to split out and move.  In the process re-factored the original unit display list and created a custom unit list component to encapsulate all of this.  This nicely pushes alot of the code out from the main form into the component.  The selection interface is pretty smooth.  There is a list of unit types, and grabber bars in each list item, so you can easily click and drag to select the amount of forces of each unit type you want to move.  This "Move Some" functionality compliments the "Move All" (where you simply move all the forces) and the "Move Half" (which is a shortcut that quickly allows you to split a unit in half.)  Now that movement is more or less complete I need to turn my attention to how units behave when they are engaged in combat.  A unit that has invaded an enemy territory cannot move normally.  Instead, it can only retreat to the zone that it invaded from.  This will be my next task, implementing the retreat, making sure such units do not auto-consolidate, providing an interface to "Retreat All" or retreat individual units if multiple ones invaded an enemy zone, etc.


  • The question of the day: whether to auto-consolidate or not to auto-consolidate in WWII5 - has been answered.  WWII5 will auto-consolidate units that are in the same zone and do not have a move order (and are not engaged in combat).  After some user interface testing with this mode in place it felt natural easy to understand, and resulted in a less cumbersome user interface.  I believe it results in a smoother user experience with limited downside (the downside is that to continue to move part of a force you have to split the forces, but I am providing an easy interface to do this.)


  • Worked more on unit strength in WWII5.  As units move across the globe their strength level decreases.  It increases when they are at rest and have a path to a land-based Supply Center.  Land units can also replenish strength if they have a path to a friendly fleet that contains a Battleship or Carrier.  Sea units need to be adjacent to an allied Port in order to replenish their strength.


  • After more tinkering I am happy with how the USSR's territories are laid out now in the new map for WinWar II 5.


  • Continuing the grueling work of creating the map for WWII5 Standard Scenario.  Have most of the USSR and some of the rest of Asia completed.


  • Thanks go to T2M for pointing out a logical flaw in the implementation of the Elite StarShip type.  The Elites are WarShips whose Weapon rating increased by 1 whenever they destroy a StarShip.  The problem was the potential for abuse in MultiPlayer games.  An ally can auto-create small StarShips (like E1 Drones) and the other player can send his Elites on auto-destroy these easy pickings, resulting in vastly inflated Weapons ratings.  T2M proposed the solution which I adopted, whenever an Elite destroys a unit, it gains "kill points" equal to the building cost of that destroyed unit.  The Elite advances only when its "kill points" exceed the difference in cost for building an Elite with a next higher Weapons rating.  This nullifies an advantage of these "Elite training grounds" while preserving the spirit of the Elite.
  • WWII5 - when units move, animated arrows now move from the source zone to the destination zone, indicating overall troop movements around the map.  Thanks to beat2k for providing the necessary math!
  • Introduced the Submarine into WWII5!  Submarines are the only units in the standard Scenario that have the "Stealth" attribute.  This means enemy Subs are only visible when they are in a zone you occupy, unlike other units that are also visible in adjacent zones to ones you occupy.  Subs will provide an hidden strength element to fleets.  In order to determine the true strength of the fleet you will have to engage it!


  • I have finally fixed the longstanding problem in SV5 that resulted in two StarShips occupying the same space.  This happened when a StarShip was destroyed, and 2 other StarShips move into that space (or another ship is built into that space.)  I hope that my fix will correct all occurrences of the "ghost ship" phenomenon, but it you still see this after Build 10.1 let me know.


  • Completed the RemoteViewer StarShip type for SV5 Build 10.  Also, changed how StarShip images are stored.  Instead of a single image file, each StarShip now uses its own image (bmp) file.  This makes it easier for me now that I am adding more StarShip types.  It will also make it easier for people who want to create their own images for some or all of the StarShip types.


  • Added the first sea units to WWII5.  Also, units are able to move and split forces, and soon will be able to consolidate.  One of the back and forths I went through was how to display forces in the same zone that are actually composed of different units.  Originally I displayed the aggregate forces.  But I realized it would probably make things simpler to display the forces in accordance with the units that they are in.  This way, players can move their units independently more easily, and less internal auto-consolidation of forces needs to occur.


  • Have the effects of terrain inhibiting movement of units now in WWII5.  This is handled by giving each terrain type a chance of randomly aborting a unit's move on each impulse.  Mountains have the worst effect, having an 80% chance of aborting a possible move out of the zone.  Each aborted attempt still reduces a unit's strength.  Unit types can be configured to have their own terrain overrides.  Armor, for example, is not effected by Desert, but is more adversely effected by Forest.


  • Last night for SV5 I implemented the Elite unit type.  This is a WarShip that increases its Weapons rating every time it destroys another StarShip.  Additionally (still need to implement), cloaked Elites are hidden even from your allies with Intelligence or Formal alliances.
  • Perfected the path-finding algorithm for WWII5, which considers terrain.  Only thing left is to optimize the algorithm to stop considering paths if their current cost exceeds the cost of the most efficient path already found.
  • Got SV5 Build 9 out the door with the two new unit types, Elites and ParalyShips!


  • WWII5, land units are now moving across Europe!  Much work ahead, including air unit rebasing (air units will not "move" like other unit classes), sea units, effects of terrain on movement, deducting cost and strength for moving units, the ability to separate forces from a unit, and combat, but this is a milestone.


  • Working on the internal object model for WWII5, including how unit types and strengths are represented internally.  Each tile can have one or more units, and units can contain forces of land, air, or sea unit types.  Each unit type in the unit will have a variable force strength.  Strength will be reduced as the unit moves and engages in combat.  It will go down sharply if the unit moves through harsh terrain tiles.  Strength will be replenished when the unit sits inactive within a path to a Supply Center.  Fleets will need to be next to a Port zone in order to replenish.  The unit strengths are visible as little bar gauges next to each unit type that you see when you click on a tile.  My goal is to make this system work as smoothly as possible automatically without having to burden the player with unnecessary micromanagement.
  • SV5 Build 8.4 fixes the bug that occurs when you build a ship off the edge of the map!


  • Made several fixes in SV5, and added the ability for Freighters to transport from BattleStations to StarSystems.  Added the visual Brain Duel "Lightning Mode".  Included the Tutorial and MirroredDoubleCluster Scenarios and released as Build 8.2.


  • Released PrismPing.
  • I've optimized the data packets sent for state changes in SV5, the network traffic generated by the game should be reduced substantially now, and this may help with some of the lag seen when massive amounts of ships are built!
  • Testing indicates that the lag problem is virtually gone now, thanks to condensed information in the data packets, and some optimizations on internal game lookups.


  • Added many new Dynamic Scenario methods to SV5, that will go into Build 8.  Beat2k is using these new methods to build some interesting new Scenarios, including an interactive tutorial.
  • Working on a PrismPing program, that will reside in the Windows taskbar and let you know who's connected to PrismServer at any time.


  • Finished the MapSet Editor, will offer it as part of next release of TurboSprite, and as a standalone tool download soon.


  • Now that SV5 has become fairly stable I am turning attention to optimization, to make the game run faster.  When a large number of ships appear there is noticable lag and the game can get agonizingly slow.  I think I found a "quick fix" that will speed up graphics performance by about 40%!  SV5 is written completely in C#, and I don't want to go outside of the .NET Framework for this project.  My TurboSprite is 100% C# managed code as well.  But I found that .NET's DrawImage call is notoriously slow, UNLESS you use a PixelFormat of Format32bppPArgb.  I modified TurboSprite and did a quick benchmark, and sure enough the rendering speed increased by 40%!  I have a few other optimizations to do and will then release this in SV5 Build 7.1 later tonight.
  • I'm cleaning up my ad-hoc tool I created to build MapSets for tile-based maps.  In other words, I'm creating a more polished and proper MapSet Editor that I and others might use to produce MapSet files.  MapSets are XML files that contain the following:
    • Information about the MapSet, like its width and height in pixels.
    • A list of MapSet Tiles.  A Tile is a list of Points that defines the polygon, and also things like the Tile's name and whether it is a land zone or a sea zone.
    • A list of optional map decorations that are images that are overlaid on the map with translucency.
  • WinWarII 5 will use these MapSets in its Scenario format.  A WinWarII Scenario file is a simple text file that lists unit types, nations, alliances, and then the different properties of the zones that are established in the MapSet.  I will need to also provide a way to hook the Scenario into a C# class that can process special actions on an Impulse by Impulse basis, like the SV5 Scenario.ProcessImpulse method.
  • The good thing about this separation is that future tile-based games, like Proliferation 2, can use the same MapSet format.  Also, other developers can use it for their own games.  The work on my tile-based map components (not yet including the MapSet Editor) is in the TurboSprite release.


  • Added some finishing touches to the SV5 PrismServer Lobby interface.  A welcome message, a version check, and server statistics on the Server Info page.  This is in SV5 Build 7.1 now available.  Should be pretty close now to being able to release the MasterServer, so others can run game servers.


  • SV5 Build 7 released.


  • I'm working more on the scenario definition file for WWII5.  For the first time, I've taken the path of defining the unit types themselves in the scenario.  This will provide the maximum flexibility to scenario creators, who will be able to model virtually any type of global or map based conflict with the new game engine.


  • Finished the CompassNavigator component for TurboSprite.  You drop this on the form, connect to the SpriteSurface, and voila! - a compass that you can use to smoothly scroll around the map in any direction.  Integrated this into WinWarII 5 user interface.
  • New WinWarII 5 map update visible here!


  • More work completed on WinWar II 5 internal game engine.  Have the basic MapSet XML file, and Scenario txt file definitions established.


  • SV5 Build 6 released!  Includes the Dynamic Scenario capability, via the Scenario.Process method, and the SVGame.DS_Random and SVGame.DS_RepositionObject method.  The provided Scenario, HighEnergy, illsutrates how this can be used.  I'm sure more questions will follow, and I intend to more fully document this exciting new feature.  Also, Build 6 includes beat2K's PL4 Scenario, and missiles are improved - they no longer are subject to StarTillery fire!


  • SV5 Build 6 is almost ready to release.  The biggest enhancement to the game is the concept of a Dynamic Scenario.  Scenarios now have a new method called ProcessImpulse that you can override.  Within this method you can examine and alter the internal state of the game.  You can do fun things like relocate StarShips or other objects based on different conditions, damage or destroy StarShips, or, like the new Scenario "HighEnergy", increase the power of StarShips.  This is only a sample of what is possible, since the method has full access to the internal state of the game via the "Game" property, which returns the instance of the SVGame class that contains the current game state.


  • I had a few hours on a plane ride today so I decided to tackle something I'd been meaning to do, change how StarSystem names are randomly generated in SV5.  From the beginning of SV, I used a very simple method of creating StarSystem names.  A file of hyphenated sample names in input, and the syllables mixed and matched to get a random new name.  It worked, but for awhile I've been wanting to implement Markov Chains to generate the names.  A Markov Chain reads a set of words, then builds distributions of the letters that follow any given letter, or 2, 3, or N character segment of a each word.  By using these distributions, new random words can be created that wind up sounding similar to the words in the sample set.  I created a new general purpose component, MarkovNameGenerator, which can read a file of sample words, and produce random words based on the samples.  It has a property called "Order" that determines the order of the Markov chain (how many characters are used as tokens when building the chains.)  A 2-Order Markov Chain winds up generating very usable random StarSystem names for SV5 using the same sample file that is already created!


  • SV5 - Fixed a couple more bugs, one related to releasing tugged ships in MultiPlayer, and one caused by placing CreateTerrainImage images in sub-folders.  Also coming up with feature list of what will be included in Build 6.  It will include beat2K's PL4 scenario.
  • WWII5 - Started implementing the object model of the game, as well as some of the basic user interface.  Compiling good ideas for game mechanics!


  • In SV5 I fixed code that checked whether objects are in bounds on the map during Scenario creation.  There were a few holes there, producing intermittent errors.
  • MapSet work - I conquered the shorelines!  My shorelines are now being calculated and rendered automatically by the TileBasedSpriteSurface and MapSet component combos.  Click here to see the shorelines of WinWar II!


  • Working more on the tile-based map system I will use for games like WinWar II 5 and Proliferation 2.  I have a cool shoreline effect where sea zones are adjacent to land zones.  Click here for a preview.  There are only 2 sea zones defined now, and there's still a slight imperfection.  I need to provide a way to make the shoreline contiguous between adjacent sea zones so it doesn't break like you see in the image, but that will be handled soon.


  • Build 5 is released!  In the process of creating the RingNebula Scenario I discovered many bugs in the Scenario BuildStarShip implementation.  That's all fixed now.  Scenarios can start with pre-defined fleets.  Also, the standard capital conquering VC can be disabled, as well as the default logic of assigning capitals.  This makes SV5 so much more flexible.


  • Worked on completing features for SV5 Build 5, including saving of Scenario parameters, Scenario.CreateTerrainImage, and Scenario.CapitalElimination (which allows you to disable the elimination of a player when their Capital is conquered.)  Before releasing Build 5 I'd like to flex my imagination by creating a new Scenario that takes advantage of the background images.  Maybe something where players start with equally balanced fleets, and no StarSystems(!) - and have to conquer the one StarSystem in the middle of the Ring Nebula.


  • Fixed a few more bugs.  Added Pulsars, and the Sprawling Scenario, and Stratego4, in Build 4.


  • Worked more on exception handling in SV5.  I created a generic GlobalExceptionHandler component that works just by dropping it on the form.  It should now intercept any exception from any running threads, and provide a dialog box allowing the user to click a link and email the error info to SCG.  This is in build 3.6 available now.


  • SV5 items: Beefed up the exception handling to try and catch any remaining bugs in the game code. This should (hopefully) prevent any future crashes in the game. Instead you should see a dialog box that contains the line number that produced the error. Send me this info if you happen to see it pop up during play.
  • Added the BuildStarShip method to the Brain API so they can build from their BattleStations.
  • Fixed the strategic map so it centers just by clicking in it.
  • WinWarII5: Completed map tile setup for Europe and the Middle east.  My Mapset creation tool is also shaping up.  Created a re-usable SpriteSurfaceNavigator visual component to serve as the basis for game mini-maps.  Really should have done this to begin with in SV5 but better late than never.  Derived a TileBasedNavigator from this to render the tiles by color in the minimap display.
  • Take a peek at my MapSet Editor (work in progress), and quite possibly the genesis of the new map for WinWar II 5.0!
  • Finally fixed the pesky bug that caused the Rank to not update in SV5 after a game completes.  This was a server side change so existing clients should now see the correct result incoming.


  • Working on the enhancements to TurboSprite that will allow me to create the tile-based map for WinWar II 5.0.  These include components like TileBasedSpriteSurface, Tile and MapSet.  I'm also in the process of developing a tool to use to build the map.
  • Added new Brain API methods: PlayerNames, GetTerrain, IsMultiPlayerGame and IsPlayerHuman and released this in Build 3.4.


  • T2M joined in a game of SV5 from Germany and promptly saw negative Resources on his StarSystems!  I quickly realized the culprit was the string->double conversion routines used in passing state information during MultiPlayer games.  I needed to ensure that the clients use the same CultureInfo for conversions.  Fixed this in build 3.3.
  • Also fixed the StarTillery alliance bug in SV5 MultiPlayer games.
  • Starting to gather ideas for how to best implement the map in WWII5.


  • Added visualizations of StarSystem ownership during Brain Duels.  Also, the Brain Duel matches will end in a draw if a StarSystem ownership has not changed in 1000 Impulses.  Finally, any Brain generated errors are just displayed in the restulr area instead of popping a message box.  This should allow lengthy Brain Duels to complete.
  • Added Stratego3, TinyBoss and LittleDragon to authorized Brains.
  • Fixed a bug that caused passing over of Brain control to other players after host was defeated in MultiPlayer games to fail.
  • Added Surrender option in MultiPlayer games.


  • Played the first 4 player game of SV5 to completion last night.  DoubleCluster with beat2k against UGT and BluePlague.  I have to learn to defend my Capital better! ;)
  • I never anticipated someone would want to make a Brain's call to AvailableShipTypes dynamic based on the initial Scenario setup.  I have this handled now for Build 2 Patch 3.
  • Integrated the awesome new SpiralSprite contributed by beat2k into the game to represent Black Holes, the effect is really amazing!
  • Build 2 Patch 4 is released.


  • Discovered a small bug in the externalization of the background starfield, which was causing problems displaying false nebula.  So, I had to rush the release of Build 2 of SV5, which includes Black Holes.

The entries below are specific to Solar Vengeance 5 development.  As of 5/22/2008 I am turning this into a general Development Blog, as I am starting to consider development for WinWar II 5, Proliferation 2, and Ceres, Inc.

Release Build 1 - 5/22/2008

  • Yes!  I found a solution to the SoundPlayer .NET class distorting the noises.  This was caused by the .NET Framework moving the buffer while a sound is playing.  The solution is to play sounds through files rather than embedded resources.  I tested this and it does indeed solve the problem, and appears to have no impact on performance.
  • Wrapped Scenario and Brain execution in exception handling blocks, and provide a way to cancel the game if Brains throw exceptions, rather than crashing SV5.
  • Externalized game graphics so players can create their own graphics sets.
  • Finished Help.

Build 16 5/21/2008

  • Created an installation, and performed some last minute fixes.

Build 15 5/21/2008

  • Improved stability of the sound playing system, I think it's the best I can get using .NET's SoundPlayer class.
  • Added AlliedWithMe method to Brain API so the Brains can tell who has allied with them.
  • Help documentation nearly completed.
  • You can now choose your color in the Star Lord Profile section.

Build 14 5/20/2008

  • Fixed graphics problems that sometimes occur when scrolling in Strategic map.
  • Optimized creation of objects so Brain processing is more efficient.
  • Implemented "closed" Patrol order.
  • More Help completed.
  • Brain orders to move outside of map will now accept the order but truncate the destination coordinates.
  • First compile with Visual Studio 2008.  Although I successfully created a build targeted at .NET 3.5, I am going to let SV5 remain targeted at .NET 2.0.  The redistributable of .NET 3.5 is about 10 times larger, and so far I am not using any 3.5 specific features, so I want to reduce the burden on users who want to play.

Build 13 Released 5/18/2008

  • Improved the methods ClosestStarSystem and ClosestStarShip in the Brain class to make it possible to find StarSystems and StarShips with more precision.

Build 12 Released 5/17/2008

  • Starting impulse for Brain duels was off by 1, leading to disadvantage of 9 impulses to first Brain - corrected.
  • Added approved brain Juggernaut.

Build 11 Released 5/17/2008

  • Toned down color of grid.
  • Improved scrolling in Strategic view and AutoScrollers.
  • Remove flickering from Diplomatic, StarShip List, and StarSystem List support windows.
  • Gave Brains the capability of going on AutoShields, AutoScanners, and AutoStarShip build modes.  Also provided properties in StarSystemInfo to access the current settings.
  • Added ClearOrder method to Brain class so Brains can clear their orders if needed.
  • Fixed some code that caused Brains to not always be able to build StarShips.

Build 10 Released 5/16/2008

  • Added grid display option in playing map.
  • Prevented flickering of title screen graphics on startup.
  • Setting Auto-StarShip type now turns on AutoBuild.

Build 9 Released 5/16/2008

  • Added Author property to Brains and Scenarios, and display this in the lists.
  • Submission of a registered Brain duel, and generation of the Brain Rankings page.
  • Modified ranking scheme - Player and Brain rankings now begin at 1,000, and can go down to 50 minimum.
  • Gave Brains access to information about visible Wormholes.

Build 7/8 Released 5/14/2008

  • Fixed GravShip bug that occurred during Multiplayer games.
  • Reload Brain source code before each game starts, so SV5 doesn't have to be restarted whenever a Brain developer makes a source code change.
  • Do not allow Patrol order if only one point defined in route.
  • Fix bug when you select a range when already providing an order for a group of ships.
  • Allow way to adjust ship selection from Prism lobby.

Build 6 Released 5/14/2008

  • Added some optimizations geared toward improving performance.

Build 5 Released 5/13/2008

  • Worked through some bugs revealed in Multiplayer games with beat2k and Ugly Green Things.  I believe the crashes were caused by submitting orders for StarShips that had already been destroyed in the host's session.  Latency issues were causing these orders for ships that no longer exist to cause null-reference exceptions.
  • A note on the new Brain Duel interface in the Prism Lobby - you can run a duel, but the results are not yet transmitted or recorded.

Build 4 Released 5/13/2008

  • Adding provision to run registered Brain duels.  A duel runs a series of games pitting the approved Brains against each other one duel at a time, running all combinations, using the Scenario "MirrorImage" to ensure fairness.  The results are then transmitted to the server, and then and only then displayed to the user.  These duels run quickly - a single match takes on average 20 seconds to process.  The server will manage an official Brain Ranking page that uses the same ranking system as used for human StarLords.  Each Brain will start with a rating of 1,000.
  • Added OwnerInt properties to StarShipInfo and StarSystemInfo.

Build 3 Released 5/13/2008

  • StarSystem Auto commands must be cleared after a conquest.
  • Added message when player has left an active game (dropped or disconnected).


  • The SCG Master PrismServer maintains a set of "approved" Scenarios for Multiplayer games.  The source code of these Scenarios is transmitted to the client after connecting to PrismServer.  When Multiplayer games are started, SV uses the Scenario source code provided by the server.  This prevents players from cheating by rigging their Scenario code, or worse, injecting viruses into other player's sessions that they might have embedded in the Scenario code.  I realized I need to do the same for Brains.  I will maintain a set of Brains approved for Multiplayer games, and transmit their source code to the clients before starting a game.  You will not be able to start a Multiplayer game with a non-approved Brain selected.
  • I've completed the "approved" Brain logic and have turned to the ranking system.  I wanted to find a ranking system that will lead to fair and effective rating scores, and after some time searching have decided to use the system described here.  I have the host of the Multiplayer game sending the result to the server after a game is completed, next step is to have the server interpret the result and adjust player ratings.  Everyone will start with a rating of 50, and this will also be the rating "floor".  No one's rating can fall below 50 no matter how badly they play ;)
  • OK - the server is now calculating rankings and ratings, saving them, and sending them back to the client.  I now want to have the server automatically maintain a game log, and a ranking page in HTML format.  I will provide links in the client to view these pages.
  • Just released alpha version.
  • Whew - just did some Multiplayer testing with beat2k.  Found a couple of bugs, fixed one nasty one in build Alpha 2.


  • Brains are completed.  I also extended the Scenario interface to allow the Scenario to restrict StarShip types available, and to add StarShip types to players at startup.  What's left is the work to allow brain-duels, the ranking system for Multiplayer games, and the server-maintained game logs.


  • StarLord Diplomatic interface completed and implemented.  This includes player to player chat, and changes to alliance levels between players.
  • Finished Auto-StarShip building capability.  This completes the last major feature in the actual game client.  The only thing left now is working on the Brain class, Brain duels, the Help, and making sure Brains work correctly in Multiplayer games.  Like Scenarios, Brains are .NET classes that derive from an abstract base class, in this case the "Brain" class.  new Brains can be written in C#.  The C# source file can be placed in the Brains folder under the main SV5 folder, and that Brain will be available to select and use in a game.
  • Making headway on the Brain implementation, including the prototype for "Defender".  Actually finished the "BuildStarShip" Brain method, and my computer Players are now creating (for the moment stationary) WarShips that I can pound.
  • Finished my first "game" against 10 Defender Brain players, that's right, 11 players total!


  • Created the Help Viewer, and began working on the Help.  These are simple HTML files rendered in an embedded browser with a TreeView contents pane.
  • Added Pause and Resume functionality for solo games.
  • Working on consolidated StarLord Diplomatic Relations control panel for Multiplayer games.  In here you can chat with other players, with channels for All, Allied, or Enemy.  You can also view and establish Alliance Levels.  There will be 3 levels of Alliances in SV5: Friendly (StarShips will not auto-attack), Intelligence (shared visibility), and Formal.  Allied victories will be declared only through mutual Formal alliances.
  • Finished the alliance control portion of the Diplomatic interface.


  • Completed the StarSystem list support interface form.  Players use this to see a quick overview of their empire, and easily navigate to StarSystems of interest that they own.
  • Also finished the StarShip list support interface form.


  • Finished CloakDetecdtors.  These are enhanced in SV5.  They display up to 8 arrows at once, allowing the owner to detect the presence of multiple cloaked ships within the Detector Range.
  • Completed CommandShips.
  • Coded alliance levels, NonAggression and Visibility.  Also, modified the default CheckVictory method of the Scenario class.  Scenarios can override this method to create their own game-specific Victory Conditions.  The default VC checks to see if all of the remaining StarLords are mutually allied.
  • Finished ShieldGenerators.
  • Finished DoppleShips.
  • Finished the new kid on the block, the BeamShip.  This one might be a "game changer".  Great defensive ship.  Allows you to target an enemy StarShip within the Beam Range, and destroy it in a single attack.  The downside is that you need to manually target the ships you want to destroy, one by one.  I'm working now to balance this appropriately by giving it a sufficiently high Beam cost.
  • Whew!  Finished JumpGateShips - the last StarShip type.
  • Moving onto the user interface, completed the translucent scrolling regions that allow for scrolling when the mouse is over them.
  • Interface enhancement - right clicking instead of left clicking on map centers the map to the space clicked.


  • Completed GravShips.
  • Finished NukeMissiles and DoomMissiles, and slightly improved their offensive capability to make them more tempting StarShip types to choose from.  NukeMissiles can now reduce a target StarSystem's Resources to below zero, putting that StarSystem effectively out of play while it repairs the catastrophic damage inflicted by the NukeMissile.
  • Prettied up the StarShip selection interface, moved the StarShip descriptions into individual HTML files that will also be included in the Help.
  • Implemented SpyShip spying capability.
  • Implemented StarShip cloaking.
  • Implemented StarTillery.


  • Completed auto-attack of adjacent enemies logic.
  • Implemented Tugs and tugging, including visual effects.
  • Finished RepairShips.
  • Completed ability of BattleStations to repair, scoop Resources, and build StarShips.


  • Finished Wormholes.
  • Finished rendering of the current StarShip Orders in the main display area.
  • Completed InkSpot tagging and evasion logic.
  • Completed EMine detonation logic.
  • Also finished TechShip processing, increasing Tech Multiple.
  • Finally, implemented HijackShips.


  • Working on some of the miscellaneous game interface, the center-on-Capital button, the load/and save game buttons, and the StarSystem-attacked-buttons that appear along the bottom when one of your StarSystems is attacked.
  • Finished the special effect (a radiating shock wave) when a StarSystem is attacked.
  • Added the basic plumbing for Alliances (Friendly, and Formal).


  • Completed the attack and damage logic for Drones, WarShips/DoppleShips.  Also completed the implementation of "known" Weapons values of attacking enemy ships.
  • Ported ParticleExplosionSprite to TurboSprite.Net, with some changes to make the explosions more flexible.  Implemented StarShip damage and destruction using this Sprite class.


  • Completed the mechanism where "approved Scenarios" are stored on the server, and the source code of the approved Scenario is sent to the client and compiled on the fly when a new multi-player game is started.  This defeats the ability to cheat by changing the source code of the approved Scenarios.  Players will still be able to join games from non-approved Scenarios at their own risk.
  • Fleshed out the Scenario base class object.  To create new Scenarios for SV5, you simply program a new C# class that descends from Scenario.  Because SV5 compiles the source code internally, we will likely have to restrict Scenarios and Brains to C# code for now.
  • Replicated the DoubleCluster Scenario.
  • Fine tuned and tested the victory condition determination that occurs after each impulse.  This is now a virtual method of the Scenario class, which means that a Scenario can define with great detail (in C# code) its own victory conditions.  And the Scenario object as access the Game object, and thus all of the underlying information contained in the game.  So, tonight I saw the first VICTORY and CONQUERED messages as the red player conquered the yellow player's capital.


  • Completed the Patrol order.
  • Completed Defend order.
  • and ... completed Transport order.


  • Working on sounds for the game.  The .NET framework's support of sound leaves alot to be desired.  I'm tempted to use the DirectSound wrapper as I did in previous games, but part of the exercise here is trying to keep the game written in 100% managed code.  Doing so would (theoretically) allow ports of the game to other OS'es.  So, I will attempt to avoid going to Interop and accessing native Windows functions.
  • Completed Escort order.


  • State change subsystem completed, and debugging of GameCoordinator component looking good.  Orders are sent to the host, who processes the impulse and sends state changes to the clients.  The end result is I now tested the first multiplayer game in SV5 and have ships from 2 players being built and moving in both game instances.
  • Targeting and conquering StarSystems implemented.


  • Completed the whole "persistence" subsystem that allows game states to be saved and re-loaded.
  • StarShip orders now render as ghostly shimmering lines.
  • StarShips are now Moving!  Move order processing completed.


  • Working on integration of PrismServer, login, lobby, starting a game.


  • I can now build StarShips!
  • Working on StarShip command interface.  I'm implementing a streamlined command interface, where you click your ship, and can then immediately click a destination or target without an intermediate command button.  Other commands (like Escort) still have command buttons (and keyboard shortcuts) available.
  • Added selection band to SquareGridSpriteSurface


  • PrismServer 5.1 build completed, added GameCoordinator component to synchronize real-time strategy games.  Open source will be released soon.
  • TurboSprite 5.0 (C# .NET version) nearly completed and ready for open source release.
  • Development on Solar Vengeance 5.0 commencing.  5.0 is a basic port of the game to .NET and C#, with a few additional features.  Most important, much more robust Brain and Scenario programming in any .NET language (note 5/1/2008 - Scenario and Brain programming will likely be restricted to C# in 5.0).