Sounds fun, but I'm a bit biased. I'm actually working on a space game with ships composed of parts too, although quite different in execution.
You might skip over most of your more complex ideas for now and concentrate on getting the core 'building' mechanism (if that really does turn out to be the core!) working in a fun way.
I'd be interested to see how you implement thruster/weapon groups/selection and AI ship control. Those are design areas I've struggled with because they introduce more complexity than I'd like to expose to the player, but I can imagine scenarios where fine-grained control is desirable.
I'm on the fence on Newtonian physics. I always liked Subspace and the subtlety in maneuvering, but the sentiment I usually see is that it takes away too much control and causes frustration (especially in shmups). Having different environments that offer both ways might be a good compromise, but I'd be wary of introducing additional controls that only affect part of the game.
I like the use of ASCII to represent the ship. It's portable, simple, human-editable, and provides a decent visual. I could imagine difficulty if you need to encode more information about a part though. Captain Forever (
http://forums.tigsource.com/index.php?topic=8095.0) also uses this approach.
Here are a few other points that come to mind:
- How will you enter 'build' mode? Does there even need to be a separate mode, or can you always edit your ship?
- Does building take resources or incur some kind of penalty?
- Are individual parts destroyed, or the whole ship as one? If individual parts, what happens when I destroy a part that splits the ship into disjoint sections?
- How is the 'forward' direction defined?
- What constraints will prevent players from creating unbalanced ships in the sense that they have a ton of weapons, armor, or design that makes them overpowering?
Thanks for your post! I'll try to answer some of the points you raised. I apologize in advance that this will probably be a quite long post.
Any activable module, such as weapons and thrusters, can be bound to a key. Several modules can be bound to one key, and one module can be bound to several keys. This is done with ASCII config file, so it's easy to edit/share out of the game. Then, whenever a key is pressed, the game activates all the modules bound to it. I think that's all there is to it, but please explain further if you think this doesn't cut it.
AI ship control I haven't implemented yet, and it seems to be a bit challenging to do in a way that AI doesn't cheat its way over Newtonian restrictions but can still behave effectively.
Newtonianess really is a big controversy for many people. My most basic motivation was that I think there are lots (one could even say "enough") of games that use the dogfight style, so why make yet another one. I do, of course, also think that Newtonian flight is super awesome, and I am happy to say that I think the flight model in this game is extremely fun! As a more deep philosophy I very much like games where the learning curve is long enough, so that after 2 hours it doesn't feel like you are a master of everything already.
However, it is true that in some situations Newtonian flight can be troublesome. In addition to wings and flaps and rudders etc, I might add some flight aid modules.
I have to confess that the ASCII file shown is by itself not enough to represent the ship for exactly the reasons you mentioned. There needs also to be a control scheme file, and a module description file. In theory these could be combined, but at the moment they are separate. Module description file takes care of telling the game which letter is which in-game module, and what are its parameters.
The simplest parameter is the direction. Every engine, for example, can only apply thrust in its direction, and (as of now) the one opposite to it. So, if one wants strafing engines (1234 in the image), they need to be directed differently than the main engines (udlr). Of course, modules are also rotatable if you designate them to be, but this is probably not very useful for maneuvering in combat. I plan to introduce a simple-to-use defaults of both the control scheme and the module definitions for players who want to finish their ships without much extra labor.
The building mode question is still open, so I'm skipping it. If I had to say something right now, I'd probably go for Minecraft-style where the player can manufacture a "dry dock" block which then will be able to manufacture a ship whose blueprint it is somehow given. Building may also take time, so for larger projects you may want to have more dock-blocks or more effective ones.
Building does also take resources, which you can gather from asteroids or acquire from NPCs.
Each block is destroyed separately, which should lead to a nice damage model and increase the importance of block placement in combat vessels. When blocks or sections lose physical contact to each other, they should become individual entities that is no longer affected by the previous entity, but is otherwise functional. In plain English, you can split ships. So, if you have a turret in such a split section and a control console nearby, you could still shoot with the turret (but the section would probably be spinning uncontrollably, unless you also had engines there). This is not yet implemented, though. If I happen to make a more complex wiring and piping mechanic this is all of course subject to change.
There is no special 'forward' direction. Most likely the one people act like is forward is the cockpit's looking direction, but of course there can be multiple cockpits and they may be rotatable. This shouldn't matter, because each module has its own direction that it obeys with no regard to any other module, thus the only way 'forward' ever matters is the players' perception of how the ship will behave.
Constraints are already quite high-level game design, so my thoughts on it are still tentative. The most obvious constraint will be resources. In addition to large ships requiring lots of basic stuff (think tritanium in EVE), special modules such as weapons will likely require more rare ones. You will be able to recycle your old ships to help around this, but expanding will require finding new materials.
Assuming resources aren't a limiting factor, there are two main restricting factors. First is the "functional resources", which means energy, fuel, ammunition, and things like that. I'm not sure if there will actually be a need for any ammo or fuel, but most likely every ship will require a generator of some sort, and the more functional stuff you add, the larger generator you will need. Guns may need some computing power to shoot targets if the player doesn't want to aim manually (a likely scenario in larger ships when there are lots of guns).
This is of course a very unsatisfying answer, because we just assumed that the resources aren't limited, so the player could just always put a large enough reactor in the ship to run everything and a large enough supercomputer to track all the targets in the universe.
A more difficult limit to circumfer is heat, which is something that I really want to add to the game. Each energy-consuming module will produce heat, and every module (also including non-functional ones such as walls) will have a bunch of thermodynamics properties like heat capacity, temperature, and melting point (or a more complex temperature - tensile strength function). If done well, this will naturally limit the amount of functional modules a ship of certain size can easily fit, without being any kind of a hard cap.
The ultimate restricting factor will be physics itself and the fact that the damage is block-based. More stuff you have, the larger the mass and the size of your ship is. Larger ships are easier to hit by enemies, but also are usually slower to turn. Massive ships are slower to accelerate (and decelerate!) than lighter ones, making them vulnerable in certain situations. Gun ports are always structural weakpoints (compared to the surrounding armor), and the same goes for the engines.
Developer
