No major new StarWright news, other than that I have just posted a new build of the game that shows off the starship designer, ship combat, and multiplayer!
Download it from here: http://starwright.waltdestler.com/
Sunday, September 1, 2013
Sunday, June 16, 2013
StarWright - Power
Over the past couple of weeks I implemented one of the last remaining starship simulation mechanics that I had planned to create. This mechanic has to do with providing power to all the various ship systems.
The power mechanic works very similarly to the existing ammo mechanic. If you don't recall, the purpose of the ammo mechanic is to require the player to carefully balance weapons (which consume ammo) with ammo supplies. The closer the ammo supply is to a weapon, the faster the ammo can be delivered, and the faster the weapon can shoot, so the player has to think carefully about where they place weapons and ammo supplies relative to each other. While I've found that this mechanic is successful in giving greater depth to the design of small, localized areas of ships, it adds little depth to the overall design of larger ships since ammo rarely needs to be transported more than short distances.
The power mechanic is intended to complement the ammo mechanic by providing greater depth to the overall design of larger ships. Power works similarly to ammo in that many ship systems (currently thrusters, ammo supplies, and the cockpit) require power to operate. And just like ammo, power "batteries" (for lack of a better word) must be hand-delivered by the ship's crew to the systems that need power. But power is different from ammo in the distance that batteries travel, the rate at which batteries are consumed, and the cost of creating batteries. Ammo is consumed very quickly during combat, but ammo typically travels only short distances, since ammo supplies are cheap enough that any well-designed ship will have one for every few weapons. Producing batteries, on the other hand, is extremely expensive due to the very high dollar cost of the "reactor core", a new ship part that produces batteries. The reactor core is so expensive that most any medium-size ship will only have one. Thankfully, power-consuming systems need fresh batteries fairly infrequently, so the potentially longer distances between the power core and power-consuming systems is not as big a deal as it would be for ammo. However, the distance that power has to travel is still a major consideration when designing a ship, so choosing a relatively central and protected location for the reactor core and keeping traffic congestion low is very important.
Here's a screenshot showing a power core and glowing batteries being carried to some nearby systems:
As I mentioned above, the ammo supply now requires power to operate. You can see the new redesigned ammo supply and thruster artwork in the above screenshot, which clearly shows how many batteries the thrusters and ammo supplies have remaining. Since producing ammo now requires power, power is now the most important resource on any ship. Without it all your systems will eventually become non-functional.
Reactor cores are very expensive, but they can produce an unlimited amount of power. Sometimes when designing a ship, you may find it beneficial to have a closer source of batteries, but you don't want the huge added expensive of another reactor core. The compromise solution is a "battery storage" which can be seen in this screenshot:
A battery storage room does not itself produce batteries, but it can store up to 15 batteries in case of an urgent spike in local demand for power. When all 15 batteries are used up, then any additional batteries must come directly from the reactor core, or the battery storage must be re-filled from the reactor.
If you think it's weird that power must be carried by hand instead of over wires, then I admit you're right. This is a design decision where I have deliberately compromised realism for the sake of deeper ship design and a more transparent simulation. The ship design is deeper because batteries make large-scale ship design decisions and corridor layouts more meaningful. And the simulation is more transparent and understandable because, rather than having some abstracted representation or numbers for power levels, you can actually see how power travels throughout the ship as it is being carried around by the crew.
The power mechanic works very similarly to the existing ammo mechanic. If you don't recall, the purpose of the ammo mechanic is to require the player to carefully balance weapons (which consume ammo) with ammo supplies. The closer the ammo supply is to a weapon, the faster the ammo can be delivered, and the faster the weapon can shoot, so the player has to think carefully about where they place weapons and ammo supplies relative to each other. While I've found that this mechanic is successful in giving greater depth to the design of small, localized areas of ships, it adds little depth to the overall design of larger ships since ammo rarely needs to be transported more than short distances.
The power mechanic is intended to complement the ammo mechanic by providing greater depth to the overall design of larger ships. Power works similarly to ammo in that many ship systems (currently thrusters, ammo supplies, and the cockpit) require power to operate. And just like ammo, power "batteries" (for lack of a better word) must be hand-delivered by the ship's crew to the systems that need power. But power is different from ammo in the distance that batteries travel, the rate at which batteries are consumed, and the cost of creating batteries. Ammo is consumed very quickly during combat, but ammo typically travels only short distances, since ammo supplies are cheap enough that any well-designed ship will have one for every few weapons. Producing batteries, on the other hand, is extremely expensive due to the very high dollar cost of the "reactor core", a new ship part that produces batteries. The reactor core is so expensive that most any medium-size ship will only have one. Thankfully, power-consuming systems need fresh batteries fairly infrequently, so the potentially longer distances between the power core and power-consuming systems is not as big a deal as it would be for ammo. However, the distance that power has to travel is still a major consideration when designing a ship, so choosing a relatively central and protected location for the reactor core and keeping traffic congestion low is very important.
Here's a screenshot showing a power core and glowing batteries being carried to some nearby systems:
As I mentioned above, the ammo supply now requires power to operate. You can see the new redesigned ammo supply and thruster artwork in the above screenshot, which clearly shows how many batteries the thrusters and ammo supplies have remaining. Since producing ammo now requires power, power is now the most important resource on any ship. Without it all your systems will eventually become non-functional.
Reactor cores are very expensive, but they can produce an unlimited amount of power. Sometimes when designing a ship, you may find it beneficial to have a closer source of batteries, but you don't want the huge added expensive of another reactor core. The compromise solution is a "battery storage" which can be seen in this screenshot:
A battery storage room does not itself produce batteries, but it can store up to 15 batteries in case of an urgent spike in local demand for power. When all 15 batteries are used up, then any additional batteries must come directly from the reactor core, or the battery storage must be re-filled from the reactor.
If you think it's weird that power must be carried by hand instead of over wires, then I admit you're right. This is a design decision where I have deliberately compromised realism for the sake of deeper ship design and a more transparent simulation. The ship design is deeper because batteries make large-scale ship design decisions and corridor layouts more meaningful. And the simulation is more transparent and understandable because, rather than having some abstracted representation or numbers for power levels, you can actually see how power travels throughout the ship as it is being carried around by the crew.
Saturday, May 11, 2013
StarWright - Doors, Doors, Doors
Recently I finished an artistic revamp to StarWright's visuals. One of the most important improvements is the addition of a separate layer of walls that is rendered above the crew on the ship. This gave the feeling of actually viewing a cross-sectional floor plan of the ship, which was sorely missing in earlier versions. But the one big oddity with that revamp was that the crew could still walk between the walls, which was definitely weird.
Now, finally, ships in StarWright have walls that crew can't move through, and of course by necessity, doors in the walls!
The player may place those white double-sliding doors in any legal wall locations (some are blocked). Once a wall has a door in it, crew may freely move through the wall. As in a lot of space fiction (Star Trek in particular), when a crew member walks up to a door, the door will automatically slide open to let them through.
From a technical standpoint, implementing doors and walls was much trickier than you might initially suspect, for a handful of reasons:
Now, finally, ships in StarWright have walls that crew can't move through, and of course by necessity, doors in the walls!
The player may place those white double-sliding doors in any legal wall locations (some are blocked). Once a wall has a door in it, crew may freely move through the wall. As in a lot of space fiction (Star Trek in particular), when a crew member walks up to a door, the door will automatically slide open to let them through.
From a technical standpoint, implementing doors and walls was much trickier than you might initially suspect, for a handful of reasons:
- The pathfinding system was previously unaware of the presence of walls between rooms, and making it "wall-aware" required a significant retrofit.
- The pathfinding system previously assumed that the entire ship was contiguous -- that is, it assumed that it was possible to get from any location of the ship to any other location of the ship. Additional fixes were required to remove this assumption.
- I didn't want to have to update every wall sprite with every possible door location, because that would have added many times as many wall sprites. Instead, I had to devise a way for the doors to "replace" the particular section of wall that they occupy, but no other parts of the wall. To do this, I render a rectangle representing the door sprites to a special off-screen "stencil" buffer. Then when I render the walls themselves, ever pixel of the wall gets checked against that stencil buffer to make sure there's no door at that pixel.
- Every door sprite has animations to open and close as crew walk through. Unfortunately, doing potentially hundreds of simultaneous sprite animations on the CPU can be slow, so instead I devised a special vertex shader to handle the sprite animation on the GPU. When an animation is triggered, such as the door is opened or closed, the CPU sends the vertex shader the information it needs to render the door animation, and then the CPU never has to worry about the animation again until a new animation is triggered.
Saturday, May 4, 2013
StarWright Logo
I made a logo for StarWright using the in-game ship editor, mostly just to show off how flexible the ship editor is.
Tuesday, April 23, 2013
StarWright - Better Art
I've been working for a while to revamp most of the ship art in StarWright. While I'm certainly no great artist, or even a good one, this new art is definitely much better than before, primarily because it gives the sense that you're looking into a cross-section of a ship as the people run around inside. This was a feeling that was missing from the old art, and the game is much better for having that feeling.
A key part of the new art is having clearly visible walls that separate the various rooms. There are no doors yet, but when crew walk from room to room they walk underneath the walls, which gives a much better sense that they're inside the ship.
The new art is not just aesthetic, though. It serves some practical purposes too. The lighting color lets you know at-a-glance what kinds of systems you're looking at, even when zoomed out (red for weapons, orange for thrusters, tan for hallways and crew). The presence or not of colored lighting also indicates whether that room is operational (a dark gray cannon tells you that it doesn't have any crew operating it). And the number of ammo bullets loaded into a cannon tells you how many bullets that cannon needs to fire.
A key part of the new art is having clearly visible walls that separate the various rooms. There are no doors yet, but when crew walk from room to room they walk underneath the walls, which gives a much better sense that they're inside the ship.
The new art is not just aesthetic, though. It serves some practical purposes too. The lighting color lets you know at-a-glance what kinds of systems you're looking at, even when zoomed out (red for weapons, orange for thrusters, tan for hallways and crew). The presence or not of colored lighting also indicates whether that room is operational (a dark gray cannon tells you that it doesn't have any crew operating it). And the number of ammo bullets loaded into a cannon tells you how many bullets that cannon needs to fire.
Thursday, April 18, 2013
Garbage Collection
Programmers who are opposed to garbage collection because manual memory management is easy completely miss the point of GC.
Regardless of whether manual memory management is easy (if you're experienced then it's mostly routine), the greatest strength of GC is not that it makes memory management a bit easier (true in most cases, but non-deterministic deallocation can occasionally complicate things), or even that it's safer and more secure (almost always true), but that it eliminates the need to track which object is responsible for deallocating another object, thus greatly simplifying program structure, increasing brevity of code, and enabling a handful of language features like closures, asynchronous methods, LINQ (C#), etc... that would be much more awkward if not impossible to use.
In short, GC enables programming languages to be more expressive and concise, and the code written in them to be cleaner and simpler, thus greatly improving flexibility, understandability, and maintainability of code. Whether that's worth the tradeoff of reduced performance and occasional added complexity is a matter of application domain and personal preference.
Sunday, February 24, 2013
StarWright - Micro Commands
"Micro commands" are special commands for power players that allow players to micromanage the behavior of their ship's crew and systems. The only current use for micro commands is to command your ship's weapons to focus-fire on a specific part of an enemy ship.
A micro command to focus-fire on an enemy ship's part is issued by holding the alt key and right-clicking on the enemy part. Additional micro commands can be queued up by holding shift in addition to alt while right-clicking.
A micro command to focus-fire on an enemy ship's part is issued by holding the alt key and right-clicking on the enemy part. Additional micro commands can be queued up by holding shift in addition to alt while right-clicking.
Monday, February 18, 2013
StarWright - Better Commands
Players have for a while now been able to give both move commands and attack commands to ships, but until now haven't been able to queue up multiple commands or tweak commands already-given. These two new features really help make commands more flexible and useful.
Queuing up multiple commands to be executed in sequence is easy. Simply give the first command and then hold the shift key while giving each additional command. It looks like this:
Adjusting an already-queued command is also pretty easy. While holding shift, rotator and mover widgets will be displayed. Simply click and drag on one of the four arrows to rotate the ship, or click and drag the center widget to move the ship.
This also of course works for attack commands too. Clicking and dragging the center widget will adjust the distance and direction of attack. Clicking and dragging one of the four arrows allows you to choose what flank your ship will fire from, which was previously not able to be manually set.
Queuing up multiple commands to be executed in sequence is easy. Simply give the first command and then hold the shift key while giving each additional command. It looks like this:
Adjusting an already-queued command is also pretty easy. While holding shift, rotator and mover widgets will be displayed. Simply click and drag on one of the four arrows to rotate the ship, or click and drag the center widget to move the ship.
This also of course works for attack commands too. Clicking and dragging the center widget will adjust the distance and direction of attack. Clicking and dragging one of the four arrows allows you to choose what flank your ship will fire from, which was previously not able to be manually set.
Subscribe to:
Posts (Atom)