Best way to make a space game?

Hey,

I've been thinking lately of making a space shooter/exploration game. I've been trying to figure out how to make it in the most efficent way. I guess the easiest would be to make a really large frame but that would be really annoying in the frame editor and i dont think it's the best way.

I'm thinking there has to be somehow to get the world to move around you instead of the player (like an endless runner). E.g. it's easy to make stars or rocks come in from the frame edges, randomizing positions etc but im having a hard time figureing out how to make things move in set positions so you get some what of a reference for movements (e.g. a spacestation should be in the same place).

So, anyone have any ideas they want to share?

I guess you would go with a top-down view / 360 degrees spaceship movement, right?

You would probably need to store those elements (space station, asteroids, planets etc.) positions in some data storage tool,
and then retrieve them while you move, so that when you find "space_station", you create a space station
(you can use "create by name" to furtherly automate the process)

--> you wouldn't actually move: you would update your X,Y positions inside the world,
and parse the database seeking positions of screen edges (being updated relatively to your position)

to optimize performance, you would better work with a grid, say 32x32 (but could be even bigger in a space game),
so that when you move i.e. 32 pixels up, and you parse the first row on top of screen,
you only check for screen width / 32 cells (instead of screen width cells!)

Assuming the world could be theorically "infinite",
there are pros and cons with various database types you could use:

standard array:
pro: arrays are very fast, and intuitive to use for coordinate references
cons: you would need 4 arrays, each one for a different quadrant (think of them as quadrants of a Cartesian plane)
since arrays can't hold negative values, you would trick the three negative X,Y quadrants with three additional arrays.
Also, if your world is not very dense (as space actually is XD) you would "waste" a lot of space in the array, since you would use huge array sizes only to store few elements here and there (>> bigger save file, worse performances on higher sizes)


"string" arrays (associative array, named variable object)
pro: you can save named indices (i.e. x-12y50= space_station), so you can easily save negative positions
you don't "waste space" as you only save the indices you need
cons: these type of arrays are generally much slower than the standard array.
There's no cross-platform solution (but this may not be an issue),
unless you use a standard (hidden) list for the same purpose, and its "find" function
(this is a pretty functional solution I've used for similar tasks in the past!)

Holy crap, you're going to scare him away! :D

Mmm, indeed my explanation may have been not so clear and a bit messy >:)

Though I've seen zip2kx making cool stuff I'm sure he could decrypt what I'm talking about XD

Anyway... just in case, here's a simple example of what I was talking about with the "list" database:

Attachment 21166

move with arrow keys,
counters on top right shows the "sector" your spaceship currently is
sectors are considered 32x32 pixel cells in this example

to populate the space simply drop a sprite in frame,
untick "create at start", apply "physical object group",
rename it to your likings

and then enter these objects in the database-list this way:

x000y000|object_name

x and y positions here refer to "sectors"

there are other things to address (i.e. loading the "first screen" elements,
a better routine for "unloading" than relying on Fusion's "destroy when too far from frame"
you would probably need a level editor to fill your space, etc.)
but this is just a basic template...

(hidden) list objects are very handy,
and surprisingly performant for these kind of jobs

thank you Schrodinger!

My thoughts were going something in that direction too but i couldnt really figure it out all the way. i will definitly sit down and try to make something. Of course your example is pretty much a finished engine already! haha.

Question, would it theoretically be possible to store values in an active objects alt. values? thus making it possible to convert it do different platforms?

If you're doing endless scrolling, in order to make objects show up in the same place every time I'd just use a timer to spawn the object. That's going to be a lot of timer events but if you're not building the entire level by hand that's how you'd have to do it.

u mean a counter that subs/adds values when u move around?

Well, as the game is going, you'd use a timer event like Timer is 10 seconds, spawn ship at XY coordinates outside the frame and have the object scroll towards the player. Using ball movement or whatever you want to get it to scroll to the left (assuming sidescrolling towards the right like Gradius or R-Type).

If you're not doing a shooter in the style of Gradius and R-Type then you can disregard all of this lol.

Quote:

---

Originally Posted by zip2kx

Question, would it theoretically be possible to store values in an active objects alt. values? thus making it possible to convert it do different platforms?

---

The example is cross platform (list object is available on all runtimes, as well as the string tokenizer - which is not mandatory btw)

Anyway, using active objects alt. vals could be done, but depends on how you would build your game
(would you create all your single objects at startup and then cycle through them to find the ones needed in that screen portion?
this would make for lots of unneeded object to load every moment in frame)
assuming you plan doing a "big" exploration game of course, otherwise this couldn't be an issue

Oh wow i missunderstood you then.

i thought it was windows only. This is great, im gonna play around with your example and see what i can do. Thank you!.
That was my first idea, to store X/Y in alt values of objects and then check if those match when the position counters change. But i can see now how that would eat memory if it's a big map.

@shawn yeah i wasnt planning a r-type game, but your system is great for that. Thank you for your help too!