A pseudo for NPCs to travel between layouts

This forum is currently in read-only mode.
From the Asset Store
A well commented Pseudo 3D Racing game template to learn from or use as a base for your own game!
  • Since I'm making an RPG and I'm trying to make the NPCs travel between layouts, I have thought of a pseudo that might work for them to be able to do that. I have not tried this but I'm gonna post steps. Try to correct me if it wont work or something or give some suggestions etc.

    Assuming I have all the things I need (objects etc..):

    1. Make a set of global variables for each NPC (or just a global array).

    2. Make the NPC objects global.

    3. When an NPC enters collides/overlaps/i dunno a "warp" object, depending on which warp object, it will it put some values in that NPC's global variables like its warp destination(layout name and position). A variable that will contain its destination will also be inputted by a value.

    Ex. Lets say NPC1's global variable "place" has a value of "village1" and its global variable "posX and posY" have 10,250 as its values respectively. When it collides with a warp object that suppose to enter village2, the GV "place" which has a value of "village1" will be replaced with "village2" and lets say the posX and posY GV is replaced by some a certain value. After that, an event will take place wherein NPC1 will be teleported to the layout and position base on its GV "place" and "posX" and posY". After that, NPC1 in village1 is destroyed.

    Ofcourse, besides those 3 GV (global variable), there will be other variables to be included (I guess )

    So that's my uhhh algorithm for this. Any help? Recommendation?

  • I would get completely rid of the idea of having the NPC actually travelling from one layout to the other. Let me give you my current thoughts on this...

    The player obviously will only be in one layout at a time. Now if a NPC is supposed to be in this layout, you simply create him and pull his stats from some sort of database. And respectively, if he should "leave" the layout, save his current stats again to the database. Maybe let him walk to a certain destination on the map and then destroy it. Easy enough theory I guess?! Indeed it's very theoretical without any concrete advice how to do it object/eventwise, but that's the fun part for you to figure out.

  • I have been thinking, since it might be too far from possible to travel an NPC from layout to layout using the current version, how bout if I make one layout as big as I can and divide it into several square pixels or something, then each square pixel will have its own map, so instead of traveling between layouts, the NPC will just travel inside the layout but in different parts and it produces the illusion that everyone in the game is traveling between maps.

    I know this could probably lag the game at some point. Would it be a good idea to shrink everything by half and at the same time zoom the screen by half? So that when playing, it would seem as if everything is at the same size as its suppose to be.

  • I know this could probably lag the game at some point. Would it be a good idea to shrink everything by half and at the same time zoom the screen by half? So that when playing, it would seem as if everything is at the same size as its suppose to be.

    If you had a really big layout you'd probably need some kind of system that would create objects if they're about to be onscreen and destroy them when they're off, in order to get good performance.

    As for the shrink/zoom idea... what????

    You would lose detail by shrinking your sprites, not to mention it'll probably look awkward. Sure if you zoomed in they'd take up the same size on the screen, but that's besides the point. Don't do it.

    I still believe it would be very doable with the theory I mentioned. Creating a basic example seems like a terrible chore right now, otherwise I'd try to do it.

  • So the shrink/zoom is a bad idea. Anyway, wouldn't it affect the NPCs if they entered a part of the layout on which the player is not literally on, since at that time, the objects would not have been created since they're not on screen?

    Would it decrease the usage of memory or lag if objects were invisible until either an NPC or the player is not in that part of the screen? And that it becomes invisible again if theres no NPC or player near by.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • I like Pixelrebirth's idea for NPC's to exist in different layouts. It handles some of the weird issues of making all of the NPCs global. When you make them global then you have to deal with turning off collisions and hiding any one the NPCs per layout. You can do it both ways.... the original way you suggested by making them global or going the Pixelrebirth route. The first way you suggested is probably easier at first but will get complicated as your world grows. The other way will be more work to setup at first but would probably pay off long-term.

  • You would lose detail by shrinking your sprites, not to mention it'll probably look awkward.

    No, you wouldn't lose detail. Why would it look awkward?

    Zooming et al in Construct is done before applying texture maps (sprite images) so it would look just the same.

    You would only lose precision, so in a large layout you could run into rounding issues. I believe it's a bad idea but not because of sprite distortion but because simulating your whole world at once could get slow, depending on how your game works. Also... come to think of it... a large zoomed layout would be just the same as a larger layout but with rounding issues... so it's just not helping.

    if you NEED to simulate warped NPCs in detail (colliding with walls, etc) then do big layout. If it's not really important (very likely, most games do this) then just store the NPC data somewhere you can retrieve it when you go to that layout.

  • No, you wouldn't lose detail. Why would it look awkward?

    Zooming et al in Construct is done before applying texture maps (sprite images) so it would look just the same.

    Oh indeed, you're right. Need to check my logic the next time.

    Still the verdict remains the same.

  • If ever I would go with the big layout with lots different maps in it route, I would assume some lag in it, my uhh desired height and width for the layout would probably be... 51200x51200? I tried it, and it was alright at first, but I'm guess as I put more maps or objects in it, its going to lag slowly and slowly.

    Anyway, is there a way to load every objects in that layout before showing everything to the player? You know... loading screens?

    And assuming a 52100x52100 layout full of objects all moving and doing their own stuff synchronizingly, how much RAM would you recommend? Since I will be putting this in our "System Requirements"

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)