Posts by Yima

Thanks a lot for the thorough reply! The game will be "open world" in a sense, with a camera that snaps to each 320x240 pixel room - there will be nearly no camera scrolling. So, there won't be any levels, but rather rooms and areas that you can move seamlessly between.

The level editor approach is likely the best one from a performance perspective. The thing that makes me reluctant to use it is that my game (much like IWBTG) will have a lot of unique things going on inside each room. While a game like Super Mario Bros is rather limited in feature scope, IWBTG has unique traps in each and every room, making it harder to apply a general solution to storing things (I think?).

I am wondering if there is any merit to using quick backdrops rather than backdrops when possible? For example, assuming that a room should have it's bottom part filled with tiles, I could replace the 20 individual backdrops with a single quick backdrop that stretches over the entire room (using a tile motif that visually ends up looking the same). Is this something that improves performance a lot, or can I just place backdrops to my heart's content?

I have returned to CF 2.5 after being away for over 10 years (using other tools). One game that inspired me to make games back then was I Wanna Be the Guy, which is created in MMF2 (I think?).

I am thinking about creating a similar, masochist platformer and want some advice regarding performance. If I recall correctly the initial version of IWBTG was created in one single frame, with everything being loaded at once. The game contains less than 100 rooms filled with collision tiles and traps (a lot of spikes). That game seems to be running fine, so I am wondering if I can get away with creating my entire game in one single frame?

To make things more clear, I plan to have around 50 rooms. Each room is 320 x 240 pixels, filled with 16x16 pixel collision tiles and some active objects. I estimate around 100 backdrop objects and roughly 10 active objects per room. This gives 5000 backdrop objects and 500 active objects for the entire game. There will be rooms that have particle effects such as rain, but things like that will be loaded only when the player enters the room.

The game is currently targeted for PC only, so I do not have to take mobile performance into consideration.

My question is if this is an approach that can work, or if I am setting myself up for failure?

This is the bare bones beginning of a remake of a platform engine that I posted a few years ago. Its purpose is to act mostly as a guide to how to solve basic platform movement, including moving platforms and slopes, using only math and no built in collision checks. I created it because I have had quite a few people asking me for my old engine, that sadly was lost in a HD crash. It is by no means perfect, but I hope it can serve as a starting point for those wanting some input on how to solve basic platforming algorithms.

/Styrbjörn Andersson

Please login to see this attachment.

Thanks for all the replies! It makes me happy to see that the easier way seems to be the way to go. I'll do the final touches to the base engine, and then I am good to go!

I created a 30 minute mock up to show you the basics of how it can be done. It is of course far from optimized, and only contains a few waves, but it should hopefully be good enough to get you started (file is attached to post)

Control the ship with arrow keys, shoot with Z. Nothing happens after the wave with blue enemy ships (that shoot at you), so you can just exit after that (or press F2 to play again).

I would divide this problem into two parts. The first part is to solve how to spawn enemies as the player comes close enough. The second part is to program enemy behaviour.

For the first part - the enemy spawning, I would probably do the entire stage as a single frame, creating placeholder actives (as Popcorn said). Then, before moving on, we have to assume a few things:

1. We use a camera object, that is used as a center for frame scrolling.
2. The camera moves slowly from left to right, until it reaches the end of the frame.
3. The player is free to move around (but not outside) the currently visible view.

This is pretty much how a shmup like Gradius or R-Type works. Now that we have a camera, we can use it's position to determine when to spawn an enemy. We can do it with an event like this:

If the enemy spawner position, minus the position of the camera, equals to less than half the screen width, we spawn the corresponding enemy and destroy the spawner.

This way you do not need to use a timer to determine spawning.

For the second part, which is enemy movement, you can do this in a multitude of ways. You could use one of the built in movements (path movement, bouncing ball, etc.), do the whole thing mathematically using sin and cos calculations for horizontal or vertical speed (good for curved movement), or make up your own algorithms for moving stuff around.

Please ask if you want further directions - this is what I can think of right now

This question has been asked before, or at least variations of it. The reason I am re-asking it is that I want input that is valid for CTF 2.5 and for the project I have in mind.

The game I am working on is divided into levels (one per frame). Each level is supposed to contain an average of 10-20 "areas", which each has the size of the screen (320 x 240 pixels).

Since I am working with a level editor, that loads areas on the fly, I need to pick an approach for how to solve background objects. The player is supposed to move seamlessly between areas (the area should load within a fastloop with no delay). I have achieved this already for all "game logic" objects (obstacles, NPC:s, platforms, triggers etc.), but I need a solution for the graphical part as well. The two approaches I have considered are as follows:

1. The tile based approach

Each graphical tile is it's own object, and normally has a size of 16x16 pixels. Some tiles can be larger, up to one screen wide and/or high in rare cases. This means that I have to load an additional 200-300 objects when the player enters a new area. All of these objects have to be positioned (x and y position, and put into the right scrolling layer). This approach would likely lead to less pressure on RAM, given that the tiles loaded are generally small. Repetition of tiles means I can represent the background with less graphical data than if I use a big image.

2. The image approach

Instead of using tiles, I draw each 320x240 area in Photoshop (quite easy to do with the grid). Then, when the player enters a new area, one image is loaded for each scrolling layer (likely one for the tiles the player are walking on, and one for the "far" background that is subject to parallax scrolling). The advantage of this (I suppose?) is that it is less CPU intensive. I load 2 objects, instead of several hundreds. Also, I get way less clutter in the frame editor this way. A cool side effect of working with images instead of tiles, is that I could put a lot more variation into the "tiles" of the background, without ending up with a lot of objects/images. The backside is that I will end up with a bunch of larger images (10 to 20 320 x 240 images per level) that leads to a larger executable, and more pressure on RAM - however, I once learned that the less things you do in fastloops, the better, so in that regard this solution should be more favorable.

For convenience, I would like to work with the image approach, but I know that the common approach is to use tiles for memory purposes. The question I have is if I, given my specifications, can get away with using large images insteas of tiles in my project. It should be noted that I develop for desktop only, so phone/tablet support is not relevant here.

Thanks in advance or any answers!

Thank you, AndyH, for the advice! I have secretly peeked at your examples in the past, and I recall having learned a thing or two from them

I went with the active object approach in the end. Currently I am quite satisfied with what my "engine/editor" can do. Everything except hit collision boxes will be treated basically the same. They will have three values stored in the array:

objectID: stores a number which makes it possible to create that object again by "Create object by name".

area: stores the area which the object belongs to. This is calculated automatically for each object at the start of the frame, by iterating through the areas and comparing area bounds with the objects position. This is probably the most taxing part of this solution, and one that makes me wish that we could set different values for multiple instances of one object in the frame editor. Finding out the area for all objects means that I have to run a 20 areas x 3000 objects (roughly) loop. It's still pretty fast though, so it works.

zDistance: Replaces layer parallax scrolling, and (almost) removes the need to guess where I should place a background object to make it turn up where I want to. It also makes it possible to sort items using the layer object.

I am getting close to the point where it's time to start creating the platform engine, and after that (with a bit of luck) I can start playing with level design.

Edit:

I forgot to mention that I am not considering any other platform than PC for this, so phone/tablet optimization is not an issue here.

I am working on yet another level editor, and this time around I am considering a hybrid solution. I want to use the frame editor of CTF as my "editor" (which saves me the time I would have used to build my own). The basic idea is that I place every active object that I want in the level, using the the frame editor. Then, on starting the frame, all objects will be loaded into an array and get destroyed. Then, depending on the player position, actives (NPC:s, collision boxes etc.) will be placed and destroyed, keeping the amount of active objects at a minimum at all times.

What I am wondering about currently is if I really need to treat background tiles the same way as I treat the actives. The tiles are not used for collision detection - I use actives for that, and those are loaded into the array. I will be working with roughly three layers of tiles (for parallax purposes) - I don't know if layers affect performance much. The frame will be 3200 by 2400 pixels, and the visible play area is 320x240 pixels.

I am considering two different solutions, and I am wondering which one would work best performance wise. Will both work without any issues at all?

Solution 1:

Place all tiles (a few thousand, like 2000 to 3000) as backdrops in the frame (non obstacles. 16x16 pixels). Done, hoping performance will be smooth!

Solution 2:

Have all tiles be actives belonging to one qualifier. Then, in the frame editor, I could clone actives with different graphics for the tiles and place them as I want (lke in solution 1). When satisfied, I would create a "stamp" object that contains each image used as different frames. Then, upon loading the level, I treat the tiles as all other objects - I store them and delete them (doing a for each loop on the objects with the tile qualifier). When the player moves to a new room, I could iterate through the "tiles" array, place each relevant tile as an active, alter the frame to the desired image (stored in the array) and then paste the active as a non obstacle background. When the player leaves the current room, I can delete all created backdrops and repeat the process. This is a "clean" solution, but it would mean that I have to load and destroy a lot more objects (probably up to 10 times more). Will this affect performance?

Also, storing and deleting several thousand objects at the start of frame might (or might not) cause a slight stutter. I could make up for this with a "Loading" text though, so it's not the greatest of issues.

I am at the point in development where I need to make a choice. It should be noted that while "start of frame" load stutter (if any) is no big issue, load time between "rooms" should be non existant. I am creating a platformer where the player is supposed to be able to freely jump and run between rooms, with no delay.

I am really thankful for any answers I get

I am wondering if there are any disadvantages to using a lot of event groups. For example, I got a fast loop called "Place detectors", which triggers five different events. I wonder if it is a good idea to put the "Place detectors" events in a group called "Detection", just to make it possible to "minimize" the group and thus reducing editor clutter?

I also use groups to be able to disable certain events (such as disabling keyboard controls if a gamepad is selected), and I guess that is what the event groups are really for. It's the usage of event groups to create "event folders" that I am unsure if it is a good idea

Thanks for any answers!

That would be practical. For now, it's certainly possible to save the dungeon layout to a file (that is the main point of the generator), but I guess you are looking after something like the seed in Minecraft or Cubeworld, where you can enter a seed that controls the "randomization". For now I have no idea how to do that, but I am really interested in learning how to do it, so I will get back to you if I come up with a solution!

Edit: After some thinking I feel that I might have come up with a basic solution to creating a seed based generation. I have to work tomorrow, but I will modify the generator as soon as I can.

Thanks for the quick reply! I really like Box2D, but I find it quite educational to develop own tools as much as I can. Also, the platform game I am working on will be quite simple, so the physics of Box2D would likely be overkill for my project.

Hi!

I have a question about platform collision detection performance. Normally I just place backdrop objects as obstacles, which I use for collision detection (I use several detectors attached to a box that I move around using fastloops). However, I started working on a polygon based approach, where I use an editor to store "hit boxes" in an array by clicking and dragging (much like drawing boxes in a drawing program). The array contains the start and end X and Y coordinates for each box, and collision would be handled by looping through the array to see if the coordinates of my detectors overlap with the edges of my stored boxes.

What I am wondering is whether this "polygon based" approach would be better for performance than placing actual backdrop objects to do pixel collision checks. A great advantage with the editor I am making is that it is really quick to click and drag the different collision areas. Also, it's easy to save the "levels" to a file, which makes it possible to load levels into a single frame instead of using the CF editor to create levels in several frames. If it's bad for performance I'll have to solve it differently, though.

If anyone has any inpout on this matter I would be happy

Thanks! Just tell me if you have any questions

Please login to see this attachment.
I just finished a random dungeon generator. It produces an array containing the X and Y coordinates, the tile type (path, wall, start or end) and tile graphic information of the dungeon.

The random dungeon generation is quite easy. It walks from a starting position until a predetermined number of tiles have been placed and a minimum distance from the starting position has been reached

The tile graphic part is solved by using prime numbers to create unique ID:s for different tile combinations. I did this in a separate editor, which is also included in the example.

It might not be the most intuitive example ever (far from, I guess), but I hope it's useful nonetheless!

The example can be found here: Please login to see this link.

Some new content added. Today I created the first part of a two part tutorial, that will cover how to create random paths between two points on a two dimensional grid. This solution can be used for any game that involves random mazes and dungeons. The second part will likely be posted this weekend, and if time allows I will create a MMF 2 example of it as well, to demonstrate how it (hopefully) works

Sorry for not updating a lot right now. I have had quite a lot of work and little time to do fun stuff Today I finished some concept art from a game I am working on, though, so I posted in on the website.

I added a new example, based on fabers idea about using trigonometry. It's a simple asteroid shooting game foundation, that uses the ATan function to rotate a cannon depending on the position of the mouse. More than half of the time was spent on animating the asteroids, and they still ended up kind of clunky >.>

Quote from faber

Good luck with the new project, it seems to have all the makings of a useful resource for clickers! Eager to see new examples and tutorials, hope your work and family allows it
Since you asked, here are some ideas on click-related examples I would love to be explored: feel free to take inspiration if you want!

- Engines inspired by classic games
- Trigonometry and its applications in F2.5
- Multiplayer games, lacewing, etc.
- Special effects (i.e. with lens shaders, particle effects, etc.)
- INI object for PC and various applications within android/ios/html5 games

Some really nice ideas there! I'd be especially interested in trying to replicate older games (mainly platform ones, since it's my favourite console genre). Thank you!

Thanks! I agree that it might be hard to update at such a rate, but I feel that especially in the beginning it's important to add content to a point where people actually find the site worth visiting