gz_bigcity - A city sandbox map

[inkoalawetrust]

Hello everyone, this is my first thread on this forum that isn't bug report or feature request. However this is far more my first map, as I've made several dozen maps since 2019. Though I've only released about 3 of them, but I may release more maps. But this thread isn't about those maps or my previous posts.

LINK TO THE DOOMWORLD RELEASE THREAD



What is this map about ?:

This map is meant to simply be an urban city sandbox for people to mess around and test things in. It does not have any gameplay of it's own, or hordes of demons for you to shoot, or items to pick up. Unless you spawn them in through the console or place them into the map with a map editor of course.

The map can be useful for doing things such as testing out your mods and projects in a proper game environment, that is closer to what the mod will be getting used on than a bunch of STARTAN2 boxes and rectangles are. In fact this map was originally just made to showcase and test my mods in a more visually interesting and complex environment than said boxes. Or you can use it as a sandbox to screw in much like the GMod map it's named after.

Features:

Now you may be asking yourself. "Well that's nice and all. But is there anything else to see or do on this map besides testing mods or fucking around ?". Well I'm glad you asked, me. You can also just explore and look around the map ! Here's a list of some of the maps' features:

• Looks nice and is fairly detailed.
• Has background ambience in place of music. Except for some of the interiors.
• Multiple player starts to play with you and the boys. (No idea if they work though, but I don't see why they wouldn't.)
• Is very large and open ended, with plenty of space, especially in the city square.
• Has cool scrolling clouds above the map. That move in a random angle and speed on every map startup.
• Very detailed and seamless 3D skybox, that is about as close to a Source engine 3D skybox as you can get in (GZ)Doom.
• Several 3D models all entirely made by me for the map. Some of them even display random things, on them, namely the billboards and office PCs.
• A cool moving 3D train, that randomly runs across the map and can run you over.
• A scripted camera system that you can enter and look across multiple cameras through, it can be found in the supermarket.
• Custom F1 help screen in case you need info or help.
• Several of the props found around the map can be broken and destroyed.
• 5 interiors: The gas station, AGM office, underground parking lot, warehouse, and supermarket. I may add more interiors in updates.
• Easter eggs, some just appear on the map, others you have to do something to get.
• Really good performance

Screenshots:

---

A view of the forest at the north of the city.

The road crossing you start on.

The supermarket.

The city square.

Another shot of the city.

One of the back alleyways.

The gas station.

And at last, but not least, the underground parking lot.

Full resolution screenshots and the thread banner can be found in this Imgur album.

How to play:

To play, you just need to extract all three archives to a folder, then run gz_bigcity.pk3 in GZDoom, and the other two resource archives should be automatically loaded as long as they are in the same directory. Once you are in the main menu, just pick the "Sandbox" episode on the episode select screen. And that should be it.

Map information and requirements:

Source port: The map will only run on GZDoom and maybe LZDoom, though I haven't tested that one. It definitely will NOT work with Zandronum though, and there's no way to make it do so without removing a lot of features.
Map format: GZDoom UDMF
IWAD: Doom 2
Maps: OPENCITY is the only map included. So no vanilla Doom 2 maps are replaced.

The map will ONLY run on the OpenGL or Vulkan hardware renderers, I tried running it with software once, and GZDoom just crashed. The map will also probably run a bit slow on weak PCs due to how big and open ended it is.

V DOWNLOAD LINK V

https://drive.google.com/file/d/1vrG7mh ... sp=sharing

Changelog:

Version 1.1.5:

NOTE: It seems that the map is even closer to hitting GZDoom's limits that I thought. As making the new small city monument out of sectors caused ZSBSP to corrupt the map every time it tried building the nodes. So the mini city model had to be made into a 3D model.

• Replaced the pillar on the city square with a mini model of the city.
• Updated the map facts sign to reflect the latest public version of the map.
• Fixed misaligned ceiling flat in the AGM office.
• Removed unused and debug ACS code.
• The linedefs on the gas station and supermarket windows and doors now block projectiles too. They did also do that before, somehow. But now I added the dedicated flag for that too.
• Significantly reduced the amount of trees on the map. Hopefully this will make things a bit faster.
• The train now honks sometimes when passing through the map.
• Added the NotAutoaimed flag on the actors used for the gas station roofs.

Version 1.1 (The version released when I made this thread.):

• Removed unused sprites, textures, and actors. Like the broken and unusable glass I had made for the gas station.
• Updated some code comments to match the current iteration of the code they are for.
• Added editor keys to the grey metal barrel prop.
• Optimized the PNG textures used by the models, not sure how I forgot to do that before releasing the map.
• Added a new desktop that can appear on the office computers.
• Slightly raised one of the buildings behind the supermarket.
• Removed unused defined camera textures, originally the supermarket camera system would just be one monitor for each camera, but that was WAY too inefficient for performance, so I had to make the scripted fullscreen switchable camera instead.
• Fixed the trash can lid so it appears again when the trash can is destroyed.
• Added credits to Cherno for the SimSun shader my models use, I forgot to add credit because the shader was a completely last minute addition.
• On the subject of the shader, the computer monitors no longer use it, so they appear brighter again.
• Added FreeDoom door textures on the front doors of the AGM office. And added FreeDoom door sounds on the whole office area.
• Added siren sounds to the police cars around the map.
• Made a wall that could be climbed to get out of bounds impassable by players.

Version 1.01:

• Renamed the voxel model for the desert tank in the Voxel Vehicles PK3 from STANA0 to STANAO0-LOL, to stop sprite conflicts with Project Brutality's first person leg sprites. So no more tank legs.
• Renamed the trash can sprites from TRAC to GARB, and the wood splinter sprites from WSPL to SPLI, both to prevent more sprite conflicts with Project Brutality.

STANDALONE MAP PROP ASSET PACK:

I have also decided to release the urban props I've made as a standalone pack that can be used for your maps. Besides the assets I've entirely made myself, it also includes the props whose sprites are originally from Realm667 such as the trashcans, but which I've made a lot of changes to, like new code and sprites for them. I've also added some comments explaining how to add more graphics that randomly appear on the billboard and PC models.

However some things that only make sense and work in the context of the gz_bigcity map have been removed such as:

• The "I am with stupid" UAC graphic doesn't appear on the billboard, since it's a joke that makes sense only in the context of the map*.
• The easter egg desktop texture on the PC that is literally my own PCs' desktop has been removed. Since it's a joke specifically tied to me, the easter egg desktop that is a recursive screenshot of the PC model in Blender is still kept though.
• The train model is only a static prop in the pack. Since the mechanism by which it moves in gz_bigcity is incredibly hardcoded and tied to the map itself.

Also, here are some renders of all the prop models I've made for the map:

---

All the relatively small props I made for gz_bigcity. The fire hydrant is used on the map as a sprite prop.

The billboard model.

The train model.

V DOWNLOAD LINK (SEPERATE PACK OF THE MAPS' PROPS) V

https://drive.google.com/file/d/1Gp2hsd ... sp=sharing

*

---

The UAC office building is just a bit further down the street from the AGM building.

[Caligari87]

Is there a specific load order for this? I can't seem to get it to like the props, just a bunch of Unknown Objects everywhere.

EDIT: Nevermind, I was loading from the terminal and forgot to account for the space in the voxels filename.

This is quite nice! Lags a bit for me in places but I love the style

[TommyGalano5]

hey hey! its finally released the style and damn the overall style is love it and by using models and voxels sparingly is pretty nice although it tends to lag my playthrough a bit in certain areas of the msp (as Caligari has mentioned) overall it's nice to see a detailed city map again that has a semi-realistic feel to it

(and now i can see my damn texture work)

[kalensar]

All I'm going to say is that most of your lag issues are coming from your 3D Sky Box event handler. I tried to edit it to test this hypothesis, but just couldn't quite get it unwound from the map mod itself, But i 85% guarantee that would solve most of the lag issues. A mod size of 22mb is hardly anything that should be causing this kind of lag because I've played and edited maps that are just crazy in detail and have ZERO lag.

[Rachael]

Without doing some deep and intense profiling of the map and all of its parts, recording the timing of specific things, I doubt you could say such things with any such certainty.

Particularly when people say "it lags in certain parts" - that clearly says to me it's a BSP-walking issue (which is extremely common with detailed complex maps such as this) and that has nothing to do with the 3D sky box event handler. I looked at it myself - there's nothing there that would cause any notable lag.

The simple fact of the matter is, is that the Doom engine (and certainly GZDoom) is not designed to handle wide-open area maps like this, at all. It has never handled them gracefully - ever. So - maybe you should consider that the accomplishment here, instead, is that the author has actually managed to reduce lag as much as they have, making most of the map playable on rather modest systems, rather than pointing out un-prove-able red herrings as to why you think it lags.

[kalensar]

Without doing some deep and intense profiling of the map and all of its parts, recording the timing of specific things, I doubt you could say such things with any such certainty.

Particularly when people say "it lags in certain parts" - that clearly says to me it's a BSP-walking issue (which is extremely common with detailed complex maps such as this) and that has nothing to do with the 3D sky box event handler. I looked at it myself - there's nothing there that would cause any notable lag.

The simple fact of the matter is, is that the Doom engine (and certainly GZDoom) is not designed to handle wide-open area maps like this, at all. It has never handled them gracefully - ever. So - maybe you should consider that the accomplishment here, instead, is that the author has actually managed to reduce lag as much as they have, making most of the map playable on rather modest systems, rather than pointing out un-prove-able red herrings as to why you think it lags.

Don't take this as a rebuttle please.

I have an active history of troubleshooting both GZDoom Maps and Mods. I run on a low-ish end machine and have a knack for getting mods to run smoother.

Anyways, When staring down the list of things that can slow down GZDoom, Not Doom Engine as they are pretty distinctly different, Active time positioning event handlers can make a train wreck on the engine which is why I tried to decouple the whole thing to diagnose some of the lag.

But you were indeed right that most of the lag is not from the parallaxing sky. The majority of the lag has more to do with the Sound calculations relative to the positioning of player, another event hanlder section that definitely wrecks some things. =))

Most of this just computing power relative, but at the same time its noteworthy for gameplay trouble shooting.

On a side note, the Largest Vanilla Map that ever gave me lag from size alone on GZDoom was Planisphere 2. This GZ-BigCity map is not anywhere near as large as Planisphere 2. Planispehere 2 only has around 700 monsters which is well below my thresh-hold of actor induced lag, but the shear size of the map does induce some lag itself.

[inkoalawetrust]

All I'm going to say is that most of your lag issues are coming from your 3D Sky Box event handler. I tried to edit it to test this hypothesis, but just couldn't quite get it unwound from the map mod itself, But i 85% guarantee that would solve most of the lag issues. A mod size of 22mb is hardly anything that should be causing this kind of lag because I've played and edited maps that are just crazy in detail and have ZERO lag.

You can just replace the two ParallaxingSkyViewpoint actors with normal ZDoom sky cameras.

As for their performance impact, right around when I begun finishing the map, I did go through and try to optimize it as much as possible, and it turned out that the 2 parallaxing skyboxes didn't impact FPS much at all. Not that they should anyway, the code to make the sky camera move relative to the player is fairly simple and short, like Rachael said, plus the contents of the 2 skybox sectors are getting rendered every frame regardless of whether or not the camera moves.

Here's the accumulated FPS I got after rendering the map for around 1500 frames total with the normal parallaxing skyboxes the map has:


Ditto, but with the skyboxes replaced by the native, crappy ZDoom ones:


Also, I got these numbers by running the "stat fps_accumulated" CCMD on the console, and I recorded those frame times by just sitting in the exact location that player 1 spawns on the map. I got 97 FPS on both instances on my i5-11500. The stats show the total time it takes to render a frame on average, by the way.

Without doing some deep and intense profiling of the map and all of its parts, recording the timing of specific things, I doubt you could say such things with any such certainty.

Particularly when people say "it lags in certain parts" - that clearly says to me it's a BSP-walking issue (which is extremely common with detailed complex maps such as this) and that has nothing to do with the 3D sky box event handler. I looked at it myself - there's nothing there that would cause any notable lag.

The simple fact of the matter is, is that the Doom engine (and certainly GZDoom) is not designed to handle wide-open area maps like this, at all. It has never handled them gracefully - ever. So - maybe you should consider that the accomplishment here, instead, is that the author has actually managed to reduce lag as much as they have, making most of the map playable on rather modest systems, rather than pointing out un-prove-able red herrings as to why you think it lags.

The biggest culprit for the FPS tanking on the map are actually the trees in the forest. Which is weird since the tree actors are set to STAT_INFO to improve performance, which when I tried them out by placing 50000 of them on a flat plane. I got like 4-5 FPS by having the trees be totally normal actors, or giving them the NoInteraction flag. While changing their statnum to STAT_INFO made the flat test map run at 60 FPS or so. Plus the actual city map only has around 6000 trees. Though it may still be the BSP traversal causing this FPS drop when facing the forest on this map. Since gz_bigcity isn't a single large flat sector.

Here's the accumulated FPS I get over the span of 1500 frames with all the trees present, and with having the vast majority of them (5729 to be exact) removed. And also, I took these below results by being at X 4256, Y 96 on the map, facing at an angle of 0.

With trees (The normal version of the map):
(95 FPS)

Without trees (Mostly):

(156 FPS (!!!))

At first, I also thought that the issue was the amount of non-occluded sectors on the map, and most of the maps' sectors are the result of the vertex slope hills, but the problem is that I can't replace them with models, since I'd then have to manually reposition every tree so it appears on top of the hill models, instead of being inside them. However since the distant mountain didn't have anything on top of it, I was able to just use a model instead.

But when I tried out removing ALL the triangular sectors that the hills consist of, while still retaining the trees, it turned out that removing all the sloped sectors did very little to improve performance:

(109 FPS)

However the above test does show that the FPS is improved somewhat. While when I first tried this, I didn't get more than maybe 1-2 extra FPS. But when I first tried removing the hills, I did also just use vid_fps, and didn't do such consistent tests by recording FPS averages while standing on the exact same position.


TL;DR, the trees cause a lot of the lag on the map, despite being about as optimized as possible without touching GZDoom's native code.

On a side note, the Largest Vanilla Map that ever gave me lag from size alone on GZDoom was Planisphere 2. This GZ-BigCity map is not anywhere near as large as Planisphere 2. Planispehere 2 only has around 700 monsters which is well below my thresh-hold of actor induced lag, but the shear size of the map does induce some lag itself.

Planisphere 2 also didn't have 6000 tree sprites on the map, which helps it's performance with GZDoom. But the map does also have similar FPS to mine when at their laggiest, overlooking the whole city in Planisphere 2 causes GZDoom to chug at 30 something FPS on my PC. While gz_bigcity runs at about 40-50 FPS at its' laggiest, besides some outliers like the initial lag when you look around the map and everything loads in.

[kalensar]

I did get it to run better in OpenGl ES setting than in OpenGL. Glad to hear that Planisphere 2 wasn't the only one to give me trouble as well.

I'm not a stranger to large maps or even intricate ones. I also had no idea that there was 6000 trees in the wad either.

[will183]

Kinda makes me wish there was a sort of Gmod style spawn menu mod so you could spawn any actors or props for a map like this