openage
openage copied to clipboard
SFTtech
Random Map Scripts (RMS)
a simple random map generator
gets a rms file and tries to make a map which can be loaded within the game.
important: if the map is for more than 2 players, you need to add more playernames in the menu, otherwise openage will crash.
how does it work? ./rms.py oasis.rms will generate a /tmp/default_save.oas file which can be loaded
what works: can create Islands (Water,Grass) with shapes(random flood fill) and placement(in circle, random, and within a bounding box) connection: from island center to another island center with terrain costs object placement: random, in a circle, filling whole island nearly everything has paramenters which can be tweaked new map can be generated with a different seed
TODO:
- [ ] preprocessor language
- [x] team circle placement
- [x] team circle placement with deep pocket players >= 6
- [ ] team placement (random placement for a team on an island)
- [x] map scaling completion (current status: only size of map is scaling)
- [x] map scaling algorithm (linear, sqrt,..)
- [ ] island styles (more than just random flood fill)
- [x] island basesize
- [ ] island smoothing, no single tiles inside water
- [x] island polygon boundary
- [ ] automatic beach grass - beach - water
- [x] automatic deep water
- [ ] object placement parameter (min distance to, loose coupling)
- [ ] object avoid player starting area
- [ ] water unit placement
- [ ] wall generation with gates
- [ ] island patches (maybe can be implemented as it is now with a dummy object)
- [x] team connection
- [x] team to island connection
- [ ] team to team connection
- [ ] connection variance (currently we go straight lines, maybe add random costs to tiles or random dummy objects)
- [x] individual object connection cost
- [ ] diffrent connection width for diffrent terrain
- [x] do not do replacement on start and end island of a connection
- [ ] blacklist of island for connection creation
- [ ] merge connection which are close to each other
- [ ] trigger support
- [ ] cython wrapper
what ideas do you have?
For now, creating the save file is a good idea, although for the future, we have to implement it with a proper python api way for the engine.
By the way, the scripts should reside in the openage/ folder like all the python components.
For random map generation itself, we should probably have support for the old .rms scripts and also our new format, which may either extend it or be completely new. Having all that in Python is very good.
Question:
As of now I can only make a Screenshot of the window, but how do I make a Screenshot of the whole map? This would be an enormous help for developing a map engine.
I dont think legacy support for old .rms files is a good idea. If we have it, people expact they will work as expected. It may be feasible testing the most famous ones, but most likely there will be problems with edge cases, which will harm the reputation of the project.
Currently, there is no implementation of rendering the whole map, I'm sorry. The best approach for this would be actually implementing map zooming and then taking a regular screenshot of the rendered game.
For the legacy support, you're probably right.
IS there a list with object ids? I need the ones for the wall and gates. Otherwise I cant test arena maps generation.
if you have ideas, please make a comment
I think there are all available here for the base game.
http://userpatch.aiscripters.net/unit.ids.html
btw you can check for CI errors locally by running make checkall :) (kevin just executes .kevin)
FYI: arabia and black forrest are playable and recognisable. They are not as perfect as the original, but we will get there.
Are you sure shapely is a good idea to depend on? We are trying hard to minimize the amount of dependent libraries, as soon as we use less-popular libraries, distros will have a hard time packaging us. (shapely is in gentoo though :)
btw it would be awesome if you came up with some actual map storage format. I think it's ok for it to be a binary file, and it should somehow represent the chunks and allow effifient access even for gigantic maps. something like the minecraft storage :bulb:
what we need to save per tile? terrain-type: uint8
allow effifient access even for gigantic maps
what is a gigantic map?
| Size | Tiles on Sides | Total Tiles | size in kb |
|---|---|---|---|
| Tiny | 120x120 | 14400 | 14 |
| Small | 144x144 | 20736 | 20 |
| Medium | 168x168 | 28224 | 28 |
| Large | 200x200 | 40000 | 40 |
| Huge | 220x220 | 48400 | 48 |
| Gigantic | 240x240 | 57600 | 57 |
| LudiKRIS(userpatch) | 480x480 | 230400 | 230 |
| openage big | 2048x2048 | 4194304 | 4196 |
objects: except of black forrest, most maps have only a tiny fraction of tiles with an object on it.
Object properties: x,y,type,action,path,status(health),.. => ~20B
if every 10 Tile has an object, then we would double the size: 8MB maximum.
do we need a special format with direct chunk access? For playing all chunks must be loaded into memory. So why not use a format which is simple and extensible. (like json)
we should use a json like format and compress it.
I will do some tests, but I need to know what properties the units have which needs to be saved. (when possible with type(uint8,int32,char,...)
Our maps won't have any rectangular dimensions. Instead, they're stored in chunks, which can be at any point and must not all be connected, just like in minecraft. Chunks should therefore store their terrain information and objects standing on them. We won't load every chunk necessarily, even on the game server.
I don't think that any human-readable format is a good idea here as speed and filesize is more important than manual editing. For the editing, we have the ingame editor.
Oh, I didn't know there could be chunks not connected to each other.
I will develop a proposal.
I don't understand what you mean? AoE2 does have RMS scripts, but openage is completely missing a parser for the files and the generator backend to create a cool map from it.
Which would be awesome if somebody implemented it :)
See #65.