oosyrag's Forum Posts

  • I also ran into this logical roadblock when dabbling with procedural generation. How to get nodes and edges from a procedural Voronoi map? The data is there but how to get to it to utilize it...

    I think if I had continued I would tried layering it on top of another procedural map, for example terrain/elevation, to further further modify the elevation values or add terrain features to suit a particular biome, based strictly on the value returned by the Voronoi noise at each coordinate.

    Another idea I had, if using the Voronoi noise pattern to define spaces like on a board/tactical game for example, would be to use some sort of flood fill algorithm on any given spot until the returned value changes. Then at least I would be able to get the top/bottom/left/right bounds of any cell area, and maybe use the center of that as a node position. Defining edges between nodes should be simple enough from there.

    For a more accurate node position, you might be able to count and weigh the number of tiles/pixels in any particular cell and see how many fall in each quadrant relative from the "center". That might be just running the actual Voronoi noise algorithm backwards, I don't know. The formula should be out there.

    No ideas on how to get vertices and their edges though, to draw borders between cells or implement something like a river between biomes...

    Sorry if this doesn't help much, just thinking out loud. I didn't get very far in my experiments myself. I suspect you'll find more insight at /r/proceduralgeneration/ than on these forums, even if they aren't familiar with Construct. They would probably have more ideas and experience on how to use and apply the results by themselves even when the generation of the noise is obfuscated.

  • Multiplayer signaling actions are asynchronous. If you put them in the same event as the layout change action, you will leave the layout before either of the signaling actions complete. Notice that the "Signaling: left room" and "Signaling disconnected" message logs never show up, even though there are events to log when they happen. So basically what is happening is that you never left the room as far as the signaling server is concerned, therefore the "join room" action will no longer work even if you leave the layout and come back with a new peerid/alias. The second time you go to the game layout, since you're already in a room and the auto join room action fails, the following "On Signaling Joined Room" event does not run and assign paddles to host/peer.

    If you do the following, it works fine: 

    + Keyboard: On Escape pressed
-> Multiplayer: Disconnect from room
-> System: Reset global variables to default

+ Multiplayer: On signalling left room
-> Functions: Call AddLog (message: "Signalling: left room")
-> Multiplayer: Disconnect from signalling server

+ Multiplayer: On signalling disconnected
-> Functions: Call AddLog (message: "Signalling disconnected")
-> System: Go to Login

  • You'll want to use a text object attached to your enemy sprite in a container.

    When you type, you'll be able to compare the player input to the contents of the text object to pick the matching text object. If that text object is in a container with the enemy sprite, the correct enemy will also be picked. From there you have the proper target picked and you can do whatever you want with it, including get its position or destroying it.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Gonna start off by saying this is decidedly not a beginners topic, and that there are so many different ways to do it you're not going be finding a tutorial or template that will walk you through exactly the way you want it.

    Also, as far as game design goes, hand crafted levels are going to be superior to randomly generated ones 99% of the time, for much less work. I highly recommend building the rest of the game first, using a sample /example handcrafted level first, as the "fun-ness" of your game should not be dependent on procedural generation. When your core game is ready, you can add procedural generation of levels afterwards. By doing this, you'll also have a much clearer scope of what exactly you need your procedural generation to do.

    Here are a few resources:

    The closest thing I can think of from your description would be levels similar to Dungeon of the Endless: youtube.com/watch

    gamasutra.com/blogs/AAdonaac/20150903/252889/Procedural_Dungeon_Generation_Algorithm.php

    squidi.net/three/c_procedural.php

  • If wallclock time doesn't work, use date.now.

  • You can use system wallclocktime, or the date plugin's now expression to get Unix time.

    Dt by default has a limit of 30 fps (minimum of 0.033. You can change this by the system action set minimum framerate.

  • You can probably do something with the set tile range action.

    I imagine I would still use an invisible helper sprite to define the area of tiles to erase or replace and collide with. It could result in vram savings.

  • One of the simplest ways would be to make it invisible while overlapping your player sprite, else visible.

  • If your want a more robust system, you'll probably want to use an array to keep track of all inputs in order and base most your event conditions off of that array.

  • Are they button objects or sprites?

    If they are button objects, are you using css styling?

    Button objects are html elements, so they have the possibility of being rendered differently depending on the browser. You can have more control over their appearance by using CSS, or better yet use a sprite object.

  • You can do it pretty much as you described.

    When conditions met for a buffer able input, start a timer.

    On action finished and is timer running，do buffered action.

  • You're going to need to give more information to get help.

    For example, if you mentioned what tutorial you tried to follow and show what you ended up with, someone would be able to say why it's not working.

    Construct tutorials generally do not get outdated even from C2 to C3, so you don't have to worry about old tutorials. Even if there is a new feature that might make things easier, backwards compatibility is usually still there.

    There's also many ways to do a particular thing so it helps to be specific. Here's one that uses tiles, which may or may not be relevant to you.

    howtoconstructdemos.com/push-objects-in-tile-based-game-sokoban-style

    Multiplayer adds additional complexity. If someone gets pushed do they lose control of their character for the duration? What happens if there is a conflict? It's best to work on your mechanics one at a time.

  • From a memory management standpoint, different tilesets are what layouts are designed for. If you use different layouts, you won't have to keep all the currently unused textures in memory. You'll then be able to load a lot more/bigger/nicer textures per any given layout.

    Note you can use the same event sheet for all of your layouts, while season specific events can check a simple variable that keeps track of the season as a condition.

    Multiplying the layouts by 4 doesn't seem like much additional work to me, considering you want different seasons to begin with and I'm assuming you don't want the seasons to look the same. That means the 4 sets of different graphical assets have to be made anyway, which is the bulk of the work.

    As for setting up the map 4 times, I believe you can just copy and paste the painted tilemap object and just change the tilemap source image, assuming your 4 season source images use the same tile layout. You'd probably want to use a program like Tiled to build those maps. As an advantage, having them separate allows for individual changes to the map itself for each of the seasons as well.