Click here to Skip to main content
Click here to Skip to main content

Mars Mission (2) : Explore the Solar System

, 20 Nov 2010
Rate this:
Please Sign up or sign in to vote.
strategy/action game defending the solar system : interplanetary space

    Mars Mission

    In the previous and first article in the series Mars Mission (1): Surface Landing we looked at the collision detection classLandscape being exploited in a form designed for the sole purpose of debugging the landing and take-off phase of this project. This past month I've been busy incorporating the landing stage into a solar-system simulator and have joined the two together so that you can now fly your shuttle anywhere in the solar system. You can no longer bounce around indefinitely like you could when we were just testing the collision detection system but rather have to worry about getting a few bumps and bruises before you suddenly crash and burn all over the virgin Venus vista. That is, only if your ship's hull doesn't get pulverized so severely by the planet's massive atmosphere that you void your voucher and riddle the dust down below with crushed little flaming bits of you and your crew.

    classSprite

    I don't want to talk about the changes I've made to classSprite and its editor. There are lots of improvements which took the better part of the last month and a half to get working right. I admit, I had the solar-system simulator working before publishing the previous article and incorporating the landscape area into it wasn't that much of a challenge. I love controls and a good UI so I took my time about it but mostly I've been bogged down working on Sprite-Editor and its class fixing the problem with the 'mirrors' for this project's landing gear. And that's all working and the class is currently loading ".sp3" files instead of any of the previous versions. The number of images per quarter rotation is variable and can be modified using the editor. They do not load all limb-images at load time but on request which means the classSpriteMaker keeps an array of open file-streams to avoid conflicts and they all cache their output images onto the Hard-Drive using a common set of ternary trees. These cache-files grow(one per working directory) from one session to the next which means your projects need to load the RAM-part of the cache at startup. its a bit complicated and twisted but nowhere near as contorted as the trig-gymnastics I went through trying to get the mirror images of these sprites working before I finally settled on a simple means of doing the complicated and decided that a lesser cost in computation time & smaller memory requirements were a good compromise for the use of a simpler means of doing the same thing. In short, I wracked my headed trying to do it the hard way and then alighted to an easy means to getting it right and ... tada! the sprites are great.

    but i don't want to talk about that, that'll be in the Sprite-Editor upgrade whenever I get around to writing it, maybe next year.

    Installation

    To install Mars Mission onto your computer you'll first have to download the source-code and the accompanying sprite/image files. There are four files in all which you should download in their enumerated order(1, 2, 3 & 4). The first one has the source-code and extracting the files in it will create the directory in which to extract the others. The files numbered 2,3 & 4 should be extracted into the directory which you extracted from the first file where you'll find the project's icon shown below.

    Mars_Mission_-_icon.png

    It should be in the same directory as the "resources" & "properties" directories such that once you've added the sprites and images to the project all these new files (*.sp3, *.bmp & a *.jpg file) will be listed along with the "resource" and "properties" directories. Once these files are on your computer you can spark-up your C#2010 and load up the project.

    Initializing the data

    The first time you run Mars Mission it will have to initialize itself. You don't have to do anything except be patient. Its big. Its slow to initialize because it needs a lot of data at the ready during run-time. So I strongly suggest you compile the project and run the executable the first time you load up the game. The reason for this is because all those bitmaps now need to be rotated N times each. The planets and their satellites are all called "solar-objects" in the code and are each instances of classSolarObject. During runtime these planets and moons rotate about their axes and though the default suggested setting for the number of images per quarter rotation is 16 (the project will prompt you with this value as the suggested setting) to get better results change this to 90. The difference during run-time is huge and the cost is only in the time it takes to set-up the game the first time you load it. Using the executable, as opposed to the debugger, means this is done much faster but it does nevertheless take a couple of hours so you should probably get it going and walk away, go play with your kids or read a glossy magazine with the word 'space' written on the cover because it's going to be a while.  This wouldn't be the case if I could package it all onto a CD-ROM and mail that to you but the size of the generated files are so big that, depending on your internet connection, it could take you longer to download them.

    files_in_directory.PNG

    above you can see an image of the files which took so long to build. The most important file here is the ".soi" file which contains all the "solar-object images". These images are the various rotations of all the solar-objects but not all solar-objects have their own images. I downloaded these images off the internet and some of them are polar-views when I could find them and others aren't. This solar-system simulator is two-dimensional and does not simulate the planetary axial tilt, such as Uranus which rotates at a tilt 97 degrees off from its orbital plane's normal. So the difference in the images of one planet's rotation compared to the next would be much more pronounced if this were not so, instead they all rotate about in circular orbits, at constant angular velocity and rotate about their own axes with a tilt exactly equal to zero which should be good enough for this time around, maybe in ten or twenty years when I decide to rewrite this project I'll consider making it a 3d-first- person shooter... but that's a ways away.

    The SOI file uses indices that redirect the filestream to the location of the image you're looking for. Because these indices are all the same size and because each solar-object has the same number of images to cache, the indices are initialized to the value of -1 and then updated as images are appended to the end of the file.  We cache two images per rotation, one of original color and a second which is set to gray-scale.  Though the image below doesn't show the two the gray-scale image immediately follows the original colored one and has its own index therefore the number of long integer variables that make up the index is equal to

    total indices = (number of solar object) x (number of images per quarter rotation) x 2

    After these have all been generated and set to -1 we start to store the images.  Here's a depiction of you how the file's data is distributed.

    Solar_Object_filestream.png

    The Controls

    main_console.PNG

    In the image above you can see the main console which appears at the top- right of the screen. There are two buttons at the top left of this "names" & "starfield". These control the look of the interplanetary map and allow you to toggle whether or not the star-field backdrop is visible or not and whether the names are displayed on the screen. You can see in the following images the difference between the four setting combinations.

    interplanetary_space_-_no_starfield_-_names.PNG

    no starfield with names of three planets, the sun and your shuttle the "St.John"

    interplanetary_space_-_no_starfield_-_no_names.PNG

    no starfield no names, same image as above without the names

    interplanetary_space_-_starfield_-names.PNG

    starfield with names

    interplanetary_space_-_starfield_-_no_names.PNG

    Starfield without names (the two planets Venus and Mercury are circled for you)

    The "focus" button on the top-most right of the console will allow you to control which planet, ship or base your console will inform you about. This is important when you're trying to land on a distant planet or moon. Let's say you're flying to Mars, you can't just head that way and then expect to get flying-colors when you hit it (if you actually get close to it!) and splash all over its the red-skied crater-filled dust bowls. What you need to do is monitor your speed relative to your target destination. Mars isn't just sitting still and its not enough to just get close to it, you have to approach it at a velocity relative to its own. By using the "focus" button you bring up a tree-view of the entire solar-system branching down from the sun. Every solar -object can potentially have satellites, bases and ships. So you start with the sun, scan down its satellites, find Mars and select it before pressing the "focus" button again and hiding the tree-view back where it was so you can center your energies on flying the shuttle. Just keep an eye on the planet's velocity and remember to start slowing down long before you get there.

    tree_view.PNG

    But let's get back to the more important controls : how to fly your ship. There are a lot of things to do so I'll try to be clear and concise. Your shuttle has three main navigation controls that require the use of the keyboard :

    1. engine strength
    2. vertical dampers
    3. horizontal dampers

    The engine strength lets you control the power your thrusters are exerting. When taking off from Terran One for the first time you'll probably want this set to five but then you'll have to decide how much engine force you want when approaching lesser planets that have weaker gravitational pulls or risk flying farther than you anticipated and losing control. Your dampers help you reduce your speed but are only effective inside the atmosphere (landscape area)  and are essential when flying around in a cave.  Simply put, they are brakes which work in the horizontal and vertical axes and are activated by pressing the "V" and "H" keys on your keyboard. You can lock them by pressing the shift key first and then releasing the damper's control key. The engines are only fired using the left mouse button and force the ship forward in whatever direction it is heading in the same way it did in the previous article's project. To change the strength of these forces you can either use the numeric keys (keeping in mind that your ship's current maximum values for all three of these navigation controls is 5) and combine it with the appropriate keys : V, H or E for the engines.

    It is possible to change these values using the mouse-wheel incombination with the the V, H or E keys.  The dampers are changed by steps of 0.1 whether you're pressing down on the shift-key or not but the Engines jump by whole values without the shift key and by 0.1 with.

    In the main-console image above you can see these values reflected inside the Ship-data groupbox which is the top of the three groupboxes that make up the console. In that same ship-data box you can see the "details" button which will call up a separate form containing more information about your shuttle, the St.John.

    select_pilot.PNG

    In the image above you can see some of the ship's details. Its currently broken down into four different tabs but for the moment only two of them are populated : Navigation and Crew. The navigation tab is shown above and this is where you can decide who will pilot your ship. Its important to pick a good pilot because that will make your shuttle more responsive when you fly. The Crew tab shown below :

    crew_of_shuttle_at_Terran_One.PNG

    displays the crew of your shuttle and though you can reorder them according to their given proficiencies (Piloting, Engineering, Chemistry & Geology) none of these proficiencies are currently meaningful in the game except for the piloting which I mentioned above. In this same image you can see the base Terran One where your ship is docked when the game starts.

    As a final note about the controls I should explain the appearance of the ship on the interplanetary space maps above. See the image below:

    interplanetary_space_-_ship_s_heading.PNG

    you can see the velocities of your ship and the planet Venus highlighted in red on the right above but what you should note most about this image is the blue circle and red and blue lines indicated as the "ship" in the left of the image. The blue circle grows and shrinks with your ship's velocity (relative to the sun), the blue line indicates the direction of that velocity and is in the same direction as the red-arrow in the ship-data's circle-control on the right. The red line is in the direction the ship is heading, its length describes the ship's engine setting and the red color tells you that your thrusters are fired and active, were they idle that line would be green.  Like on the landscape map you can zoom in close enough to actually see your ship but doing this would make it difficult for you to fly because you would no longer see the planets around you though the star-field in the back remains the same. From the data relevant to the planet Venus on the right compared to the ship's data you can tell that the ship is moving away from venus at considerable speed. Likely heading home after a brief excursion into that planet's heady atmosphere.

Landing Gear

Your landing gear should be retracted while you're in the air because it causes drag (and watching the gear go up and away or down and out is really cool!).  To toggle the position of your landing gear use the key "G" on your keyboard.

    Shadows

    The sun is the center of the solar-system which means it would be strange if we were to call it Starbuck Space, but more importantly, the sun sheds its light on every part of its system. no... actually, it doesn't. you know this. you shouldn't allow yourself to be misled like that.  That previous statement was clearly false and you can't let your mind wander or tire too much. But the sun does radiate light outwards in all directions and if you're lucky enough to be on the sunny side of a planet then you'd feel the heat but there's more to Pink Floyd's "Dark Side of the Moon" than a good track to kick back with.

    ramble, babble, idle, sidereal...

    where was I?

    right, ok. the sun sheds light in every direction. but that means it also causes shadows to appear on the back of planets farthest from this light source. To simulate the appearance of a shadow on a planet, night and day, and all that, we have to keep track of the sun's position relative to the planet we're looking at. Then, before putting it onto the screen, decide whether we want to cast a shadow or not (no shadows on the landscape view, more on that below) and when we know we want to put a shadow on the output image we retrieve two images from the SOI file. We retrieve both the shaded image and the originally colored one and use these images along with a third which is handy for all these shady affairs : The Shadow! The shadow is a rotated image of a shadow which is used to mask the gray-scale image before pasting it onto the colored image. All three of these bitmaps have to be rotated before we can cut-em'up and paste it all together which does take some time but since we cache all of them onto the HD its pretty easy to find and retrieve them quick enough for it all to be over relatively painlessly.

    Have a look at the shadow below :

    SO_SolarShadow.png

    Doesn't look like much but there it is. The rounded edge on the right faces angle 0 and though the shadow's image is the same size as all the solar-object images it covers just a bit more than half the solar objects by first making the black center transparent and pasting it onto the rotated gray-scale image, then the resultant 'chopped' gray-scale image is made transparent around the outside and pasted onto the colored image so that this chopped-gray-scale less than complete image is positioned such that it and the colored image match perfectly except for the grayness of it all.

    You can see the results in the images below. First a look at Earth's moon Luna when the sun is above it on the screen :

    approaching_the_moon.PNG

    and here's a view of Venus :

    approaching_venus.PNG

    its difficult to see here but both Venus and the sun have animated atmospheres. Venus's atmosphere is particularly active and to simulate this I used a program I put together to remove the darkest parts of the colored image of venus until only the vein-like streaks were left. Then I cut these up into small segments and used them to create the Atmosphere_Venus_nn.sp3 files you downloaded. These are positioned at randomly distributed locations and grow from a draw-size of zero to max of (1.0 x the game's zoom) and back to zero again when they disappear after having affected their entire configuration. Since each planet first looks on the hard drive to see if any files exist for it before deciding whether or not it needs to animate an atmosphere(it searches the hard- drive only the first time it is put to the screen and then remembers what to do) its simply a matter of creating atmosphere-sprites (using my upgraded Sprite-Editor) and saving them with the correct file-name for the program to find them and animate the atmosphere(I'll get around to making some for the earth and the gas-giants later but its not a priority). The sun's solar-flares are pretty cool but since they protrude outside the original sized image the output image is not correct which is the reason why I'll have to do some further tests flying around the system's central star to weigh the sun's gravitational pull which doesn't live up to Star-Trek's expectations of time travel. I'll have to ask Leonard Nimoy for some help with this!

    Landscape and the light of day

    screen_shot_-_landing_on_the_moon.PNG

    Because we're now a part of the solar system its important to know what time of day it is where you are on the surface. For this reason then we can see the sun rise/set and the sky light up and fade to darkness with the passage of time. The sun's angle relative to the planet and your location on the surface are taken into consideration before the sun is positioned on the sky. Once we know where we are the sun's X location on the landscape is determined and we measure the distance between our current location and the sun to determine how far away from the center of the screen the sun should appear. Once this is determined we plug that value into an equation describing an ellipse with height/width value settings wider and taller than those for moons, and we figure out how far down from the top of the screen the body needs to be drawn for your viewing pleasure.   No shadows or animated atmosphere here since they would probably be too far to see anyway, and I don't think most computers could handle the extra work given that this is where a lot of the fighting is going to happen later.

    Entering/Exiting Landscape

    One of the trickier parts of this project was figuring out what direction your ship should be moving/heading when entering and exiting the landscape stage. The reason for this is because when you're on the landscape up is up and east is on the right with west to the left, but then when you get to the interplanetary view things are a little different. If you look at a polar view of the Earth

    Earth_from_above.png

    You might image that up is up there too but it isn't. Actually, when you exit the atmosphere and enter into the interplanetary space your direction relative to the planet from this perspective is a horizontal mirror, sort-of-speak of the original. The calculations to figure out the angle of the ship and its direction of motion have to be reflected horizontally(horizontal mirror) about the normal of the angle your ship makes with the center of the planet. This is because the upwards direction radiates away from the planet and east, from that point of view, is to the left and west is to the right. Once you get your head around that little bit of trip-wire you'll be fine. but it took me a while so don't feel so bad if you didn't think of it first.

    Reports

    Remember though, Venus is a rough place to go if you're not properly encased in something seriously sturdy. In the image below you can see the results of the Shuttle St.John venturing too far into Venus's atmosphere.

    formReport_-_Ship_crushed_on_Venus.PNG

    The report system is simply a queue of reports made up of the classGraphicText's Panel_GraphicText you may have seen in one of my previous articles like GCide: A Complete English Dictionary where I explain it further. The report form currently has three relevant buttons, two of which appear on the form itself and a third one appears when required above the ship-data on the main console.  Clicking next will display the next report pending in the queue, this button will only appear if there is another report left to show.  And the ok button hides the report but leaves the Q intact.  The third button is in the console above the ship-data and appears when a new report needs your attention.  This way you're not faced with the report-form blocking your view while you're in a fight.

    the new game messagebox is made using bitmap region which I won't go into here

    new_game.PNG

What's next

The first thing I have to do now is implement the game save/load.  Then, before the next article, I'll have the astronauts walking around the ships, landscape, caves, and in/out of buildings where they will perform duties relevant to their proficiencies like pilot the ship, dig up some dirt or process their stuff they dig up.  For this they'll need a resources/action engine which I'll get into when I write about it sometime in the new year.

until then, Ski-doo safe, eh, and you'll be ready for your space-buggy!

Mars Mission (3)

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

About the Author

Christ Kennedy
CEO unemployable
Canada Canada
Christ Kennedy, published his fourth novel "Cleats of the Counter Revolution" in the summer of 2010. He grew up in the suburbs of Montreal and is a bilingual Quebecois with a bachelor’s degree in computer engineering from McGill University and is currently walking across ontario plotting a new novel, far away from any computer.

Comments and Discussions

 
GeneralMy vote of 5 PinmemberKentuckyEnglishman22-Nov-10 2:34 
GeneralRe: My vote of 5 PinmemberChrist Kennedy22-Nov-10 6:29 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Mobile
Web02 | 2.8.140721.1 | Last Updated 20 Nov 2010
Article Copyright 2010 by Christ Kennedy
Everything else Copyright © CodeProject, 1999-2014
Terms of Service
Layout: fixed | fluid