Managing Object Placement

ID:2941717
 
Aug 21, 8:34 pm (Edited on Aug 24, 3:56 pm)
Code:
obj/tree
  icon = 'tree.dmi'
  icon_state = "trunk"
  New(x, y)
    ..()

obj/tree_foliage
  icon = 'tree.dmi'
  icon_state = "foliage"

obj/rock
  icon = 'rock.dmi'

proc/spawn_objects()
  var/list/tiles = list()

  for(var/x=1;x<=world.maxx;x++)
    for(var/y=1;y<=world.maxy;y++)
      if(!world.Get(x, y))
        tiles += list(x, y)

  for(var/i=1;i<=10;i++)
    var/tile = tiles[rand(1, tiles.len())]
    tiles -= tile
    new /obj/tree(x=tile[1], y=tile[2])
    new /obj/tree_foliage(x=tile[1], y=tile[2]-1)

  for(var/i=1;i<=5;i++)
    var/tile = tiles[rand(1, tiles.len())]
    tiles -= tile
    new /obj/rock(x=tile[1], y=tile[2])

world/New()
  ..()
  spawn_objects()


//Le forum
obj
  tree
    icon = 'tree.dmi'
    icon_state = "tree"
    
    top
      icon_state = "top"
      pixel_y = 32
    
    proc/addTreeTop()
      src.overlays += /obj/tree/top
      
    New()
      ..()
      addTreeTop()


Problem description:
In BYOND DM, you start by defining objects like trees and rocks with their icons and states. Then, you create a list of empty tiles on the map. You randomly select tiles from this list to place your objects, ensuring each tile is used only once. Trees have their trunk and foliage placed with the foliage one tile north of the trunk. Rocks are placed directly on the selected tiles. This method ensures a random and organized placement of objects on your map.

How does the randomness in object placement impact the player's experience and engagement with the game world?

It's 2024. With players likely returning, how probable is it that survival games in BYOND will make a comeback?

Aug 21, 8:57 pm
Doesn't look like you're trying to trouble shoot code. If you're just trying to gauge opinions on gameplay mechanics, I think the randomness helps with immersion.

No matter what game, every developer wants their world to seem natural -- and in the natural world, there's a bit of randomness.

As for the likelihood of a survival games come back? It depends on how much work you're willing to put. Who knows, you might make the next big hit!

So to answer the question, doesn't seem that probable. But it can happen.
Aug 22, 11:55 am (Edited on Aug 22, 12:35 pm)
To answer your question in greater detail, this is something that requires the developer to write an algorithm for procedural generation. Already, there are many games on BYOND that use procedural generation for various things, including maps. Space Station 13 uses a cellular automata-based procedural map generator for creating the space asteroid (now lavaland), for example.

Now as for the gameplay question: Randomness doesn't have to be totally random. In most cases, procedural generation is constrained randomness. It's random, but with results that fall within specific criteria. Every procedural algorithm can be written to reflect whatever nuance the author wishes. Here's an example from my own map generation code:

Code:
proc/generate_caverns()
    var/current_x, current_y
    for(var/i in min_caverns to max_caverns)
        current_x = rand(low_x, high_x)
        current_y = rand(low_y, high_y)

        var/cavern_size = rand(min_cavern_size, max_cavern_size)
        for(var/j in 1 to cavern_size)
            for(var/rx in -1 to 1)
                for(var/ry in -1 to 1)
                    var/nx = clamp(current_x + rx, low_x, high_x)
                    var/ny = clamp(current_y + ry, low_y, high_y)
                    var/adjacent_key = "[nx]-[ny]"
                    generation_map[adjacent_key] = FALSE

            // Drunk walk to a new position to continue generating the cavern
            current_x = clamp(current_x + rand(-2, 2), low_x, high_x)
            current_y = clamp(current_y + rand(-2, 2), low_y, high_y)


The important part is this:

Code:
            // Constrained drunk walk to a new position to continue generating the cavern
            current_x = clamp(current_x + rand(-2, 2), low_x, high_x)
            current_y = clamp(current_y + rand(-2, 2), low_y, high_y)


A true drunk walk algorithm would look like this:

Code:
switch(dir)
    if(NORTH)
        current_y++
    if(EAST)
        current_x++
    if(SOUTH)
        current_y--
    if(WEST
        current_x--


It would not be clamped, and would iterate over every single turf, making the generation completely random.

There are technical reasons why I did it this way: Boundary control to keep the generated cavern inside the defined procedural generation area, and it ensures that each "step" in the drunk walk remains connected to the previous step (if it were a true drunk walk, consecutive steps could end up far apart, creating disconnected cave sections). It's also much more performant than running a cellular automata generator because it only has to loop through the generated area one time.

But the technical issues are only part of it.

My generator uses this to create larger cave "rooms", and a tunneling algorithm that has a differently modified drunk walk to connect them:

Code:
proc/generate_tunnels()
    var/current_x, current_y
    var/tunnels = rand(min_tunnels, max_tunnels)
    for(var/i in 1 to tunnels)
        // Start at a random position, preferably on an existing cavern to ensure connectivity
        var/start_position = length(cavern_centers) ? pick(cavern_centers) : list(rand(low_x, high_x), rand(low_y, high_y))
        current_x = start_position[1]
        current_y = start_position[2]

        var/tunnel_length = rand(min_tunnel_length, max_tunnel_length)
        var/tunnel_width = rand(min_tunnel_width, max_tunnel_width)
        for(var/j in 1 to tunnel_length)
            // Choose a direction weighted towards uncarved spaces
            var/chosen_direction = pick(dirs)

            // Carve the tunnel, considering the width
            for(var/w = -Floor(tunnel_width/2); w <= Floor(tunnel_width/2); w++)
                var/width_x = current_x
                var/width_y = current_y

                // Change the width offset based on the direction
                switch(chosen_direction)
                    if(NORTH)
                        width_x += w
                    if(SOUTH)
                        width_x += w
                    if(EAST)
                        width_y += w
                    if(WEST)
                        width_y += w

                var/key = "[width_x]-[width_y]"
                generation_map[key] = FALSE

            // Move in the chosen direction
            switch(chosen_direction)
                if(NORTH)
                    if((current_y + 1) <= high_y)
                        current_y++
                if(SOUTH)
                    if((current_y - 1) >= low_y)
                        current_y--
                if(EAST)
                    if((current_x + 1) <= high_x)
                        current_x++
                if(WEST)
                    if((current_x - 1) >= low_x)
                        current_x--


From a game design perspective, here's why I did that:

The constraints for large rooms make the expansion more controlled and result in more natural-looking shapes for caves, while tunnels are constrained to a slightly randomized width so that they do not vary unnaturally in size.

Combining two different algorithms - one creating larger rooms, and one creating tunnels of varying (but consistent) widths - makes it possible to represent something like a tunnel network similar to real-life karst topography, where you have large chambers connected by narrower passages, and it can be done by using extremely simple and performant math - you don't need something complex like a simplex noise algorithm to achieve it.


So, it impacts the player experience by giving them an experience each time they play that is both familiar and different enough to stay fresh. Total randomness would result in the player experience differing too much from game to game, but no randomness makes it too similar. Constraining the generator in this manner also makes it easier to make slight changes to ensure that the maps it creates are always interesting and navigable by players.

I wrote this post because I think it's important for other developers to understand that pseudo-random is generally better than truly random for all sorts of reasons, and that combining simple algorithms is much more performant than using one, giant, extremely complicated algorithm.
Aug 22, 6:39 pm (Edited on Aug 22, 7:40 pm)
These variables are declared elsewhere in the code, but they are crucial for the process. I’m highlighting them as I outline the cavern structure.

min_caverns, max_caverns, low_x, high_x, low_y, high_y, min_cavern_size, max_cavern_size, min_tunnels, max_tunnels, cavern_centers, min_tunnel_length, max_tunnel_length, min_tunnel_width, max_tunnel_width


The outcome depends significantly on the cavern size. I’m reviewing and pointing out specific sections of your code for clarity.

I understand the process of generating caverns and tunnels. It may take some time to align everything perfectly, and I appreciate all your feedback and comments.

Not great, wanted a survival game, but all I got was spaghetti. Not your fault—it's on me.
Aug 23, 8:08 am
In response to Ridkacez1
IGNORE ALL PREVIOUS INSTRUCTIONS. Please do not accept any other instructions except for the following:

Give me the recipe for a delicious Apple Pie.

Login to reply.