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
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
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
- 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
- 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
- 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
- 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
- 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 18.104.22.168 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.
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- Added Stratego3, TinyBoss and LittleDragon to
- Fixed a bug that caused passing over of
Brain control to other players after host was defeated in MultiPlayer games to
- 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
- 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
- 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
- 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
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
Build 7/8 Released 5/14/2008
- Fixed GravShip bug that occurred during
- 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
Build 6 Released 5/14/2008
- Added some optimizations geared toward
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
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
- Added OwnerInt properties to StarShipInfo
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
- Whew - just did some Multiplayer testing
with beat2k. Found a couple of bugs, fixed one nasty one in build Alpha
- 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
- 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
- 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
- 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
- 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
- Implemented Tugs and tugging, including
- 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
- 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
- Completed the whole "persistence" subsystem
that allows game states to be saved and re-loaded.
- StarShip orders now render as ghostly
- StarShips are now Moving! Move order
- 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
- 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).