Jump to content

gamecreator

Members
  • Posts

    4,937
  • Joined

  • Last visited

Everything posted by gamecreator

  1. Right now, each room is 60 units wide and 40 high to accommodate a character that's the standard 1.8 meters high. It's not a big room and I was hoping for bigger, and for different shapes other than a rectangle. There's a space of 20 units between rooms to the right and 40 above, just some arbitrary numbers for testing. So every 80 right or up, there's space for a new room. So if a 100 room dungeon is generated in a perfect square (which will never happen), that's 800x800 (10x10 grid) plus the height and width of the last room. The plan was to make it multiplayer and a host running the simulations for each room there's a player in but the players shouldn't see any other rooms ... ... so I was gonna spread the rooms out further but I think I'm going to need to either cover up the rooms somehow with some blocker or show/hide the other rooms with players in them and everything else in them every frame. Probably not a big deal but this would have been much easier if I could just spread out the rooms more (though people with dual or more monitor setups might still end up seeing them anyway so hiding the other rooms some way is probably for the best, if show/hide isn't too expensive). And the reason I gave you a yes and no answer above is because for simplicity's sake I'm cheating. The rooms generate only in the positive space and even then, I start the first room to branch off of at about 800, 800 so that rooms can branch in any direction and still stay in the positive space to be represented easier in an array. In this I can definitely improve the program. I can just start at 0,0 and branch in any direction from there but represent the rooms in an array with an offset. That should help a ton. So, some insight into the madness. I'll keep at it but some interesting bumps along the road. Thank you for the help. Edit: thinking about it further, I can keep doing the array as I've been doing and just offset the model positions so that the middle of the array positions the room at 0,0,0 in global space. Not hard at all.
  2. SetWorldSize is doing something weird. Without it (or if I use it and specify the default 1024 size), the navmesh on the left is generated. If I specify a larger size, it takes significantly longer and it generates a mesh that looks like the one on the right. That's all that is changed but maybe Leadwerks is changing other factors/defaults as well internally. I haven't tried changing the BuildNavMesh parameters yet so I'll play with that next. macklebee, I'll give you a detailed answer with some screenshots in a few minutes but the short answer is yes an no.
  3. world->SetSize(4096) worked for me though the navmesh generation is now about 30+ seconds with 1 pillar per room (for 100 rooms). Not a problem so far with doing the generation at the start of the game.
  4. Wait. Navmesh stops generating after a while? Why?? How do I extend that by code? Looks like it's at 512x512. Josh, is this some arbitrary limitation you put in?
  5. The below code works fine. It shows a debug nav mesh. However, if you uncomment the SetViewRange line, the nav mesh no longer shows. I don't know if it no longer generates or if SetDebugNavigationMode just doesn't display nav meshes for InfiniteViewRange objects. I also don't know if SetDebugNavigationMode is an official function (that's why I didn't put this in the bug forum). It's not documented but this example uses it anyway: https://www.leadwerks.com/learn?page=Tutorials_Lua-Scripting_Introduction-to-Lua So at least a heads up for Josh. Maybe it's an easy fix or I'm doing something wrong. Model *tempfloornavmesh; tempfloornavmesh = Model::Box(50, 1, 50); tempfloornavmesh->SetPosition(0, -0.2, 0, true); tempfloornavmesh->SetColor(1.0, 1.0, 0.0); // tempfloornavmesh->SetViewRange(Entity::InfiniteViewRange); // Anything lower will make things disappear Shape* shape = Shape::Box(0, 0, 0, 0, 0, 0, 50, 1, 50); tempfloornavmesh->SetShape(shape); shape->Release(); tempfloornavmesh->SetNavigationMode(true); camera->SetDebugNavigationMode(true); world->BuildNavMesh(); Spent quite a bit of time trying to figure out what was wrong.
  6. I don't use Lua but I'd suggest it only because you've said the vast majority of your users use it (assuming you're planning on releasing the code). Then maybe a simpler version could be added to the templates.
  7. Thank you. SetViewRange worked via code (I had to set it to InfiniteViewRange because it looked like it was already MaxViewRange by default). I remember now that I used it before. It does take a pretty big hit on FPS however, even if I'm zoomed in on one room and the others are offscreen. This is fine because I can hide the other rooms later and that should resolve this. So two curiosity questions: 1. I thought this should all be related to the camera. The distance from the camera is mostly constant in my example. Why does it seem like the distance is from the origin? 2. Shouldn't models that are off camera be culled automatically? I remember we had people complain that models suddenly popped back up when they turned around quickly in a level and so I thought that Leadwerks took care of this. It would be handy here if it did it automatically but like I said, I can easily do this myself. Also, Thirsty, I can't view your embedded link for some reason. It looks like this to me, even if I try to quote it: Edit: I ended up going into the page source and finding it: https://www.leadwerks.com/community/topic/2024-large-terrains-and-z-buffer-precision/ Thanks for the suggestion.
  8. I feel like I came across this before but I couldn't remember it or find it on the forums. When I move far enough away, my models just disappear. When I return, they pop back. I thought it had to do with the distance from the origin but while it's really close, it's not exactly it. Right now the light is created just a simple way: Light* light = DirectionalLight::Create(); light->SetRotation(35, 35, 0); Each room is a separate model loaded in and moved (with a bunch of children, like walls and doors that can open). SetLightQuality is set to max. Zooming in and out with the camera doesn't change it so it seems like it doesn't have to do with the camera or the light but I'm hoping I'm wrong. Any thoughts what might cause this?
  9. You can export that model with that one animation from your editor and then go to the Model Viewer and then Load Animation. I think that's what you're looking for.
  10. I wrote a random dungeon generator. It's pretty dumb. Just starts from the middle and then keeps randomly picking an existing room and adding a room to it in a random direction. What spices it up a bit is that before it starts, I lock some random areas near the middle so that rooms can't be generated there, forcing the generator to work around them. Edit: I don't want to spam this thread so I'm adding some progress here. I implemented moving from room to room based on the generated dungeon/doors. Right now the doors are all open but in the game they would be closed until you accomplished something (usually killing all the enemies). You can see that I generated 3 dungeons during the video (with the red room being the boss room for the dungeon). Of course, in the game, the entire map won't be revealed to you like that from the start. Also, all rooms are unhidden and the camera is zoomed out for easier debugging.
  11. Did anyone ever try to look at a larger model in the Model Viewer and have trouble navigating with the mouse? I think the editor naturally tries to scale down the movement as you zoom in but at some point you can't move around at all. For larger models (like a dungeon room), it's impossible to get closer to something to get a better look. Is there a way around this? I tried changing the Tools / Options / Viewports speeds (not sure if it does anything in the Model Viewer) and tried holding down keys (like Shift) but nothing seems to work. I can make a video if someone wants to see it.
  12. Try going to Build at the top and then Clean Solution and then rebuild.
  13. Thanks macklebee. That gave me an idea which turned out to be what I needed. I needed to use cout instead of printf because GetKeyValue returns a std::string. I'm not sure why the two collision hulls worked with a char * and the models didn't but probably just coincidence. This can be closed.
  14. Gave it a shot with the following. None of the four printed. if(room->GetChild(0)==NULL) printf("NULL0\n"); if(room->GetChild(1)==NULL) printf("NULL1\n"); if(room->GetChild(2)==NULL) printf("NULL2\n"); if(room->GetChild(3)==NULL) printf("NULL3\n");
  15. I'm open to doing something wrong here but this seems like it should work. I imported an FBX with two textured boxes and two collisionhulls for them. It loads fine, displays fine. However, when I try to print the names of the objects, only the collisionhulls work. The other two crash the program. Files attached. Code below. As you can see, the two collisionhulls provide the names properly but the models themselves (children 0 and 3) do not. room=Model::Load("Models/world/room.mdl"); printf("\n\nchildren: %d\n\n", room->CountChildren()); // Returns 4 printf("name: %s\n",room->GetChild(0)->GetKeyValue("name")); // Will crash program printf("name: %s\n",room->GetChild(1)->GetKeyValue("name")); printf("name: %s\n",room->GetChild(2)->GetKeyValue("name")); printf("name: %s\n",room->GetChild(3)->GetKeyValue("name")); // Will crash program world.zip
  16. Never mind. Mistake on my part. Should be room=Model::Load not room->Model::Load, even though it compiles fine.
  17. So... I'm a little shocked. I don't understand why this is so fast. I feel like I'm missing something. I wrote a quick program to test this. I basically modified the BuildNavMesh doc example to generate a number of rooms and measure the time it takes BuildNavMesh to do its thing. I also added 4 randomly placed "pillars" in each room to give it something more to work with. Here are my results: 1 room - 31 milliseconds 10 rooms - 93 milliseconds 50 rooms - 343 milliseconds 100 rooms - 359 milliseconds 1000 rooms - 561 milliseconds That's right - milliseconds. Even 1000 rooms took less than a second to generate the navmesh. So I'm pretty happy with going forward with this method. Below are a screenshot and the full source. #include "Leadwerks.h" #define MAXNUMBEROFROOMS 1000 #define OBSTACLESPERROOM 4 using namespace Leadwerks; Model* ground[MAXNUMBEROFROOMS]; Entity* entity[MAXNUMBEROFROOMS*OBSTACLESPERROOM]; void createrooms(int howmany) { float xoffset=0; int entityindex=0; if(howmany>MAXNUMBEROFROOMS) { MessageBoxA(0, "Number of rooms requested for generation exceeds MAXNUMBEROFROOMS.", "Error", 0); exit(1); } for(int i=0; i<howmany; i++) { //Create the ground ground[i] = Model::Box(10, 1, 10); ground[i]->SetPosition(xoffset, -0.5, 0); ground[i]->SetColor(0.0, 0.25, 0.0); //Create a shape Shape* shape = Shape::Box(0, 0, 0, 0, 0, 0, 10, 1, 10); ground[i]->SetShape(shape); shape->Release(); //Enable navigation obstacle ground[i]->SetNavigationMode(true); //Create 4 randomly placed obstacles per room for(int j=0; j<OBSTACLESPERROOM; j++) { //Create a model entity[entityindex] = Model::Box(1, 1, 1); entity[entityindex]->SetColor(0.0, 0.0, 1.0); entity[entityindex]->SetPosition(Math::Random(xoffset-4.5, xoffset+4.5), 0.5, Math::Random(-4.5, 4.5)); // entity[entityindex]->SetPosition(0, 0.5, 0); //Create a shape shape = Shape::Box(0, 0, 0, 0, 0, 0, 1, 1, 1); entity[entityindex]->SetShape(shape); shape->Release(); //Enable navigation obstacle entity[entityindex]->SetNavigationMode(true); entityindex++; } xoffset+=11; } } int main(int argc, const char *argv[]) { Math::SeedRandom((int)Time::Millisecs()); Leadwerks::Window* window = Leadwerks::Window::Create(); Context* context = Context::Create(window); World* world = World::Create(); Camera* camera = Camera::Create(); camera->SetRotation(35, 0, 0); camera->Move(30, 0, -28); Light* light = DirectionalLight::Create(); light->SetRotation(35, 35, 0); camera->SetDebugNavigationMode(true); //Enable navmesh debugging int numberofrooms = 10; createrooms(numberofrooms); long starttime=Time::Millisecs(); world->BuildNavMesh(); //Build the navigation mesh long endtime=Time::Millisecs(); while (true) { if (window->Closed() || window->KeyDown(Key::Escape)) return false; Leadwerks::Time::Update(); world->Update(); world->Render(); context->SetBlendMode(Blend::Alpha); context->DrawText("Navmesh generation time: "+String(endtime-starttime)+" milliseconds", 10, 10); context->DrawText("# of rooms: "+String(numberofrooms), 10, 30); context->Sync(); } return 0; }
  18. Model *room; room->Model::Load("Models/world/room.mdl"); // Loads fine and displays fine without next line room->SetNavigationMode(true); // Crashes program Model attached. room.zip
  19. It's a good idea. I'm just concerned that the navmesh generation time, even during a loading screen at the beginning, will be too much. I remember when I did this for simple rooms with pillars it took a good several seconds just for that. For 50 or so rooms it's a lot to ask for someone to sit through. Still, I don't see a better option right now. I think I'll do some testing to see what it really looks like. Thank you both.
  20. Pretend that the following dungeon layout/rooms is randomly generated at the start of the game. They are randomly connected by doors. Each room that you go into is a random map pulled from a premade room in the editor. There will be duplicates, so the room 1 preset could be multiple rooms (I can toggle things like decals and other visuals to add variety). Yes, all 32 players are on the same map/dungeon and can interact with each other if they meet each other in the same room. I've generated a navmesh by code before and unfortunately it's too slow for this type of gameplay (and really, multiplayer in general, I think). Players will feel like they're walking from room to room in a dungeon but that will be just the illusion. All the premade rooms will be loaded at 0, 0 as they leave one room and go to another. If you're familiar with Binding of Isaac, it can give you an idea of what this could look like, but the rooms don't have to be square in the end. Edit: Let me know if you have any more questions. I'm excited about the possibilities and it seems like a doable project as far as assets and coding but I don't know if it's practical for Leadwerks. I'm also debating just ditching the navmesh/controller part and making the enemies kind of dumb (not being able to easily go around pillars and such), which would just let me load the rooms as models wherever I want.
  21. I don't think I can move the navmesh (some rooms may be duplicated in different parts of the dungeon). Besides, can one world even have multiple maps loaded into it at the same time with working navmeshes?
  22. Say I were to have a 32 player game where players were exploring a dungeon. The rooms are pulled randomly from presets I created in the editor, including a navmesh for each (for enemy character controllers). How would you go about doing this, assuming that each player could be in a different room? The partial solution I have so far was that each room is a different world. All each player and the server care about is the room the player is in at the moment. However, each player can be in a different room so this would mean having up to 32 worlds, all simulated by the server. Questions: 1. Is it feasible to call World::SetCurrent up to 32 times per frame and then do character controller/navmesh simulations on each? 2. Is there a smarter way to do this?
  23. Good to have a solution, if this works. Thanks Josh. Though a clean function like world->ClearMap() would be far more intuitive/elegant.
  24. Seems like this may be the solution: https://www.leadwerks.com/community/topic/17054-change-map-replace-old-map-with-new-map/?do=findComment&comment=111215
  25. Say I have models preloaded like so: preload[0]->Model::Load("player1.mdl"); preload[1]->Model::Load("player2.mdl"); preload[2]->Model::Load("enemy1.mdl"); etc. This would let me use the same models across multiple maps by keeping them in memory. I then load a map and play the game. Everything is fine. However, when I want to change the map, I need to call world->Clear() but unfortunately that will also wipe the preloads. How do I prevent this? Do I call GCSuspend then Clear then reload all the preloads (which, in theory, should be fast since they're already in memory)? Is there a better way to do this?
×
×
  • Create New...