pokerentrancement

• Spaceship Creator Games
• Spaceship Engine Design

You MUST have 'use new audio engine' ticked under the global game settings for it to work. This gives you access to normal sounds as well as emitters which you can then set sound fall off, velocity, position and set listeners which sounds like what you want to do. If you press F1 to get to the help file and search 'audio' in the index tab you.

1. 1000+ Free Sound Effects, Music Tracks & Loops for. Chances are that you are using Unity game engine and are familiar. Music and sound effects for game.
2. The Soundscape for Science Fiction fans. Star Trek's Enterprise engine noise has been a recurring request. A slight problem delayed its release: our user interface had more sliders than it needed to recreate the sound!

Game-Maker (aka RSD Game-Maker) is an MS-DOS-based suite of game design tools, accompanied by demonstration games, produced between 1991 and 1995 by the Amherst, New Hampshire based Recreational Software Designs and sold through direct mail in the US by KD Software.^[1] Game-Maker also was sold under various names by licensed distributors in the UK, Korea, and other territories including Captain GameMaker (Screen Entertainment, UK) and Create Your Own Games With GameMaker! (Microforum, Canada).^[2] Game-Maker is notable as one of the first complete game design packages for DOS-based PCs, for its fully mouse-driven graphical interface, and for its early support for VGA graphics, Sound Blaster sound, and full-screen four-way scrolling.^[3]

Primary distribution for Game-Maker was through advertisements in the back of PC and game magazines such as Computer Gaming World^[4] and VideoGames & Computer Entertainment. At release Game-Maker was priced at $89, and shipped on 5.25' diskette with seven or eight demonstration or tutorial games. Later releases were less expensive, and shipped on CD-ROM with dozens of sample games and a large selection of extra tools and resources.^[5]

After some consultation with the user base, on July 12, 2014 original coder Andy Stone released the Game-Maker 3.0 source code on GitHub, under the MIT license.^[6]

• 1Construction
• 2History
• 3Game distribution
• 4Limitations
• 5Influence

Construction[edit]

Game-Maker consists of a text-mode wrapper, tying together a collection of WYSIWYG design tools. The tools produce proprietary resources that are compiled together and parsed with RSD's custom XFERPLAY game engine. The design tools include:

• Palette Designer - for designing and editing custom 256-color .PAL palette files (for sprites, color #255 is clear)
• Block Designer - for designing 20x20 pixel .BBL background tiles and .CBL/.MBL animation frames for characters and monsters
• Character Maker - for animating and sequencing .CHR character sprites
• Monster Maker - for animating and sequencing .MON 'monster' (i.e., non-player) sprites
• Map Maker - for designing 100x100 tile .MAP files (10 screens tall; 6-1/4 screens across)
• Graphics Image Reader - for importing visuals from .GIF files, produced with external painting programs
• Sound Designer - for designing PC speaker .SND files, assigning Sound Blaster .VOC samples, and formatting .CMF music files
• Integrator - for compiling and organizing resources together into a playable .GAM file

Game-Maker involves no scripting language; all design tools use a mouse-driven 320x200 VGA display, with a shared logic and visual theme. Users draw background tiles pixel by pixel in an enlarged window, and can pull tiles from the palette to arrange in a 'sandbox' area. A further menu allows users to set physical properties—solidity, gravity, animation, various counter values—for each block. The user draws maps by pulling blocks from the palette and painting with them using simple paintbrush, line, shape, and fill tools.

Characters can have up to 15 keyboard commands, plus idle, death, and injury animations. They can hold an inventory and money, earn score, gain and lose hit points and lives, and track several counters—often used for keys and similar functions. Monsters have simple animations and movements, and can also change behavior in response to the player.

Playable games can be exported complete with a portable version of the XFERPLAY engine, sound drivers, and configuration files. All games record high scores and (in later versions) attract mode replays. All games also feature instant save and load, and support standard PC joysticks.

In later versions of the software, games also can incorporate several formats including ASCII text data, CompuServe .GIF files, and Autodesk Animator .FLI animations into multimedia presentations during menus and between levels. Although Game-Maker includes no tools for developing these files, the formats are standardized enough to allow the user a choice of standalone utilities. In addition, image data produced with outside programs such as Deluxe Paint is easily imported and split into background tiles or sprites.

Game engine[edit]

Through RSD's proprietary XFERPLAY engine, all Game-Maker games run in 256-color full-screen VGA, at an eccentric 312x196 resolution (switching to the more standard 320x200 for menu screens). Game-Maker games are also distinguished by their eccentric 20x20 tile and sprite size (as opposed to the more standard 8x8 or 16/16 dimensions), populating a standard 100x100 tile (2000x2000 pixel) map size. Transition between scenes is achieved through a slow fade to or from black.

All games share a common interface, with a menu screen offering six options: Play, Read Instructions, Read Storyline, See Credits, See Highest Scores, and Quit. Pressing F2 brings up an inventory screen, while F5 and F6 bring up save and load screens. Although most of these menus can be customized with .GIF backgrounds, their basic layout, labeling, and content are constant across all games.

All games track player score, and display a high score table upon the game's end (whether through completion or failure). Later versions of Game-Maker allow multimedia sequences between levels, including .GIF images, .FLI animations, and ASCII text files.

The engine allows one player at a time, with the screen automatically scrolling in any of the four cardinal directions when the character comes within 1/3 screen width or height of the screen's edge. All Game-Maker games lack an on-screen display (of hit points, score, lives, etc.), though much of this information can be tracked in the inventory screen.

History[edit]

Game-Maker developed from a series of modification tools for a top-down competitive maze game called Labyrinth,^[7] designed by Andrew Stone in January 1991. Although the engine is different,^[8]Labyrinth shared code and file formats with the later XFERPLAY engine and graphical resources with several later first-party games.

Graphically it was 320x200 8-bit (like Game-Maker). It split the screen in half, putting two players’ top-down views of the maze side-by-side on the screen. [...] Every time someone trod over the grass, it would droop and get a little more brown until after about ten times there was a clearly defined brown path. [...] To make all these subtle grass changes, I needed a block editor. So, BLOCEDIT was born.^[7]

Whereas Labyrinth grew out of Andrew's interest in NetHack and Piers Anthony novels, one of Andrew's first goals was to expand his tools and engine to permit side-scrollingaction-adventure games. 'In fact, making something like Metroid was sort of the bar I set myself for version 1.0. Which is why I added the secret passage features, and gravity, early on.'^[7]

In July 1991^[9] Andrew and his father G. Oliver Stone incorporated Recreational Software Designs to pursue Game-Maker as a business venture—with Oliver as president and Andrew as CEO.^[7] Through Oliver's business acumen RSD made deals with KD Software and GameLynk to distribute Game-Maker and host its online community.^[7] Through 1992-1994 RSD placed a series of full-sized ads (and some smaller sizes) in major computer magazines, and in 1994 they sub-leased a booth at the Consumer Electronics Show in Chicago.^[7]

At the time of Game-Maker's release the software was revolutionary both in concept and technology; although there were earlier game creation systems, Game-Maker was the first general-purpose graphical GCS for the dominant DOS/Windows-based PC. Throughout the design process Andrew was adamant that Game-Maker's tools remain entirely visual, involving absolutely no programming from the end user.^[7] Its engine also supported full-screen four-way VGA scrolling, and later full-screen double buffered redraws, well before these were the standard.^[7]

Several updates followed over the next three years, adding Sound Blaster support, improving the design interface, and refining the game engine—yet many features kept being pushed back. Although his brother Oliver Jr. spent a summer on the project, and wrote the code for the sound and Monster editor, Andrew handled the bulk of the coding and updates — a task that, thanks to the lack of standardized drivers or libraries at that time, became all-encompassing and difficult to maintain.^[7] Over the software's lifetime Andrew found himself so 'waylaid by video driver and [engine] problems' that he was unable to focus as much as he wanted on adding and refining features.^[7]

By the mid-1990s the advent of 3D video cards and the introduction of Windows 95 meant that to keep up with the marketplace Game-Maker would need great changes both in concept and in coding. Furthermore the continued lack of standardization meant a large investment in coding ever more complicated drivers and libraries—work that would be thrown away as soon as standards were established.^[7] Despite plans for a radical professional-quality update, RSD ceased support for Game-Maker around 1995.

In a 2011 interview Andrew mused about Game-Maker, stating that by his own principles he was surprised he hadn't released the source code years earlier.

Yeah, you know I should have OSSed a long time ago as I am a proponent of open source. At first there was the possibility that I might jump back into it. And later the fear that whatever startup company I worked for at the time would try to claim it. But upon mature reflection I think that is impossible.^[7]

Later, on July 1, 2014, Andrew posted to the Game-Maker Facebook page, asking for community input on releasing the code.^[10] On July 12 he posted the Game-Maker 3.0 source to GitHub, under the MIT license,^[6] suggesting that although people were free to use the code how they liked, 'if there is interest in preserving the old games you guys made then porting Game-Maker to modern OSes is the first step.'^[10]

Release history[edit]

• Game-Maker 1.0: Includes one 1.44 MB microfloppy disk containing the full set of RSD tools plus the games Sample, Terrain, Houses, Animation, Pipemare, Nebula, and Penguin Pete. Also included, beginning in version 1.04, is a separate diskette containing the GameLynk game Barracuda: Secret Mission 1. All 1.X iterations of Game-Maker include a square-bound 75-page user manual and several leaflets about the use of the software. Later versions (1.04, 1.05) also include leaflets explaining recent changes and updating the user manual.
• Game-Maker 2.0: Includes both 1.2 MB floppy and 1.44 MB microfloppy disks containing the full set of RSD tools plus the games Tutor (a replacement for Animation), Sample, Terrain, Houses, Pipemare, Nebula, and Penguin Pete. Both versions 2.0 and 2.02 include a square-bound 94-page user manual and several leaflets about the use of the software. The latter version also includes a leaflet explaining recent changes and updating the user manual.
• Game-Maker 3.0, floppy: A three-microfloppy (1.44 MB) package contains the full set of RSD tools, the in-house developed games Tutor, Sample, and Nebula, and three licensed games developed by the independent designer A-J Games: Zark, The Patchwork Heart, and Peach the Lobster. Both packages of version 3.0 include a square-bound 104-page user manual and several leaflets about the use of the software.
• Game-Maker 3.0, CD-ROM: this package includes the contents of the floppy package, plus first-party games Pipemare, Penguin Pete, Houses, and Terrain; A-J Games productions Glubada Pond, Crullo: Adventures of a Donut, Cireneg's Rings, and Linear Volume; two games by Sheldon Chase of KD Software, Woman Warrior and the Outer Limits and Woman Warrior and the Attack from Below; and the GameLynk game Barracuda: Secret Mission 1. In addition, the CD-ROM includes a large collection of images, sounds, music, animations, and gameware elements, and a Shareware directory holding demo versions of fourteen games by various independent designers.
• Create Your Own Games With GameMaker!: In 1995, the Canadian company Microforum rebranded and repackaged the CD-ROM version of Game-Maker 3.0 for release to a worldwide market. This version includes a spiral-bound user manual. The disc contents are the same as the original RSD release.

Game distribution[edit]

During Game-Maker's lifetime, users could distribute their games through the Gamelynk (aka Night Owl, later Frontline) BBS in Kennebunkport, Maine or through the Game-Maker Exchange program — an infrequent mailing to registered users, compiling submitted games to a floppy disc with occasional commentary from RSD president G. Oliver Stone. ^[11] Many user-generated games also wound up on public bulletin boards, and thereby found wide distribution and eventual salvation on shovelware CD-ROMS.^[12]

RSD's initial terms of use were rather restrictive. To quote from a pamphlet titled 'Distributing Your GAME-MAKER Games' and dated May 9, 1993:

Under your Game-Maker license agreement, you may distribute any game you create to up to ten people and your gameware to any number of people. You may not distribute the Game-Maker design tools, but you may include Game-Maker's gameware (picture blocks, monsters, characters, sounds, etc) along with your games or gameware.

Commercial distribution of games is not covered by your license agreement and such distribution requires a commercial distribution license, since games contain valuable software owned by Recreational Software Designs.

The pamphlet goes on to detail standalone games, promotional games, and shareware and BBS distribution. For standalone games (which is to say, games that are meant as an end unto themselves), RSD asks a royalty of $500 for the first 200 games sold or distributed, then a small fee for each subsequent copy. The higher the number, the smaller the fee. For promotional software (distributed as part of a promotional kit), RSD asks $1000 for the first 1000 copies and then smaller fees for every copy up to 25,000. Beyond that, RSD asks no additional charge.

Shareware and BBS distribution is a curious case. Although RSD prohibits free distribution, the license does allow a loophole for shareware so long as the author requests the user to pay a minimum registration or license fee of $5.00, then makes a quarterly payment of 10% of all collected fees. These restrictions were rarely enforced; as a June 15, 1993 pamphlet titled 'Distributing Games' suggests, freeware games were common and tolerated despite the license agreement:

To distribute a game via Shareware, simply place a text file statement along with your files letting the user know your terms. You can find example statements in any Shareware product. For Freeware, include a statement that says that you own the product but will allow others to distribute it freely, or even that users can incorporate your work into their games.

Open format[edit]

Despite the limitations on distribution, Game-Maker's design format is notoriously open. From its outset Game-Maker was designed as a collaborative tool, with the intent that users not only trade design tips but pick apart and freely sample from each other's work. A series of full-page magazine ads, run in the early 1990s, spends nearly as many words selling Game-Maker as a modification tool, along the lines of Galoob's Game Genie accessory, as it does describing the software's design features, promising that users can 'modify and enhance Game-Maker games'.^[4] 'Is a game too easy? Increase the speed. Too boring? Add danger, sounds and monsters. Too plain? Dress up the graphics, add animation. Too short? Add new levels.'^[4]

This 'remix' philosophy stems partly from the Stones' own collaborative family dynamic,^[7] and — as with the insistence on an entirely visual, code-free interface — partly from concern about overwhelming the end user. '[W]e realized that it would be pretty hard for a ten to twelve-year-old to do it all himself so there were practical considerations.'^[7]

To that end Game-Maker games are distributed as an unprotected bundle of resource files, both specialized (i.e., Game-Maker's unique graphic and animation formats) and common (including CompuServe .GIF, Creative .VOC, Autodesk .FLI, and ASCII text files^[12]), making it a simple task to identify and edit most Game-Maker games. The decision was a defiant one on the part of programmer G. Andrew Stone, who argued that any user concerned about protecting, rather than sharing, his work should take on that burden himself.

I deliberately (in fact I remember an argument about it) made no effort to protect a game's content -- anyone could load up anyone else's game in the editors. My feeling was that if you were sophisticated enough to build a game that really needed protection, you could wrap it in your own encrypted .zip file or something.^[2]

As it happens, one of the earliest games distributed with Game-Maker was GameLynk's Barracuda: Secret Mission 1, a user-derived project that is most distinguished by its presentation whereby its file structure is hidden by LHarc compression and the portable Deluxe Paint Animation player is tacked onto the Game-Maker executable to provide intro and exit animations.^[11]

Limitations[edit]

Through its history several aspects of Game-Maker's engine, design interface, and feature set have experienced scrutiny from its user base.

One of Game-Maker's more notorious qualities is its exclusive use of Creative's proprietary .VOC and .CMF sound and music formats,^[7] and its absence of integrated design tools for those formats (or recommendations as to external tools), leaving users to work out their own solutions — or often not.^[13]

The use of .CMF was a last-minute decision; Andy had been working on a .MOD-style tracker format, but development was indefinitely delayed. As a temporary measure his brother Ollie plugged in code provided by Creative Labs.^[7]

I got waylaid by video driver and XFERPLAY [game engine] problems. The music was going to be completely dropped, but then my brother pulled this free code up and made it work!^[7]

Other common frustrations include a lack of multi-key mapping for character behaviors, such as pressing Z + a directional arrow to jump in the direction pressed (a problem stemming from a lack of standardized keyboard electrical layouts at that time); the extreme simplicity of monster behaviors^[13] (partially due to a desire to eliminate programming from the design tools); a lack of persistent flags for game events ^[8][14] (partially due to memory constraints); and the lack of on-screen displays for health, lives, and other counters^[14] (due to Andrew's emphasis on full-screen rendering^[7]).

I just felt that the full screen greatly increased the game quality. I guess I just hated staring at the action through a fifteen-inch monitor already when playing video games. I mean, try it in real life. Get a big piece of cardboard, cut a fifteen-inch square in it, and then walk around your house with it held at arm’s length for a day.^[7]

Monsters are a particular point of contention. Compared to characters, monsters have only limited interaction with their environments. For instance, monsters are not affected by gravity or other physics—and have no contextual AI to speak of, aside from a limited awareness of the character.^[13] Monsters also lack variable counters, such as hit points.^[14] Instead each monster (including NPCs, character shots, and some kinds of power-up) has a fixed 'power level' between 0 and 255, and a collision between unequal monsters is resolved by destroying the weaker monster. The engine therefore does not lend itself to graduated damage (i.e., sword 1 does twice the damage as sword 2). Rather, collisions are all binary; either a weapon works, or it doesn't.

Workarounds[edit]

For advanced users, many of the engine's limitations have workarounds. One can approximate gravity's effect on a monster by defining a heavy diagonal path; the monster will move horizontally until it reaches a ledge, at which point it will fall until it hits the ground again. Similarly, although monsters lack hit counters, the user can create chains of identical (or successively injured-looking) monsters to approximate the same effect.^[15]

In later years users have found ways to subvert or play along with the system's properties to achieve effects, mechanisms, and even genres unaccounted for in the engine's basic features—including extensive in-engine cutscenes, boss sequences, AM2-style sprite scalers,^[16][17]RPG style battles,^[17][18]parallax scrolling,^[18] shooting galleries, and destructible terrain.^[17][18][19]

Influence[edit]

As one of the first complete game design suites for IBM-based PCs, and the only one devoted to action games during the early '90s Shareware boom, Game-Maker 'anticipated the thriving indie game community we have today with countless game engines, web sites and indie game companies.'^[2] Several of its users went on to later note in indie or commercial game development, such as renowned Seiklus author cly5m,^[20][21]Slender: The Eight Pages designer Mark Hadley, Liight programmer Roland Ludlam,^[22]Warhammer Online background artist Justin Meisse,^[23] and Bionic Commando associate producer James W. Morris.^[14][24]

Some games produced with RSD's tools, such as Jeremy LaMar's Blinky series, have become cult favorites.^[25] Others, like A-J's Quest, Die Blarney!, and Matt Bell's Paper Airplane, reached a wide circulation during the 1990s Shareware boom, appearing on many CD compilations. Game-Maker seems also to have made an impression in the Benelux, with references in various academic papers,^[26] coverage in the largest game magazine in the region,^[27] and dissection by the local demoscene.^[28]

Notable games[edit]

• A-J's Quest (A-J Games, 1992) — A widely distributed side-scrolling platformer that was also incorporated into an early slideshow demo of Game-Maker.^[29]
• Barracuda (GameLynk, 1992) — An action simulation game, involving deep sea diving. The shareware episode, distributed on a separate floppy disk with early versions of Game-Maker, incorporates external functions such as LHarc auto-compression and the portable Deluxe Paint Animation player, into the game's presentation.^[11][30]
• Blinky 2 (Jeremy LaMar, 1994) — A top-down action game inspired by The Legend of Zelda: A Link to the Past. Through its distribution on AOL Kids, Blinky 2 and its sequel achieved a small cult status.^[18][25][31]
• Blinky 3 (Jeremy LaMar, 1995) — A side-scrolling platformer featuring multiple characters and a branching level structure. Of the two distributed Blinky games, Blinky 3 has received the bulk of attention.^[18][25]
• Nebula (RSD, 1991) — Game-Maker programmer Andy Stone's Metroid-influenced action-adventure platformer, that was always first to demonstrate any new features to the software.^[32]
• Parsec Man 3D (Mark Hadley, 1994) — A minimalist free-floating/platform shooter by Slender: The Eight Pages designer Mark Hadley, that uses red/cyan anaglyphic 3D glasses to add both atmosphere and functional design. Parsec Man was also distributed on the Game-Maker 3.0 CD-ROM.^[18][33][34]
• Paper Airplane (Matt Bell, 1993) — A side-scrolling strategic action game with puzzle-solving elements; perhaps the most widely distributed Game-Maker game.^[18][35][36]
• Peach the Lobster (A-J Games, 1994) — A Sonic the Hedgehog influenced side-scrolling platformer that was incorporated into a late-era slideshow demo of Game-Maker.^[37]
• Pipemare (RSD, 1991) — G. Oliver Stone's top-down action maze game, which provides much of the iconography for the Game-Maker software and packaging.^[32]
• Sample (RSD, 1991) — Joan Stone's simple 3/4 view adventure game that formed the basis for dozens of user-created games.^[32][38]

References[edit]

1. ^'Game-Maker'. The Personal Computer Museum. Archived from the original on 26 April 2012. Retrieved 9 May 2013.
2. ^ ^abcG. Andrew Stone, 'RSD GameMaker'
3. ^DIYGamer, 'The Original Game-Maker'Archived 1 March 2014 at the Wayback Machine
4. ^ ^abcComputer Gaming World, 'Issue #114 (January 1994), page #209'
5. ^DIYGamer, 'The Game-Maker Archive – Part 14: Laser Light'
6. ^ ^abG. Andrew Stone, 'Recreational Software Design's GameMaker product, released in 1994'
7. ^ ^{abcdefghijklmnopqrs}Gamasutra, 'The Making and Unmaking of a Game-Maker Maker'
8. ^ ^abGamasutra, 'Bonus Time with Andy Stone'
9. ^New Hampshire Department of State, Corporation Filings
10. ^ ^abG. Andrew Stone, 'Facebook Game-Maker page, July 1st 2014.'
11. ^ ^abcDIYGamer, 'The Game-Maker Archive – Part 11: Mark A. Janelle'
12. ^ ^abDIYGamer, 'The Game-Maker Archive — Part 13: The World Wide Haystack'
13. ^ ^abcSylvain Martin, 'My RSD Game-Maker years'
14. ^ ^abcdGamasutra, 'James W. Morris: Learning to Game, Gaming to Learn'
15. ^DIYGamer, 'The Game-Maker Archive: Mike Perrucci'
16. ^Mike Perrucci, 'Invasion of the Blobs II.'
17. ^ ^abcAlan Caudel, 'New Dummy 7 Game!'
18. ^ ^abcdefgGamasutra, 'The Game-Maker Story: Infoboxes'
19. ^A-J Games, 'Builder: Build footholds. Destroy obstacles. Be observant.'
20. ^autofish.net, 'RSD Game-Maker'
21. ^insert credit, 'From Shooter to Shooter: The Rise of cly5m'
22. ^Gamasutra, 'Roland Ludlam on Liight and the Hurdles of Game-Making'
23. ^MobyGames, 'Justin Meisse'
24. ^MobyGames, 'James Morris'
25. ^ ^abcDIYGamer, 'Jeremy LaMar: Doodles, Dawdles, and the Creative Cycle'
26. ^Mike Wiering, 'Clean Game Library'
27. ^'Game-Maker review'. Power Unlimited, March 1994
28. ^Bilou HomeBrew's Blog, 'vgmaps tool for RDS Game-Maker'
29. ^MobyGames, 'A-J's Quest (DOS)'
30. ^MobyGames, 'Barracuda: Secret Mission 1 (DOS)'
31. ^MobyGames, 'Blinky 2 (DOS)'
32. ^ ^abcDIYGamer, 'The Game-Maker Archive: Samples and Demos'
33. ^DIYGamer, 'The Game-Maker Archive: Mark Hadley'
34. ^MobyGames, 'Parsec Man 3D (DOS)'
35. ^DIYGamer, 'The Game-Maker Archive: Matt Bell'
36. ^MobyGames, 'Paper Airplane (DOS)'
37. ^MobyGames, 'Peach the Lobster (DOS)'
38. ^Gamasutra, 'Inside the Mind of Gary Acord'

External links[edit]

• The Game-Maker Archive Wiki

I'm trying to make a top-down spaceship game and I want the movement to somewhat realistic. 360 degrees with inertia, gravity, etc.

My problem is I can make the ship move 360° with inertia with no problem, but what I need to do is impose a limit for how fast the engines can go while not limiting other forces pushing/pulling the ship.

So, if the engines speed is a maximum of 500 and the ship is going 1000 from a gravity well, the ship is not going to go 1500 when it's engines are on, but if is pointing away from the angle is going then it could slow down.

For what it's worth, I'm using Construct, and all I need is the math of it.

Thanks for any help, I'm going bald from trying to figure this out.

5 Answers

Take a page from relative physics, where objects cannot exceed the speed of light:

(See below for my working C++ code snippet and running demo [Windows only].)

1. Set the constant c to the maximum speed an object can reach (the 'speed of light' in your game).
2. If applying a force will increase the speed of the object, divide the acceleration (change in velocity) by the Lorentz factor. The if condition is not realistic in terms of special relativity, but it keeps the ship more 'controllable' at high speeds.
3. Update: Normally, the ship will be hard to maneuver when going at speeds near c because changing direction requires an acceleration that pushes velocity past c (The Lorentz factor will end up scaling acceleration in the new direction to nearly nothing.) To regain maneuverability, use the direction that the velocity vector would have been without Lorentz scaling with the magnitude of the scaled velocity vector.

Explanation:

Definition of Lorentz factor, where v is velocity and c is the speed of light:

This works because the Lorentz factor approaches infinity as velocity increases. Objects would need an infinite amount of force applied to cross the speed of light. At lower velocities, the Lorentz factor is very close to 1, approximating classical Newtonian physics.

Graph of Lorentz factor as velocity increases:

Note: I previously tried to solve a similar problem in my asteroids game by playing with friction settings. I just came up with this solution as I read your question^^

Update: I tried implementing this and found one potential flaw: acceleration in all directions is limited as the speed of light c is approached, including deceleration! (Counter-intuitive, but does this happen with special relativity in the real world?) I guess this algorithm could be modified to account for the directions of the velocity and force vectors...The algorithm has been modified to account for directions of vectors so the ship does not 'lose controllability' at high speeds.

Update: Here is a code snippet from my asteroids game, which uses the Lorentz factor to limit the speed of game objects. It works pretty well!

update:* added downloadable demo (Windows only; build from source code for other platforms) of this algorithm in action. I'm not sure if all the dependencies were included in the zip; please let me know if something's missing. And have fun^^

Well, lets consider the realistic problem first and see why this doesn't work and how we have to differ from it. In space as long as your engines are firing, you will be accelerating. Your speed is only limited by your fuel (and in fact you can accelerate faster once you've spent some fuel because your moving less mass).

To give this model an effective maximum speed, you can consider particles in space slowing you down and causing friction. The faster you go, the more particles you're hitting and the faster you're hitting them, so eventually at some fast enough speed, you will be hitting enough particles the amount of decelerating they do exactly cancels out the amount of accelerating your engine is doing.

This realistic model does NOT sound like what you want. The reason being: You have to introduce friction. This means if you cut your engines, you will automatically start to slow down. You can probably count this as one of the unintended forces you do not want.

This leaves us with reducing the effective force of your engine to 0 upon reaching a certain speed. Now keep in mind if your going max speed in the north direction, you still want force to be able to push you in the east direction, so your engines shouldn't be cut out by raw velocity alone, but instead based on the velocity your going in the direction your engines are pointing.

So, for the math:

You want to do a cross dot product between your engine pointing vector and your velocity vector to get the effective velocity in the direction your engines are pointing. Once you have this velocity, say, 125 mph (with a max speed of 150) you can then scale back the force of your engines is exerting to (150-125)/150*(Force of Engines).

This will drastically change the velocity graph of how long it will take you to accelerate to full speed. As you approach the full speed your engines become less and less powerful. Test this out and see if it is what you want. Another approach is to just say Force of Engines = 0 if the dot product is >=150, otherwise it is full force. This will allow you to accelerate linearly to your max speed, but no further.

Now that I think about it, this model isn't perfect, because you could accelerate to 150 mph in the north direction, and then turn east and accelerate to 150 mph going in that direction for a total of 212 mph in the north east direction, so not a perfect solution.

I really do like Wongsungi's answer (with the Lorentz factor), but I wanted to note that the code can be simplified to have fewer floating-point operations.

Instead of calculating the Lorentz factor (which itself is a reciprocal) and then dividing by it, like this:

simply multiply by the reciprocal of the Lorentz factor, like this:

This eliminates one floating-point operation from the code, and also eliminates the need to clamp b to DBL_MIN (it can now be clamped to 0 because we're not dividing anymore). Why divide by the reciprocal of x when you can just multiply by x?

Additionally, if you can guarantee that the magnitude of v will never exceed c, then you can eliminate the testing of b being less than zero.

Finally, you can eliminate two additional sqrt() operations by using length_squared() instead of length() in the outer if statement:

This may only make a 0.1% difference in speed, but I think the code is simpler this way.

You need to have three variables for your ship, which you update at each physics time step based on the forces that are acting on it. These will be mass, position, and velocity. (note that position and velocity are single numbers but vectors). At each physics time step you update the position based on the velocity, and the velocity based on the acceleration. you calculate the acceleration based on the forces acting on the ship (gravity, friction, engines)

Newton's equation for force is F = M*A We can rearrange that to A = F/M to get Acceleration. Basically you need to figure out how much the ship should accelerate, and in which direction (vector), then add that acceleration to the ship's velocity, and add the ship's velocity to its position.

Here is the code you should execute each physics time step (I hope you can fill in the blanks) please ask if this is not enough detail

Spaceship Creator Games

Your question is difficult for me to understand but it seems like you're not using real physics for this game. Have you considered using real physics equations such as velocity, acceleration, force, etc?

Edit:After your edits, I think I have a better understanding. You are simply keeping track of the current velocity (or something similar) but you don't keep track of the force where that velocity comes from. The ship should not be storing any of that information (other than engine thrust) -- it should come from the environment the ship is in.

For instance, the environment has a gravity vector (directional force) so you would need to take that into account when calculating the directional force provided by the engine.

Your ship should be storing its own engine force, acceleration, and velocity.

Spaceship Engine Design

Not the answer you're looking for? Browse other questions tagged mathphysics or ask your own question.