Stage construction

[Rozyrg]

Basically, what is your approach to building levels?

For backgrounds, do you use "one big image" or smaller elements you can freely interchange and repeat as necessary? Should an attractive looking and well constructed background come first and should enemies be placed afterwards or vice versa?

So far, all of my projects have used admittedly boring, repeating backgrounds there only as more-or-less just a visual stand-in and honestly, it's starting to feel like a crutch. I want to do more interesting ones; but I'm curious how other people have approached the problems involved... specifically things like the large image/background memory snafu with Game Maker.

And as far as enemy placement goes, would you go for a set, -they always appear here - approach, or something more flexible? Also, how would you handle that with a more intricate background? I mean common stuff like little roads and alleys for ground vehicles.

(I love making tanks; but it's not always easy to keep those buggers from going somewhere they shouldn't.)

Just from playing the games people have made and posted here, I know there's probably quite a few different takes on this subject. I'm interested in any input yall can give me.

[Udderdude]

Big backgrounds can work but they require a lot more detail. Smaller elements only works if you're trying to make it look really tile-based.

A level editor helps a lot if you're trying to do paths for enemies. Doing it manually is a pain.

As for Gamemaker sucking, not much you can do there but move on from Gamemaker ..

[monkeyman]

Backgrounds are a pain with GM.

You could go tile based for details, but as far as i can tell, you can't move the tiles so you'll have to cope with the hastle of having everything lined up with a moving view.
Other than that, I suppose you could have each 'tile' as an object but i can't see that being good for memory.

Best I managed was to take advantage of the fact you can have many BGs and have looping BGs abount the size of the screen, and simply start the one a layer above scrolling at set points in the stage so you at least get some variation. You can also use the occasional object as a background detail. (this is what I did for Proj Raiden which is the only game I've attempted with anything approaching interesting BGs anyway).

From a design point I'd say interesting enemy placement and bland backgrounds is better than stunning backgrounds and bland enemy placement.

[genecyst]

i usually create a big image, than i divide it into tiles.
then i charge in memory my onscreen map + 1row of tiles in the direction i'm scrolling.
when the first row of the screen is out of the bounds i recharge in memory tiles and map as in a fifo.
this way works well on gba and ds development. i don't know at all how it should be in gm.

[Sasupoika]

I am planning to construct stages from tiles size of 1024x1024.
Call me crazy, but if it works, it might be pretty cool.

[alastair jack]

I am planning to construct stages from tiles size of 1024x1024.

If you have a lot of images that size, peoples graphic cards won't be too happy.

[worstplayer]

Such image should take 4MB of video memory, so you can fit 64 (minus space taken by sprites, minus framebuffer) into an average GPU. Not bad if you just cut tiles out of them, but if you want to simply put them one after another, better have a way to unload ones you already passed.

[genecyst]

I am planning to construct stages from tiles size of 1024x1024.
Call me crazy, but if it works, it might be pretty cool.

why do you try this? i can't understand what you'll gain using this sort of tile map.

[Rozyrg]

Big backgrounds can work but they require a lot more detail. Smaller elements only works if you're trying to make it look really tile-based.

A level editor helps a lot if you're trying to do paths for enemies. Doing it manually is a pain.

Definitely. I'm ok with a tiled look, since that's decently representative of the era I'm trying to nail. I can't play anything 8/16-bit without catching myself looking for where stuff is mirrored/tiled anyways.

Would you say it's common to use level-dependent paths for enemies vs. type-specific behavior for movement? What I tried was to give them ways to react to certain obstacles (other ground enemies or decorative objects); but the movement code I have is messy enough as it is. A pain, indeed.

@ monkeyman

I was curious about using tiles... it seems like a pretty popular approach among the GM crowd. I'm not surprised to hear it has it's disadvantages when it comes to backgrounds, though.

And yeah, backgrounds are definitely a pain with GM...lol. I hate drawing them; but I hate coding them even more. >_>

What you described with having individual objects for details is kinda what I've settled on at the moment. It's much easier that way now that I've ditched the old timeline method I had been using.

[Suslik]

For backgrounds, do you use "one big image" or smaller elements you can freely interchange and repeat as necessary?

Interesting question. I have thought about this.... not sure what exactly i am going to do yet, but i think in my case smaller elements is the right choice.

Should an attractive looking and well constructed background come first and should enemies be placed afterwards or vice versa?

I am doing enemys first then background. This could be a big mistake though >.<

And as far as enemy placement goes, would you go for a set, -they always appear here - approach, or something more flexible?

My game has a combination of both. In my opinion bullet hell game makers should be very careful with adding any kind of randomness to the game. It works well in some places, but could be devastating in others.

[wondersonic]

And as far as enemy placement goes, would you go for a set, -they always appear here - approach, or something more flexible?

My game has a combination of both. In my opinion bullet hell game makers should be very careful with adding any kind of randomness to the game. It works well in some places, but could be devastating in others.

'Controlled randomness' is cool but takes time to achieve

[tiaoferreira]

Well, this thread is too old, but the question is always valid; I make my background stages by the more simple way as possible: build a big map and save it like an unique image.

But, in my project "PIXEL FIGHTERS" I'm trying to build maps starting randomic tiles that use mathematical combinations. This way, the map NEVER repeats when players run the game, the combination algorithms run aleatory pieces, and those pieces merge themselves, building a background environment.

The objective is prevent the players to remember where enemies spawn, where bonuses are hidden, where stay avoiding bullets...

For this, I built five objects to be the pieces of map; Each one of these pieces have 20 internal subpieces, and these have 40 frames, that always change according some mathematical combinations of frames.

So, the mathematical combinations define which frame will be showed according scenario of sea, desert, city, forest, snow...

I'm making it using flash MX AS1, and the codification is very simple. In general terms, the method is:

1 - Each stage/mission is defined by numbers, from 1 to 40 (more some secret stages). So, if first stage is called "1", the program will search the pre-defined environment to it. The main 5 pieces are classified like CITY, ISLAND, FOREST, MOUNTAIN and RIVER/LAKE; Into each of these 5 main pieces, there are 20 sub pieces with equal design, but with different colors and details, to be showed according the environment. Finally, the 40 frames contain little elements like cars, houses, trees, buildings, bridges and others. Those little elements also are selected by the same randomic code that controls the main 5 pieces.

See some examples:





2 - When the program reads that the stage/mission is "1" (or other number between 40), another piece of code says if the environment of these mission is : the CITY, ISLAND, FOREST, MOUNTAIN or RIVER/LAKE; This piece of code is a simple loop similar to old "FOR... NEXT, GO TO..." from basic. See:

Code: Select all

//ESTAGIO 1
	if(_root.estagio==1){
		this._x = 62.5;
		this._y = this._y + 0.5;
		this.gotoAndStop(2);
		_root.ilha2.gelo.gotoAndStop(_root.frame_ilha2);
		}

Translating from portuguese, "ESTAGIO" means "STAGE", "GELO" means "ICE" and "ILHA" means "ISLAND". Flash allows you to write using anyname wha you want, for variables. The coordinates _x and _y are the position of piece of map, this case, an island. Finally, the variable "frame_ilha" is an aleatory number from 1 to 40. It is changed when the piece of map appears on screen, on a position above the visible area for player. It runs when the piece of map is removed from screen, and stop when the piece spawns again.

See:



The great advantage of this method is to create incredible maps that (almost) NEVER repeat. At least, until now, none respawn EXACTLY equal the map that been shown before.

This method is fun, these are some results:











Unfortunately, one of five main pieces is showing a strange bug that causes a confused visual when the game runs.

But patience and new tries can solve this problem.

Well, by today is this

[Pteriforever]

I actually wouldn't recommend intricate backgrounds -- most of the time the player will be way too busy to pay close attention to the background, so something straightforward to set the scene is good enough. I use one large image for backgrounds. They tend to be pretty simple, so I don't bother make them as long as the stage. Each background in my games consists of a single 400 x 640 looping image.

I tend to make the backgrounds before the stages, just so I can tell if it looks good all put together when I test incomplete stages.

All enemies appearing at a specific place and time is what I've done, but the results can be really good when people do fancier things -- having particular enemies only spawn if earlier enemies are defeated fast enough can work great.

There are lots of approaches to enemy placement -- mine is to use a combination of large and small enemies, and make sure there's always something onscreen to fight unless you're immediately before a boss.

2 minutes for the stage portion I find is is ideal most of the time, but feel free to deviate from that. Final stages can get away with being considerably shorter, like they are in Touhou, and if you use enough midbosses and a sufficiently wide variety of enemies, they can be much longer than that without getting boring.

[DJ Incompetent]

Repeating backgrounds are fine, but insert uncommon "landmarks" throughout to create the illusion of variety.

Watch this intermission. What are you drawn to?

Since it's a STG, place the landmark on one side and have several seconds of popcorn spawns on the other side, giving the player an opportunity to spot the landmark.

[tiaoferreira]

My idea is just this: DO NOT RO GIVE LANDMARK

SEE the random code creating map pieces...


https://www.youtube.com/watch?v=VAe4HodY7Zg

[n0rtygames]

Combination of both. Huge background images and small pieces where required.

Positioning is handled by everything using world coordinates - not screen coordinates and basically using my own editor to place them in very specific locations.

Peed myself when it worked.

[MintyTheCat]

I tend to work on older Consoles and as such there are harder limits as to what can be achieved compared to modern day hardware.

Not so much with Shmups but with RPG games map prediction is also useful as a backend.

That being said I developed a rule based map generator primarily to make life easier. It generates a couple of plane's worth of graphics for tile based systems for a given level section length. Weighted systems using rules would be 'directed randomness'.

This also raises the theme of the player interacting with the background whereby rules once again play a role. E.g. if the player shoots things in certain orders or with certain weapons in places and at given game times then activate something works well to make things interesting.

I also like the idea of making the environment looked more damaged over time seen through nth game-loops.

Tool wise I quite like Tiled but I wrote my own Level-Editor handling processes to handle game events/etc.

Cheers,

Minty.