building maps with modular parts

Community Forums/Technical Discourse/building maps with modular parts

RemiD(Posted 2016) [#1]
Hi,

I am trying to reproduce, and then to modify and to improve an old video game with a top down view, and i need to build maps, so i decided to create a map editor which use modular parts (premade meshes and textures) that i assemble with different positions/orientations in an area.

Each modular part is loaded once, and then only copies are positionned/oriented in the world.

A quick test map :


For the moment i have separated the entities in these categories :
->"entryexits" (passages to go from one map to another map)
->"terrains" ("mesh" using the blitz3d ROAM algorithm)
->"statics" (walls, fences, doors, windows, gates, columns, floors, roofs, beams, barrels, boxes, crates, containers, furnitures, machines)
->"interactables" (handles, buttons, switches, levers) (these can be actioned by characters)
->"lightsources" (streetlamps, walllamps, floorlamps, tablelamps) (these will light/shade the surfaces with fake "volumetric lighting")
->"takables" (armors, shields, weapons, bullets, bandages, splints, drugs) (these can be taken/used/droped by characters)
->"turningmovings" (characters)

For now i have not unwraped/texelsfilled/uvmapped all meshes/surfaces but i plan to do it at least on large surfaces, with a texel size of 0.01 and an outline along each edge, to add some details and to have a better visibility between different shapes)

Since it will be a top down view, not too many meshes/surfaces should be in the camera fov so this should be fast enough to render on most computers recent enough. (but i don't know yet if having many (thousands) copies (with copyentity) will be fast enough to render because i know that renderworld() can take a lot of time when there are too many pivots/entities in the scene (even if they are not in the camera fov or hidden)), weird i know but it is what it is...

Not sure how far i will go with this, but i like the approach to build maps with modular parts...


jfk EO-11110(Posted 2017) [#2]
Interesting. The way you organize it reminds me a lot of how I did it with my fps engine a couple of years ago. I also had a String parameter for each object, that could hold things such as Microscripts for interactivity, timing etc. in a rather flexible way.


RemiD(Posted 2017) [#3]
Yes i will also add a name/tag parameter to define some properties, especially for characters. (bodyshape, faceshape, skincolor, hairshape, haircolor, eyescolor, colthes/armors, shield, weapons)

I have modified slightly the way i structure a map, but this is not important, for the moment i am working (again) on a turn move, dectect collisions, reoriente reposition, system (using linepick and pickables) and on a nodes+links, calculatenodespath, follownodespath, system.

As you may know, all of this takes time and sometime a system must be recoded in a way to make it compatible with the map/things/entities... So plenty to do...


Rick Nasher(Posted 2017) [#4]
I really hope you do not have a similar idea as I do. lol.


RemiD(Posted 2017) [#5]
@Rick>>not sure what you mean, but probably not...


neoshaman(Posted 2017) [#6]
[quote]

->"entryexits" (passages to go from one map to another map)
->"terrains" ("mesh" using the blitz3d ROAM algorithm)
->"statics" (walls, fences, doors, windows, gates, columns, floors, roofs, beams, barrels, boxes, crates, containers, furnitures, machines)
->"interactables" (handles, buttons, switches, levers) (these can be actioned by characters)
->"lightsources" (streetlamps, walllamps, floorlamps, tablelamps) (these will light/shade the surfaces with fake "volumetric lighting")
->"takables" (armors, shields, weapons, bullets, bandages, splints, drugs) (these can be taken/used/droped by characters)
->"turningmovings" (characters)

[quote]
It's funny how close it map to the usual convention I know, with some minor adjustement in the naming:

Takables = collectibles
turningmovings = agents
interactables = gameplay elements

:D


RemiD(Posted 2017) [#7]
This is because i don't like arbitrary exceptions (weird words who don't follow the logic of a language) so sometimes i make up my own word using the logic of the language. :P
(i do the same thing in french)

I have slightly modified my map structure :

->terrains

->statics (floors, walls, ceilings, passages, columns, containers, furnitures, machines, rocks, plants, trees) (including locks, handles, buttons, switches, levers, doors, windows, gates)

->lightsources

->takables (all equipments/items)

->turningmovings (characters/vehicles)

->triggers (invisible low tris meshes which can be picked/intersectedwith to trigger an event (areas where you can interact with a lock, handle, button, switch, lever, door, window, gate, entryexit)

->obstacles (low tris meshes which are obstacles in the map (low tris version of the renderers so that collisions calculations takes less time)

->nodes and links (used by the AI to calculate a nodespath and to follow a nodespath when there is no directpath possible to the target)

Of course some of these things could still be put in the same group (for example lightsources with statics), but imo it is better to have separate shorter lists to decrease the time it takes to browse through them...