Development:Base Backgrounds

Development

---

Introduction

This page summarizes concepts and approaches recommended to add base or planet backgrounds to Vega Strike.

Development Needs and Tasks

We could always use more backgrounds. Ideally, each planet and base in Vega Strike would have a unique background.

Please head over here for a list of open tasks: Development:2D_Images#Base_Backgrounds

Docking Backgrounds

Texture Requirements

Generic Image Requirements

Please read this Development:Graphics_Requirements page before continuing to the specific requirements.

Specific Image Requirements

That leaves few options:

• 1024x1024
• 2048x2048

Keeping original high resolution image (e.g. 8192x or 4096x) versions in stock helps maintaining quality and scalability as game development progresses or typical screen resolutions rise in the future with better hardware available to the players.

Creating and Naming

Comments by MamiyaOtaru in Forums

First off, the bases are not full screen due to the config file, not the sprite file. Change that first to have fullscreen bases. So, the explanation:

In the coordinate system, 0,0 is at the center not the top left. The coordinate system is cartesian, left to right is -1 to 1 x, top to bottom is 1 to -1 y.

Width 2 means the width of the screen (two halves, from -1 to 1) and height 2 means the height of the screen.

In your example, the image is meant to take up 3.104/2 screen widths and 2.4832/2 screen heights. This is because the actual used part of the image (320x200) is approx 512*(2/3.2) x 256*(2/2.5). 3.104 and 2.4832 stretch the image beyond fullscreen, so that the part of the image that actually has something in it (which is only 320x200) will take up fullscreen.

The next two numbers are where the image is centered. Often, those two numbers are actually stored elsewhere. In cockpits, they are stored in the .cpt file and only the dimensions are actually in the .spr file. Here, the X and Y coordinates for the center of the image are in /bases/*.py. Your example is in /bases/pleasure_land.py

Your example is therefore actually 3.104 2.4832 width and height and 0.582 -0.2716 centerX and centerY

The center of the image is thus a little more than half the distance from the center of the screen to the right hand side of the screen. This serves to place the center of the area that has actual content at the center of the screen. The center is a bit more than a quarter of the way from the center to the bottom of the screen for the same reason.

If you use an image that fills up the whole bitmap, without empty space like the priv remake backgrounds, to go fullscreen you would use something like this 2 2 (2 half widths and half heights, from -1, -1 to 1, 1) 0 0 (centered in the center of the screen)

Oh, and pleasure_land.py is also where the animations are linked, if you'd like to remove them for a different background. The animations are the water and the building lights: Jolson_LandingBay_wtr and Jolson_LandingBay_blt respectively. Remove their lines.

Python Scripts

You will need to create the appropriate python scripts to be placed in the bases directory.

Each planet has a script labeled according to its texture name (i.e. texturename_day.py, texturename_night.py, texturename_sunset.py, etc.) What this means is that each planet you want specific control over will require its own texture. Not too big a task (as I assume the number of planets for which this control is needed is not major), as you can almost just copy and paste the old python files for the planet type, but you will also need to edit units.csv to add that planet type. This is easy if you know what you're doing, but obviously is not a long term solution to such a problem. (If anyone knows of a better way that we can do this, let me know!)

Each unit type has a script labeled according to its unit and faction name (unitname_factionname.py, or ignoring factions unitname.py). Here the trick will be to create a python file that checks the name of the unit you are docked to to see if it's the campaign one. If it is then do something special, else do the same as every other unit.

Basically, these scripts are simply run when the player docks. We can't force a different script to load at will, only make sure that the script VS looks for contains what we want it to. However, it might be useful in future to change this...

Room definition

room1 = Base.Room ('Aera Planet')
Base.Texture (room1, 'tex', 'bases/generic/aera_planet.spr', 0, 0)

In the first line, you assign the room object type to your script variable giving the unique argument, the name that will be visible on the in-game interface. The second line defines the texture image sprite for the base background with the argument list roomvariable, linkname, spriteaddress, centerx, centery.

Ship placement

Base.Ship (room1, 'ship', (-0.3, -0.3, 6), (0, 0.93, -0.34), (-1, 0, 0))

The above code defines the placement for the cargo computer with the following convention: Base.Ship (roomvariable, linkname, vectorP, vectorR, vectorQ)

where:

• roomvariable - the room in which you place the button
• linkname - arbitrary name to make your code readable
• vectorP - position of the ship with (centerx, centerx, scale)
• vectorR - ship up orientation with up-vector coordinates (x, y, z)
• vectorQ - ship nose orientation with forward-vector coordinates (x, y, z)

Button definition

Base.Comp (room1, 'CargoComputer', 0.289063, -0.283854, 0.146484, 0.179688, 'Cargo Computer', 'Cargo')
Base.Link (room1, 'goto_exterior', 0.3, -0.3, 0.5, 0.3, 'Planet Exterior', room2)

The above code defines the button for the cargo computer and a link button to an exterior background image with the following convention: Base.Object (roomvariable, linkname, leftx, bottomy, width, height, displaytext, linkobject )

where:

• roomvariable - the room in which you place the button
• linkname - arbitrary name to make your code readable
• leftx, bottomy - button left bottom corner coordinates; ranging from -1 on the left to 1 on the right, -1 on bottom 1 on the top
• width, height - button size; full screen size is 2, half screen is 1.
• displaytext - the text that will be shown in game
• linkobject - the variable name of the object in your python script or a name predefined in the engine

In addition, for Base.Comp, the linkobject is used to determine the services available at that particular computer:

• Cargo
• Missions
• News
• Info
• Upgrade
• ShipDealer

Including and Testing

You'll need to create a sprite file referencing the image. See more information on how to do this in HowTo:Edit HUDs

Selection and Vetting

Some Thoughts

Once you have chosen a replacement candidate and have one or more proposals...

The Process

If you are not sure that your texture meets the basic requirements, then please open a forum topic posting your textures. Please verify the summary of requirements above.

If a texture that you have created meets the texture requirements, then:

• Open a poll for a reasonable period of time (e.g. 2 weeks) and describe:
  • which texture(s) you'd like to replace
  • display your candidates
  • briefly describe the method of creation and tools used
  • If you'd like to replace more than one texture, describe how you would assign the favorites of the poll to the individual textures

• After a set period of time
  • announce the winners
  • and call the poll closed

• Then
  • Submit the textures to svn (in case you have commit rights attributed), or
  • through the forum ask a developer with write access to submit them (e.g. the maintainer of this page, pyramid).

Submission

AKA: Committing to SVN.

References

Software, Tools

For a comprehensive list of tools, please see:

• Links:Graphic Applications
• Links:3D Applications

See Also

• See the following Forums [1], [2]
• How to change the base art in a planet
• Example Scripts

Author: pyramid