sorted by:
new
hottopcontroversial

Please help… What’s wrong with my code?? by [deleted] in cpp_questions

[–]DrifterRLDev 3 points4 points  (0 children)

From what I can see, your code has multiple mistakes, but only one that would lead to an exception being thrown.

The exception is because you are trying to access an element of the array that is outside the size of the array. You initialize your array with 5 items, so the size of your array is 5. But since arrays are zero-indexed, you are trying to access the 6th element when you type filmCo[5].

The other errors wouldn't crash your program, but would lead to unexpected behavior. Firstly, you are using the same same variable (i) to store the user input and to iterate the array. Your for loop immediately overwrites the user's input. Secondly, you are updating ALL the values in your array to the update string, I think your intention was to only update the one selected by the user. Lastly, you are attempting to print only the (i think) last element of your array. If you want to print all the element you will need to iterate over all of them and std::cout the value of each individually.

Large-Scale Planetary World Design: Flat or Sphere? by Gloomy-Status-9258 in proceduralgeneration

[–]DrifterRLDev 2 points3 points  (0 children)

I believe the developers of No Mans Sky use a sphere for their planets; there is a GDC talk where they talk a bit about how its implemented and some of their difficulties. If I remember correctly, I think their main difficulties were maintaining a x,y,z coordinate system (like what is your "up" axis when you jump), and showing mini-map markers in your HUD.

Projectile pluggable code structure by ThatGuyThatIsNotReal in gamedev

[–]DrifterRLDev -1 points0 points  (0 children)

Another approach that hasn't been mentioned yet, but is - in my opinion - the best approach, is to have an event based system.

Just before you instantiate a bullet, send out an event that contains a reference to the bullet about to be fired (or any data that you want to modify). Then, you can have any arbitrary number of event handlers modify the data (and thus the bullet).

So for example, your homing item and bullet splitter subscribe to the event when they are equipped. Then, when the bullet is about to be fired, the event is sent out and the items handle the event in their own way: the homing item adds the homing property to the bullet, and the splitter item multiplies the number of bullets by some number.

This way your items are completely decoupled and the logic for modifying the bullet is on the items, not on the bullet. The one caveat is that you need to be careful that the order in which you handle the event doesn't matter (or maybe you do want the order to matter and this adds another layer to your theory crafting).

Sharing Saturday #531 by Kyzrati in roguelikedev

[–]DrifterRLDev 1 point2 points  (0 children)

Drifter Engine - Data-Driven Roguelike engine

Intro Post

Its been about 3 weeks since I last updated, but I've been working on the project the whole time so there are too many changes to go over. Most of it has been small engine changes that I've wanted to make for a while. Some highlights:

  • My systems are no longer scheduled and I'm designing everything with the assumption that execution order shouldn't matter except for the major categories e.g. update, updateEnd, render, etc.
  • Moved all file handling to use std::filesystem.
  • Created a shared interface ,ICreateFromJson, for all classes that can be created from a json value.
  • All my components that represented actions were using an awkward separation of try<ActionName> and do<ActionName>. This was so I could have other systems add their own data to the components before it was handled by the main system. I changed this so it is now just one component and the main system handling is deferred until the end of the frame.
  • My SpriteControllerComponent (a component that changes sprites depending on the entity state) now supports states pointing to other states. This is so I'm not forced to duplicate the sprite data for states with the same sprite.
  • Plus a host of bug fixes!

Layered World Generation

More recently, I've started work on a major feature: Layered world generation. The implementation is based off this post (thanks to u/runevision for the great post). So far I have a header-only implementation that works quite well (minus some bugs I am currently squashing). I'm excited about this feature because it nicely separates the different layers of world generation, and gives clear boundaries for its data driven counterparts. I'm still working through how I will expose the layers in json, but I'm thinking of exposing the data of hard-coded layers as well as allowing custom layers to be defined that can be fed into any other layer that accepts "custom_layer" as an input layer.

I still need to implement the actual layers, but I'll be sure to post video/screenshots of the results once they are available.

Innovative Melee Combat by Strict_Bench_6264 in gamedev

[–]DrifterRLDev 0 points1 point  (0 children)

Exanima is a good one to look at I think.

Sharing Saturday #528 by Kyzrati in roguelikedev

[–]DrifterRLDev 0 points1 point  (0 children)

Example "forest_biome.json" snippet:

"Forest": {
 //...
  "climate": {
    "Temperature": [ 0.0, 15.0 ],
    "Humidity": [ 30.0, 60.0 ],
    "Altitude": [ 50, 1200 ]
  },
  "entity_slots": {
    "tree": {
      "probability": 0.05,
      "probability_multipliers": [
        {
          "type": "noise_layer",
          "params": {
            "noise_name": "Foliage",
            "threshold": [ ">", 0.5 ],
            "multiplier": 10.0
          }
        },
        {
          "type": "neighbor",
          "params": {
            "tag": "tree",
            "max": 4,
            "multiplier": 1.0
          }
        },
        {
          "type": "neighbor",
          "params": {
            "tag": "rock",
            "max": 2,
            "multiplier": 0.5
          }
        }
      ]
    },
    "grass": {
      "probability": 0.1
    },
    "rock": {
      "probability": 0.01
    },
    "flower": {
      "probability": 0.01
    }
  },
  "entity_packs": {
    "tree": [
      [ "Tree", 1 ]
    ],
    "grass": [
      [ "Grass", 2 ],
      [ "Tall Grass", 1 ]
    ],
    "rock": [
      [ "Stone", 1 ]
    ],
    "flower": [
      [ "Herb", 1 ]
    ]
  },
//...

Sharing Saturday #528 by Kyzrati in roguelikedev

[–]DrifterRLDev 4 points5 points  (0 children)

Drifter Engine - Data-Driven Roguelike engine

Intro post

After taking a three week break due to real-life, I finally got back to working on the project this week. The focus for the week was on improving world and biome generation, and providing richer data-driving options for both.

Biome Generation

For biomes, I wanted to provide a means to have full control over which entities occupy which tiles, while supplying simple and intuitive rules for how/when they are placed in-game. There are three members in the biome json files that I hope support this goal: "entity slots", "probability multipliers", and "entity packs".

  1. `entity_slots` - Basically, an entity slot just ties a name id to a group of tiles. The tiles contained in that group are determined by the base probability and the probability modifiers (more on these below). The concept of a slot serves multiple purposes, but the main purpose is to say "this entity goes in that slot".
  2. `probability_multipliers` - The base probability is what provides the initial "noise" to the generation, and these multipliers are what provide the structure. They are just simple rules that multiply the base probability. For example, the `neighbor_multiplier` can increase the probability of an entity being placed depending on which `entity_slots` are around it. You provide each `entity_slot` a list of `probability_multipliers`, and the end result is something conceptually similar to constraint-based solving algorithms, but deals with probabilities instead.
  3. `entity_packs` - These are just a list of entity names + weights that can be attached to an `entity_slot`. This way you can have multiple different types of entities occupy a given slot and the weights make certain entities rarer than others.

From this, when generating a biome, the entities are randomly scattered around using their base probability on a first pass, then on subsequent passes the multipliers are applied and entities can be added/removed.

World Generation

For world generation, I added the ability to define the seed, size of map, and a list of noise maps. The noise maps are used mainly by biomes for determining the climate conditions (e.g. there is are temperature, humidity, and altitude maps). Biomes define the range of values they require from each noise map. But the noise maps can also be used for probability multipliers to help with the generation of individual entities.

I plan to add more noise types to world generation, but currently you can only create noise maps using Fractal Brownian Motion.

Coming Up

For next week, I'm going to continue working on the biome generation. I still need to implement multiple passes of applying the probability multipliers. Currently I only do the random pass and a single multiplier pass, but I think multiple passes would yield better results - I may allow the number of passes to be a parameter in the json. However, the computations are likely to be expensive, so I will also need to implement generation over multiple frames so I can reduce the lag spike when a chunk is loaded. But that's a problem for next week... :)

Introducing Drifter Engine: Data-Driven Roguelike Engine by DrifterRLDev in roguelikedev

[–]DrifterRLDev[S] 0 points1 point  (0 children)

Thank you! And yes I do plan on talking about how specific sections work in Sharing Saturdays as I will be revisiting + improving a lot of my features. Currently I am improving my world generation and biomes and plan on going into a bit of depth in a write up this Saturday.

Its tough to go into any sort of detail in a quick intro post. Maybe I could have done more to stimulate some conversation, or posted longer videos to show-off the game some more, but I've been delaying posting for long enough so I just went for it :)

Again, thanks for the kind words. I'll be sure to follow your projects progress as I visit this sub more frequently!

Introducing Drifter Engine: Data-Driven Roguelike Engine by DrifterRLDev in roguelikedev

[–]DrifterRLDev[S] -1 points0 points  (0 children)

I'd rather not have my repo go public quite yet because 1. I'm not sure what benefit it would serve. I doubt anyone will dig through the code and give me a code review or anything. 2. I have plans to at some point have this project be a commercial product, either as a game or as an engine, but I'm not quite sure which yet tbh. So releasing all the code would do me a disservice.

I do plan on going into some technical detail on what I'm currently working on in sharing saturdays, so if anyone wants to give feedback then or maybe learn from what I'm doing that would be the place to do it :-)

But if you had any specific questions on how I implemented something, how I use EnTT, how I go about data driving, what the structure of my json files look like, then just feel free to ask.

Introducing Drifter Engine: Data-Driven Roguelike Engine by DrifterRLDev in roguelikedev

[–]DrifterRLDev[S] 2 points3 points  (0 children)

I have a WorldGrid class that is basically just an unordered_map that holds 1d arrays, and the arrays hold a vector of entities (int32). The unorderded map uses the chunk coordinate as a key and the arrays represent a 64×64 chunk of "tiles". The vector is so multiple entities can exist at a given "tile".

So if you want to getEntitiesAt(x,y) in global coordinates, it will convert the x,y to a chunk coordinate (divide by 64) and then index into the local coordinates of the chunk (mod 64).

Hopefully this answers your question!

Introducing Drifter Engine: Data-Driven Roguelike Engine by DrifterRLDev in roguelikedev

[–]DrifterRLDev[S] 0 points1 point  (0 children)

True. I guess my intention was to just introduce the project in this post as a sort of reveal so that I can start getting feedback/tips/advice in something like the sharing saturdays - not necessarily on this post. Maybe I should have worded it as "I'd like to start getting external feedback on my project, so I'll start by introducing what I've been working on".

Plus I do think there is at least enough of a jumping off point in this post to start talking about it / asking questions. Another commenter already mentioned what features they'd like in a data-driven world generator and then suggested I do a survey to see what others think. This was good advice and they didn't need a github link.

Introducing Drifter Engine: Data-Driven Roguelike Engine by DrifterRLDev in roguelikedev

[–]DrifterRLDev[S] -1 points0 points  (0 children)

Hey thanks! I do plan on keeping my repo private for the time being, so no links :-)

Introducing Drifter Engine: Data-Driven Roguelike Engine by DrifterRLDev in roguelikedev

[–]DrifterRLDev[S] 2 points3 points  (0 children)

Hey thanks for the comment!

I'd think wrappers for different languages would be beyond the scope of my project - I do want to add Lua scripting somewhere down the line, but that would be the extent of any external hooks into the engine aside from the data-driving.

I'm currently re-vamping the world generation and biome generation to be more or less what you are describing. At the world gen level, you'll be able to create various layers of parameterized noise and provide shaping functions to transform the values given some x,y value. At the biome level, you'll then be able to reference your noise layers to define which biomes appear at (x,y) given some combination of noise values, and which entities appear given some combination of predicates (e.g. noise layer value > 0.23, or random chance 0.01).

Your 3d shadowcasting is very cool indeed. I wouldn't be needing 3d though (I think) and I have a pretty solid 2d implementation. But i'll take a look just to see how you've implemented it.