User Tag List

Page 1 of 4 1 2 3 ... LastLast
Results 1 to 10 of 31

Thread: Best way to make Castlevania map?

  1. #1
    Clicker Fusion 2.5 (Steam)Fusion 2.5 Developer (Steam)Android Export Module (Steam)HTML5 Export Module (Steam)iOS Export Module (Steam)Universal Windows Platform Export Module (Steam)
    seep's Avatar
    Join Date
    Mar 2015
    Posts
    35
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)

    Best way to make Castlevania map?

    Hi guys,
    I have already some ideas to make a Castlevania Symphony of the Night map ( https://i.redd.it/2wfvac2r3pn41.png ), but are a long process and I prefer ask you if know a method just easiest.

    The idea off course if unlock the pieces of the map when the player visit a certain place. I thinked created it just using global variable + switchable graphics of the map, but I think is a little bit long... Do you have some ideas to make it easy?

    Thanks!

  2. #2
    Clicker Fusion 2.5 Developer

    Join Date
    Jul 2008
    Location
    UK
    Posts
    1,397
    Mentioned
    16 Post(s)
    Tagged
    0 Thread(s)
    Yes, it will be a (very) long process - that's unavoidable.

    Global values are generally best avoided where possible. It's usually better to use object alterable values (if for no other reason than to keep them organised) and arrays. For tracking which areas of the map have been unlocked, there are loads of possibilities - it doesn't much matter how you store that information during the game, but when saving the player's progress you'll need to include it in the same array as other information like the player's location and health.

    For any game that's even remotely close to the scale of CSotN, you will want to create your own custom level editor - the time saved by having a good design tool tailored to your specific game (instead of the generic and clunky frame editor that is built-in to CF2.5), will easily outweigh the time it takes to create one.

    It's going to be easiest to have the entire game (minus the main menu etc) run in a single frame, but only load one "room" at a time, from an array (do not use one frame that's the size of the whole map, and do not use a separate frame for each "room").

    Obviously if you're just making a really tiny game (fewer than 10 rooms maybe), you can do things any way you like.

  3. #3
    Clicker Fusion 2.5 (Steam)Fusion 2.5+ DLC (Steam)
    vSv's Avatar
    Join Date
    Aug 2010
    Location
    Sweden
    Posts
    138
    Mentioned
    7 Post(s)
    Tagged
    0 Thread(s)
    [QUOTE=MuddyMole;766081(do not use one frame that's the size of the whole map, and do not use a separate frame for each "room").[/QUOTE]


    What is the reason to not use a frame with the size of the whole map?
    Is it very demanding for the cpu/gpu, or is it even noticeable to run a map that is much larger than the level itself?

    The reason I'm asking is that I'm curretly building all my levels in one frame that is loaded in "chunks" at start of level, so every object is not there at the same time but the size of the level is the same, and it's somewhat large (15168x8256), but I haven't noticed any slowdowns yet.

  4. #4
    Clicker Fusion 2.5
    Fusion 2.5 (Steam)Fusion 2.5 Developer (Steam)Android Export Module (Steam)HTML5 Export Module (Steam)iOS Export Module (Steam)Universal Windows Platform Export Module (Steam)
    JimJam's Avatar
    Join Date
    Jun 2006
    Location
    USA
    Posts
    353
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by vSv View Post
    The reason I'm asking is that I'm curretly building all my levels in one frame that is loaded in "chunks" at start of level, so every object is not there at the same time but the size of the level is the same, and it's somewhat large (15168x8256), but I haven't noticed any slowdowns yet.
    To my knowledge, this technique you're using should be fine. "Chunking" levels and loading them on-the-fly is a pretty standard game technique, used in all sorts of games, ranging from Zelda, to Grand Theft Auto, and probably most famously Minecraft. But notably, these games "stream" the chunks in as needed (only the chunks that the player is in, and the ones immediately around them). Loading all the "chunks" in at the start of the level kind of defeats the point of chunking it up in the first place.

    But if you haven't noticed any slowdown so far, you're probably fine.

    It might be good idea to find someone with a 10 year old low-end laptop (or if you have one yourself) to do some "limit testing" for your game. You'll get a better idea of what things cause slow down on a slower machine.

    One thing I learned in general is that video games are not built on "perfect code" but "good enough hacks" that no one will really notice. One of my favorite little "tricks" was in Mario Galaxy -- they needed to have a certain door in a certain level make a text note popup. But instead of programming a new object that Mario could "read" they just hid an already programmed Sign Post object behind the door.

    https://nintendoeverything.com/super...ng-a-signpost/

  5. #5
    Clicker Fusion 2.5 Developer

    Join Date
    Jul 2008
    Location
    UK
    Posts
    1,397
    Mentioned
    16 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by JimJam View Post
    To my knowledge, this technique you're using should be fine. "Chunking" levels and loading them on-the-fly is a pretty standard game technique, used in all sorts of games, ranging from Zelda, to Grand Theft Auto, and probably most famously Minecraft. But notably, these games "stream" the chunks in as needed (only the chunks that the player is in, and the ones immediately around them).
    The part you left out is that also they dispose of the previously loaded chunks to make way for the new ones - if you leave an area and then come back to it, usually enemies etc will have respawned, because the game has had to regenerate that section of the map again. In fact, if you don't do that, then loading the map in chunks has little benefit over loading the whole thing at once - it will mean that the game loads slightly quicker to begin with, but then there is the added risk of a brief lag during the actual gameplay, as a new chunk is loaded, which is far more annoying to the player.

    CF2.5 can "de-activate" objects when they get too far away, so it doesn't waste time applying events to them, but it must still be storing all their properties in memory, which could perhaps affect performance if you have enough of them (probably more so than the physical size of the map).

    These days, computers (and especially graphics cards) are so powerful that you can "get away with" a lot. Whether that's the case for a low-end Android smartphone, or an old unplugged laptop in battery-saver mode, I don't know - only testing will tell you. It's good to try and do things as efficiently as possible anyway though, within reason...

  6. #6
    Clicker Fusion 2.5Fusion 2.5 Mac
    Fusion 2.5 (Steam)Fusion 2.5 Developer (Steam)Fusion 2.5+ DLC (Steam)Android Export Module (Steam)HTML5 Export Module (Steam)iOS Export Module (Steam)Universal Windows Platform Export Module (Steam)
    zip2kx's Avatar
    Join Date
    Jun 2015
    Posts
    860
    Mentioned
    18 Post(s)
    Tagged
    0 Thread(s)
    Each room would be its own level, you build and save them to an array and then load them when the player hits certain trigger points. There are examples in forums if you search for "array based level editor".
    Can be complicated if you havent done it before.

  7. #7
    Clicker Fusion 2.5
    Fusion 2.5 (Steam)Fusion 2.5 Developer (Steam)Android Export Module (Steam)HTML5 Export Module (Steam)iOS Export Module (Steam)Universal Windows Platform Export Module (Steam)
    JimJam's Avatar
    Join Date
    Jun 2006
    Location
    USA
    Posts
    353
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    Good point Muddymole. Yeah, just loading in new chunks without ever un-loading old ones, would just eventually cause major slow down and fill up your RAM. But to be able properly mange that and unload areas, you'd need some sort of direct access to the memory. And to my knowledge, Fusion handles the memory allocation all on its own behind the scenes, so you don't have to deal with that stuff. In most cases, this is great because it allows rapid prototyping and less "micro-managing" from us. But for large data sets like that, yeah it can be an issue.

    One neat trick that I've found: you can sort of create your own "RAM" management, by using a finite number of objects with an ID alt value, and re-order them based on context. This way you always have the same number of objects loaded into memory at all times (no lag, because Fusion isn't constantly creating and destroying new objects, thus having to constantly add/remove things from RAM).

    An example of this would be: let's say that your character kicks up a little dust cloud particle every time they walk. And after about 1 second, the dust cloud particle fades away and would normally be destroyed. So using normal create/destroy method, you'd be creating (and destroying) a new object every 1 second. And let's say that this dust particle is only kicked up 4 times every second (according to your character's walk animation). This means that at most, there will only ever be 4 particles in existence at once.

    Since you know exactly how many particles there will ever be, instead of doing the create/destroy object method -- you can just "cycle" through 4 pre-made particles that are always in the frame. When a dust particle reaches the end of it's lifespan, you simply make it "invisible" and maybe store it off screen. If you give each particle object a unique ID (ranging from 0-3) you can just use a Global Value to +1 the "particle index" so you know which is the next particle to "create" (reappear). When loop your Particle Index Global Value back to 0 when it reaches the "end" you simply apply MOD math = "ParticleIndex = (ParticleIndex + 1) mod 4"

    If you use this method, you also completely avoid any potential bugs where (for example) you accidentally have a particle effect that continually creates 10,000 objects until your game crashes!
    The downside to this method is that there will be a hard-limit to the number of particles on screen - but this limit can be whatever you want it to be, and you simply have to make a good estimate on how many particles you need.

    For example, if you have a character that kicks up 4 dust particles per second, with a lifespan of 1 second, you'll only ever need a max of 4 particles objects. If you have 2 characters on screen, you'd need a max of 8 particles. If you want to create a sort of safe "buffer zone" for extra particles, you can just increase the limit a little further than you'd need, (+5) or even just double the limit (16).

    ---

    So a more relevant example of this would be for a level screen. Let's say you know that there could only ever be a possible 100 tiles on screen at once in your game. You could use 100 Actives, and simply reposition them when the screen scrolls, and reload a new "tile" animation. Since there physically can not be more than 100 tiles on screen, you don't need to "create" new chunks. And again, if you wanted some buffer room there, you could increase your limit to 200 so that your game is loading the tiles on screen, and a little ahead and behind you.

    To the best of my knowledge, this is how most old SNES-era games worked. They'd use a sort of "array" to manage all the objects and tiles on screen. So when you killed an enemy, or they went off screen, their slot in the array would be "freed up" to load a new enemy. This is how they worked within the memory and sprite limits of the hardware at the time. But using those same techniques on today's hardware also help make our code much more efficient to run.

  8. #8
    Clicker Fusion 2.5 Developer

    Join Date
    Jul 2008
    Location
    UK
    Posts
    1,397
    Mentioned
    16 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by JimJam View Post
    So a more relevant example of this would be for a level screen. Let's say you know that there could only ever be a possible 100 tiles on screen at once in your game. You could use 100 Actives, and simply reposition them when the screen scrolls, and reload a new "tile" animation. Since there physically can not be more than 100 tiles on screen, you don't need to "create" new chunks. And again, if you wanted some buffer room there, you could increase your limit to 200 so that your game is loading the tiles on screen, and a little ahead and behind you.
    One of the examples in my "tile-based examples" pack (the frame called "virtual scrolling") does exactly that:
    https://1drv.ms/u/s!Atq7cUIJ7uexhEsh...sPYq2?e=wrtjrr
    (although, just looking at it now, I can see it could be optimized a LOT)

    To be honest, I think it's probably a step too far unless you're forced into it (as developers for old consoles were). It's complicated, it makes everything else more complicated, and I doubt it's even faster in CF2.5. Like you say though, for particle effects, where you're constantly creating and destroying instances, it would make a lot more sense.

  9. #9
    Clicker Fusion 2.5
    Fusion 2.5 (Steam)Fusion 2.5 Developer (Steam)Android Export Module (Steam)HTML5 Export Module (Steam)iOS Export Module (Steam)Universal Windows Platform Export Module (Steam)
    JimJam's Avatar
    Join Date
    Jun 2006
    Location
    USA
    Posts
    353
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    @MuddyMole - Awesome work, I've had your Onedrive link bookmarked for a while now from some other thread. There's a lot of great stuff in there to sift through.

    And yeah, I agree that for tiles it's probably too much to manually handle them in this way. I just brought this up because it's more relevant to the this topic at hand (Castlevania Map). I'm sure Fusion itself (or the tilemap extension) handle this sort of task much more efficiently than making up an array system in Fusion . But for particle systems, it can definitely be useful to have limitations in place.

    That said, the Tilemap extension would be best bet to handle the actual static tiles. But this doesn't touch on the issue of actual Active Objects (the enemies, items, etc in your level). You'll still need to figure out some way of handling how these things should behave when off screen. Should you load them all at once and keep them in memory? Should you create some system to dynamically load them? Should you just let Fusion handle it all by default?

    It really depends on what the objects are doing, and how you want them to behave.

    I've had some issues before with letting Fusion just handle everything. For example, for items or powerups that have little to no behavior (just a static Active that the player collides with), just letting Fusion deactivate them tends to work fine. But I've had issues with enemies falling through the floor when off screen, or enemies pausing (getting deactivated) in weird spots when outside the screen. So I think how to handle these objects need to be evaluated case-by-case.

    @Seep - Definitely check out the Tilemap object in the Extension Manager. For the actual background tiles, it's incredibly efficient and dynamic.

  10. #10
    Clicker Fusion 2.5 DeveloperAndroid Export ModuleHTML5 Export ModuleUniversal Windows Platform Export ModuleSWF Export Module

    Join Date
    Jun 2014
    Posts
    64
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Personally I would use 2 arrays for a map like that. One array for the general world map & another for the actual tileset placement. Maybe there's a better extension for the tiles, but the default array is cross-platform & would definitely save you a problem in the long run if you plan to release across multiple formats.

Page 1 of 4 1 2 3 ... LastLast

Similar Threads

  1. Castlevania Whip Example
    By Sparckman in forum Guides, Tutorials, Examples, Widgets
    Replies: 0
    Last Post: 2nd June 2014, 06:16 PM
  2. Castlevania stairs
    By Atherton in forum Multimedia Fusion 2 - Technical Support
    Replies: 4
    Last Post: 13th December 2009, 03:08 PM
  3. Castlevania Sprites and SFX
    By piscesdreams in forum The Games Factory 2 - Technical Support
    Replies: 1
    Last Post: 22nd December 2007, 07:47 PM
  4. Castlevania help
    By piscesdreams in forum The Games Factory 2 - Technical Support
    Replies: 5
    Last Post: 20th December 2007, 04:55 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •