Infinite scrolling all directions

Hey,

I have this idea for a space game but when I actually sit down to write it in Construct I'm drawing a big blank. I've read lots of info on scrolling and have gone through most examples of .caps on the board that scrolled. Here is what I'm trying to do:

I'm trying to make a game similar to an old space game called Solarwinds. The game would always show your X and Y coordinates. You would get missions like "Go to the planet at 500,500" or go talk to the ship at "10000,10000". I need to be able to create objects (planets, aliens, star bases, etc) at certain points. I also need to be able to give the impression that the world is much bigger than a 2000 x 2000 grid.

So some options are to keep the player in the middle of the screen and just scroll the starfield background. However, then the X and Y coordinates wouldn't be updated. To solve that I could increment a "fake" X and Y in global variables, but then how to solve placing objects on the screen at X and Y coordinates. I think collisions and other actions based on X and Y would be a nightmare as well??

I think the option of actually moving the player are a no go because of the size layout....you would eventually run into the end of the layout.

I'm starting to think this infinite scrolling is a bad idea and I should just implement jumpgates or something like that instead. Of course, even with jumpgates I still can't be having the player fly to the "edge of space" all the time. So I guess I still need some way to have infinite scroll even in that case!!

I'd appreciate any ideas!

Enable unbounded scrolling and you can scroll anywhere!

Enable unbounded scrolling and you can scroll anywhere!

If you do this then you will have to place all of your planets, space stations, etc. at runtime (using events to set the X and Y of the objects) rather than placing them in the layout. A bit of extra work, but probably the best solution.

placing tiny objects in a monster layout isn't very comfortable anyway.

You could place objects using an editor (made by yourself) that creates a text file with the data.

Or, you could generate positions randomly.

>>Enable unbounded scrolling and you can scroll anywhere!

If you do this then you will have to place all of your planets, space stations, etc. at runtime

I can't believe I gave up on this before. I tried the unlimited scrolling a day or so ago, but once the ship got off the tilebackground of the starfield, then it looked weird because it was all black. I didn't even think of dynamically generating more starfield. I still think I may not be doing it the best way possible. What I do is check if the ship object is not within a certain distance of overlapping the starfield, and if so I create a new starfield. This ends up overlapping the old starfield. To help deal with this I destroy the starfield when it leaves the screen. I'm getting some choppy behavior sometimes.

Here is the .cap. http://www.mediafire.com/file/3zy1jym2n2r/unlimited_scrolling2.cap

I'm using car behavior, because physics behavior still has 20000 limit. Still I think this might just work out. I'll have to look into making an editor, haven't tried to before.

For the stars, why not just put them on a separate layer that doesn't scroll?

You can use a Tiled Background object for your star field (or a few if you want parallax), and simply set their offset, in effect scrolling the inside of the tile without actually moving it. Of course, the textures will have to be power-of-two in order to use the offset feature.

if you really need physics you could bound the world to the required size, clamping or wrapping as necesary.

If that world is too small, you could use layout zoom and resize everything to a smaller size, thus making the world appear larger (although numerically it won't).

If that's STILL too small, you could generate stuff in grids and spawn them when needed, moving stuff around when boundaries are reached to keep numerical weirdness in check. This would give you a universe the size of your grid size times the maximum grid index, which could go up to 2^32. Very large.

You should also take special care of the physics behavior, it might not like being repositioned (I gotta try that btw).

Have several layers of background.

• bottom, fixed background - usually features that don't ever move as you do, a significant space feature such as galactic core, distant galaxies etc.)
• middle, "slow" layers - scroll slower than the main display - usually large features such as nebulae, dust clouds etc.
• top, "fast" layer - immediate surroundings scroll fast, typically planets and stuff

Ok, I'm sure there is an easy answer but it eludes me...

I decided to go with car behavior for now, I kinda like the controls even though its not "true" space.

I'm dynamically placing objects (like an enemy ship). However, to actually create the object I have to place it somewhere during creation time. The common thing to do (shown in tutorials) is to place it off the layout, but this doesn't help in my case because the ship travels off the layout as well. How to create a sprite and NOT put in statically on the layout during creation time??

A more complex problem. When the player flys over a planet they may have an option to "land" on that planet. This causes the player to move to another layout just for that planet. However, when the player decides to "takeoff" and return to the space layout, everything is back to the way it was during game start. Is there a way to keep state between layouts? So the player's ship will be over the planet when you return to the layout?

Ok, I'm sure there is an easy answer but it eludes me...

I'm dynamically placing objects (like an enemy ship). However, to actually create the object I have to place it somewhere during creation time. The common thing to do (shown in tutorials) is to place it off the layout, but this doesn't help in my case because the ship travels off the layout as well. How to create a sprite and NOT put in statically on the layout during creation time??

I have wondered this myself. It seems very peculiar that we have to actually place the object (for example a sprite) somewhere on the layout (even if off to the side) to use it.

Tick the 'Destroy on Startup' checkbox under the Attributes section for the object.

You can still reference the object at runtime and it won't create it

It's not so strange, really. MMF does it. It has to exist somewhere. If you don't want it there when the level starts, just check "Destroy on Startup."

I'm dynamically placing objects (like an enemy ship). However, to actually create the object I have to place it somewhere during creation time. The common thing to do (shown in tutorials) is to place it off the layout, but this doesn't help in my case because the ship travels off the layout as well. How to create a sprite and NOT put in statically on the layout during creation time??

Why not have a loading sequence at the start of layout that places all of your objects before they have a chance to be seen?

However, when the player decides to "takeoff" and return to the space layout, everything is back to the way it was during game start. Is there a way to keep state between layouts? So the player's ship will be over the planet when you return to the layout?

Use a global variable for the ship's position when it enters a planet layout, and set the ship to that position again when the ship returns to the space layout.

It's not so strange, really. MMF does it.

Yeah, but if MMF does it, it doesn't mean Construct should do it. Why an object should be placed in a layout, when user doesn't want to place it in a layout?

It has to exist somewhere. If you don't want it there when the level starts, just check "Destroy on Startup."

There are non-layout objects too, which don't get placed in the layout. I think that if there's an object type you want to later use in your layout, there shouldn't be need to have an instance of it. There is no such a need even in programming languages - object classes and object types are totally separate.

Also, if you delete the last instance of an object, the object type disappears too. I think that object types should be like Plato's ideas, they should exist in their "own world", in some kind of object bank, and then you could make instances of them in layouts.

As far as I know, the object always exists even if there are no instances of it. By adding them to the layout - even non-layout objects - you DECLARE them, so the runtime can use it. C++ and other programming languages are full of such declarations, so object type exists within runtime. You can create and destroy them within runtime as you see fit; if you remove them within edit time, they're gone for good.

Some stuff...

Don't get me wrong, I agree with what you're saying. An object bank would be nice. But the current system is so entrenched in the foundation of Construct that it's not likely to change.

I would guess the only way to do this would be if the devs completely rewrote Construct's engine and IDE from the ground up, and it's a little late in the game to do that. It might be something to consider for C2 though... hint hint