Viata
Arcane
I have this problem with programing, I feel like if we have 1000 objects, it's already too much and things will take longer to run. I keep forgetting I'm not working on a MSX anymore.Why would 1000 tiles be bad?
I have this problem with programing, I feel like if we have 1000 objects, it's already too much and things will take longer to run. I keep forgetting I'm not working on a MSX anymore.Why would 1000 tiles be bad?
Lance, you seem to know your programming, I have a simple but important question I'd like to ask you.
How did you generate all of these hexes (or square tiles) on the screen? I mean, what are they? Just some graphical overlay? Still impressive.
When I think of making an RPG with tiles, I think of having like 1000 game objects each representing individual tiles, and that seems bad. But you just have pathfinding, and the tiles on the ground and it seems great. What method is that? And how powerful are these tiles to contain game data?
That's pretty much it. I try to keep loading time down as much as possible, I'm in the habit of just loading everything into a tilemap and we're good to go.then the only downside is file size and loading time
Thanks RobotSquirrel and Lance. I have very little experience with large containers of data, I tend to keep things separate.It is bad. Each of the "Tiles" are a uniform size meaning you can just use simple position values instead of individual objects. You'd only ever draw the objects for debug.When I think of making an RPG with tiles, I think of having like 1000 game objects each representing individual tiles, and that seems bad.
My suspicion on lance's implementation is he's using rays to find the height of each tile and to determine if the ray is inside a collider or not and if the tile is imperfect. Its pretty damn impressive though, I've not really seen a lot of people try to do that they usually stick to just using a tilemap for everything.
The player wouldn't continuously send their position, you'd only check the position to when a player or character requested a move, then you would calculate A* because A* is computationally expensive as it predicts the moves the player will make step by step testing all adjacent tiles. Basically the data just sits there until its needed its not always running. Its important as good practice to only ever run bits of code when it is 100% crucial that the code runs, otherwise you're just wasting CPU this is why its considered generally bad practice to run a function on a frame update especially if you never turn it off you only do it if you really have to have that updating every frame, most of the time you won't need that a simple input trigger will be enough. When the player clicks then run the loop, it doesn't have to be run every frame.Or, maybe the player is continuously sending his position to the container, and the container is able to catalog that data into the right tile? It sounds bad to me because it requires the game objects to constantly send updates of their positions to some central tilemap.
Honestly sounds a bit overkill. You wouldn't have to use raycasts because the position of each tile aligns to the normal of each tile anyway there's no need to have a separate raycast - when I meantioned that I Was specifically referring to map generation not runtime. You would need raycasts to check if the tile is intersecting a mesh's collider that isn't aligned to the grid - then you'd turn the colliders off when you were done as they are no longer needed the grid automatically does collisions.Can you generate 1000 raycasts that just stand up continuously and are able to intercept the player?
Yeah of course it depends how it all ravels out but to be needlessly worried about "1000" loops is kinda silly. That was something I used to think about in 1996 but even then...I have this problem with programing, I feel like if we have 1000 objects, it's already too much and things will take longer to run. I keep forgetting I'm not working on a MSX anymore.Why would 1000 tiles be bad?
You just take a regular A* algorithm and tweak it as needed. Before deciding whether to explore a hex, you check to see whether it's passable. You just need to make the extra information available to the individual nodes. I used A* in Himeko Sutori and it worked great:I should say that my tiles are a bit different. They have dynamic data. Like, the 'cost' of moving to a certain tile is not fixed in advance, it depends on what is currently placed on that tile, that's why we need a method of having the object on top of a tile (such as a door that's closed or open, or a wall, or a person) to somehow collide with the tile and give it data.
And a Fallout-like game needs it too. There are no static navmeshes or navigation tiles; since other characters, at minimum, can move on them, and the tiles need to then update their move costs reflecting that a character is standing on them. Any navigation system will require your tiles to have dynamic data, which tracks what is colliding with them in real time, or what is on top of them.
Some kind of collision detection is needed, and I just don't find any solutions outside of an update loop, which seems bad, or a individual collider box for every single tile.
No colliders necessary.I should say that my tiles are a bit different. They have dynamic data. Like, the 'cost' of moving to a certain tile is not fixed in advance, it depends on what is currently placed on that tile, that's why we need a method of having the object on top of a tile (such as a door that's closed or open, or a wall, or a person) to somehow collide with the tile and give it data.
And a Fallout-like game needs it too. There are no static navmeshes or navigation tiles; since other characters, at minimum, can move on them, and the tiles need to then update their move costs reflecting that a character is standing on them. Any navigation system will require your tiles to have dynamic data, which tracks what is colliding with them in real time, or what is on top of them.
Some kind of collision detection is needed, and I just don't find any solutions outside of an update loop, which seems bad, or a individual collider box for every single tile.
Have a happy new year, game devs.
I just did a thing.
Posts like this take time and I don't know if they'll result in more customers seeing my game. It's kind of like how I mostly talk about my game in development forums (like this thread), and talking to other game developers doesn't really put me in front of my target audience. I guess we'll see if posts like this get any engagement, and maybe I'll do some more.
Always found that annoying that doing something in secret inflicted reputational losses. If nobody sees you do it, how could it? I hope you make some checks for that.a specific party member to be able to lockpick. That will negatively affect your standing
The karma system is more for your character's actions and sort of how they carry themselves. I don't have anything like a reputation system or guards/fines or anything like that. It's more of the actions you take reflecting on your personality. If that makes sense. There are NPCs that might mention something about how you don't seem like a nice person, or something along those lines, but it's not like they know you've been breaking into people's houses.Always found that annoying that doing something in secret inflicted reputational losses. If nobody sees you do it, how could it? I hope you make some checks for that.a specific party member to be able to lockpick. That will negatively affect your standing
The channel has got some interesting videos. Mostly consisting of retro techniques for 2d.
there is 0xffffffff point to craft an isometric 2d engine anno 24This took far longer than it should
Thanks I never thought of that, I'll look into it.I think if you used a CRT shader with scanlines, it would look about 10 times better.