10 September 2020

ShipBasher Development Log 8: Vision

I figure it's about time I shared a detailed description of exactly what game I'm trying to make here. In short, ShipBasher is a real-time 3D sandbox, simulation, and strategy game about building custom spacecraft out of premade pieces (known as kitbashing, hence the name) and pitting them in battle against one another. I'll expound on each of these facets here in their own sections.

Main Menu 

The intended gameplay experience starts, as most games do, with the main menu. Originally this was a generic list of buttons to enter different environments in the game (i.e. settings page, credits, campaign mode, ship editor) but then I decided to take a bit of inspiration from Spore and have a big 3D galaxy occupying most of the screen, as I have mocked up here:

This is itself a menu in that each little circle represents a playable level. Part of each level's data file will be a position in the galaxy at which it appears. As I intend to allow players to create their own levels and place no limits on how many a player can have, it will be possible to fly the camera through this galaxy to explore different areas of it up close.

By selecting any of these circles, the player can open a preview of the level, which takes the form of a "wormhole" showing the level's background features and a window detailing properties such as the level's name and description.

Playing a Level 

Once a level is selected, or a fresh new one is created using the buttons on the side, it can then be played or edited. There will be separate UIs for playing a level and for editing it. This is a mockup of the play mode UI:

While playing a level, the player can select one or more ships to control. I plan to make it possible to restrict which ships are available for a player to control and which are "enemy" or "NPC" ships. For now clicking any module on a ship will select that module and the ship to which it is attached, and as seen here that module will be highlighted and the ship will have a ring drawn around it.

While a ship is being controlled, a menu will be visible (in this mockup it is at lower right) for issuing commands that affect that ship, such as initiating self destruct. Right-clicking a module on any other ship will open a menu (seen at upper left) for interactions between the selected ship and that other ship, such as attacking it.
The camera can be focused on any ship and rotated around it, but to keep track of objects not in the current field of view, there is a radar display at lower left with a slider to adjust its range.
Each ship may have a small readout next to it showing its current status.

Finally, a few large objects are visible in the background. The distant star and planet are visual effects only and won't affect gameplay, but the asteroid on the right is a physical obstacle players will need to accommodate. I may add levels in which asteroids need to be destroyed, or in which special environmental hazards from distant objects affect ships in the level - for example a pulsar that would damage ships with its radiation. These concepts have yet to be figured out in much detail for now.

Planned but not shown are options for pausing the level or returning to the main menu.

Editing a Level 

Instead of playing a level, the player can open a level for editing, or, in certain circumstances, the player can pause a level in progress and edit it. Editing a level involves a different UI:

As in play mode, any ship and any module can be selected. Different windows exist for editing these or for editing the level itself.

At lower left is a window for editing the properties of the level, such as its name, description, and location in the galaxy. Changing the level's location in the galaxy will alter the appearance of the background starfield, so that a level near the galactic core, for example, will be surrounded with a dense field of yellowish stars. Additional information may be shown such as how many total ships exist and a difficulty rating, which will likely be left to the players to determine but might be possible to calculate.
At upper left are buttons for adding objects to the level, e.g. ships, distant background objects such as stars or planets, or physical hazards such as asteroids. Clicking the button to add a ship will reveal options to either create a new ship (not shown in this image) or open a saved ship from a file and spawn it in front of the camera.
Once a ship exists in the level, it can be moved and rotated, and a window becomes visible for editing properties such as its name and description (seen here at lower center). Additional information such as its total mass and firepower is also intended to appear here. At the top of the ship editing window are buttons for tasks such as copying or removing a ship or for saving it to a file.

Any ship will need at least one module attached for it to function. Visible at lower right is a menu for adding modules to ships. When the player hovers over a module in this menu, a preview window appears, allowing the player to examine the properties of the module before loading it. Once a module has been attached, it can be moved and rotated using transform handles, as shown surrounding the module in space, and a window appears, shown here in the upper right, allowing properties such as its name and description to be edited. I may make it possible to restrict editing of certain properties in certain contexts, for example allowing the armor and damage power of a weapon to be changed but not the price (rather the price would be calculated based on how powerful the module is made via other edits). At the top of the module editing window is a set of buttons for tasks such as copying or removing modules or saving a customized module to a file.
At this time it is not planned to allow the scale of modules to be altered or for any custom 3D modeling or texturing to occur in the game.

Finally, at upper right are buttons for saving the current level, playing it, or returning to the main menu.

Other Features 

As seen here, ShipBasher uses a 3D environment with a third-person camera. Every object in the game is able to move in three dimensions, not restricted to a ground plane, grid, or global axes. The camera can be rotated omnidirectionally so that there is no universal "up" or "down" direction, as is the case in outer space in real life.

ShipBasher simulates in real-time, i.e. gameplay is not based on turns. It will be possible to pause the game, but time dilation, either to slow it down or speed it up, is not planned.

Being a sandbox and simulation game, ShipBasher has no central storyline, goals, or sequence of levels through which the player must progress. I intend to include a number of example ships and levels, and I may decide later to make it possible to restrict some levels until after other levels have been completed, but this is not planned at the moment.

A strategy element arises in how players will go about clearing each level that exists - which ships to include (if the option is available), what orders to give them, etc.

Players will be able, as described above, to create their own ships and levels, save these in files, and share them with other players. I have no plans to make this a multiplayer game, include any online functionality, or set up any hosting servers, so it will be up to individual players to send files to each other and import them into their own games.

Hopefully this clears up any mysteries surrounding what my goals for this game are. I'll be glad to address any questions I haven't answered so far.

No comments:

Post a Comment

Sorry this isn't a real post :C

I've entered graduate school and, as I expected, suddenly become far busier than I had been before, leaving no time to maintain my blog,...