Tile Games

Started by Hardcoal, January 21, 2018, 21:31:30

Previous topic - Next topic

Steve Elliott

#15
So verbose and at least 3 times the size Derron?

I'm not familiar with those file types, but efficiency always wins in my book.
Win11 64Gb 12th Gen Intel i9 12900K 3.2Ghz Nvidia RTX 3070Ti 8Gb
Win11 16Gb 12th Gen Intel i5 12450H 2Ghz Nvidia RTX 2050 8Gb
Win11  Pro 8Gb Celeron Intel UHD Graphics 600
Win10/Linux Mint 16Gb 4th Gen Intel i5 4570 3.2GHz, Nvidia GeForce GTX 1050 2Gb
macOS 32Gb Apple M2Max
pi5 8Gb
Spectrum Next 2Mb

Derron

Efficiency of what? Your coding time savings or file size?
Do you use the BRL-modules in blitzmax or just use the raw OpenGL commands?


Like said I am not knowing the real file size it would have or not - I just made assumptions. The most savings could be done by defining "areas" instead of individual cells (similar to compression in PNG files - not doing RLE but saving a single "105 pixels of blue in a row" entry).

How do you store your assets? PNG? for bigger background assets (with eg. drop shadows) too? You could save disk space when using two Jpegs - one defining the colors, and the other one (grayscale) defining the alpha. It would be time saving to just use a PNG. Exception is if you use the old PopCap-Games-Framework which did not support alpha channel png's and prefer'd a "texture + shape"-approach.

Do not forget the intention of XML: easily interchangeable, industry standard syntax,... and human readable (at least if you use understandable property names). File size does not always matter.
Why is HTML, CSS, ... readable? Once it got "programmed" it could get compiled to some binary code and just "executed" (read: parsed, processed, rendered).

An XML-File could easily get processed by external tools: you define certain markup to look for (or better "xpath") and are able to replace strings without needing to know more about the structure of the other parts in the XML. Localization is done way easier then. No need to have a special "language.bin"-editor.

Similar things can be said for tile maps. If the editor does not have a certain feature (say "tile swapping") you are needing the map-editor-coder to add the feature. If you got an XML/Json is just a matter of opening it up in an editor of choice and switching things/values. Of course you need to "understand" the basic structure first - but the hurdles are way lower than to say: cells are written as bytestream consisting of "cellID:int,x:int,y:int,additionalLength:int,additionalInfo1Length:int,additionalInfo1StringAsBytes:byte[],..."

So for me it is important to use XML as soon as I want the users to be able to play a bit with it, to have the level designer be able to do things "prototyping-fast" without the need to add a complicated gui-interaction to the editor (writing a nifty dialogue-system to allow a one time job to switch 500+ cells, level designer has no clue about your programming language but is experienced in search/replace of the text-editor).

All these sprite-atlas-creation tools output XML, Json ... wouldnt a binary file be faster to read/save? Interoperation, Exchangeability (I repeat, sorry).


As said I am using Brucey's persistence.mod to serialize or deserialize stuff from BlitzMax to XML/Json. Means I define eg. a TLevelMap consisting of a list/map/array of TLevelTiles. Next I patched the module to ignore all properties having a "{nosave}" metadata attached to it. To save the map I would just have to push my "levelMap" object to the TPersistence instance and add a "SaveFile(myfile)". Way back is then a "LoadFile()" or a manual levelMap = TLevelMap(deserializedObject).
It handles all the stuff for lists, arrays ... automatically. No need to take care of whether it is a byte, string, ... what has to get written/read.

Such thing could be written for "binary" too, but then it cannot use the reflection-stuff of BlitzMax without being elaborative again (writing the property name). To save space I extended the TPersistence-Stuff to allow custom readers,writers, hooks... and it looks if Objects have certain methods defined which would take over the serialization of an object instance. This allows what I described earlier: I could serialize into a bytestream and write that encoded into the XML.

For me the benefit stays: I can easily extend things to save to files, read from files - and the users are able to edit to their needs. I wait for years now to get a proper editor for TVTowers databases (persons with details, IMDB connection; movies with details, IMDB connection, person connection, ... triggers which can get defined but also hooked up by all the objects, news, events...). To connect all these things it needs a big editor (many interactions, changing A changes B, disables C, ...). Until this is possible, the users edit the XML files by hand. It has a steep learning curve to understand how things work, but then it becomes "consistent" (very similar for each object type). With binary files it would not be able.

So for _my_ cases XML still is better than binary. If your tile map is to get edited by users, or you want easy uploads to websites hosting levels .... use XML/JSon. It is easier to get processed in PHP/Javascript (existing libraries for Json/XML processinG). It depends on who wants to use your data - and how.


bye
Ron

Steve Elliott

#17
Definition of verbose in the Dictionary - see Derron lol  :P

The KISS (keep it simple) way of working would help you no end I feel.  You tie yourself in knots coding-wise (because you over-complicate things) and are then complaining about it  :)
Win11 64Gb 12th Gen Intel i9 12900K 3.2Ghz Nvidia RTX 3070Ti 8Gb
Win11 16Gb 12th Gen Intel i5 12450H 2Ghz Nvidia RTX 2050 8Gb
Win11  Pro 8Gb Celeron Intel UHD Graphics 600
Win10/Linux Mint 16Gb 4th Gen Intel i5 4570 3.2GHz, Nvidia GeForce GTX 1050 2Gb
macOS 32Gb Apple M2Max
pi5 8Gb
Spectrum Next 2Mb

Derron

I am complaining about ...what?

I allow the users of my game to customize/extend it.


As the load/save is done _once_ (framework...) I can reuse it for all the other games, tools ...  so I use the "write once, use often" approach. If one uses my framework, then using the provided solution is "KISS" for these users/developers.


bye
Ron

TomToad

I honestly don't know what can be simpler than:
Persist.SerializeToFile(Level,LevelName) 'Save the level to the file "LevelName"
Level:TLevel = TLevel(Persist.deSerializeFromFile(LevelName) 'Load the level from the file "LevelName"

Of course, I really don't like how BaH.Persistence formats its files,  I prefer to create the document with Bah.libxml directly.  Something like
CreatureNode:TXMLNode = Node.CreateChild("creature",creature.x+","+creature.y) 'create the creature node
CreatureNode.AddAttribute("type","ogre")
CreatureNode.AddAttribute("strength",100)
CreatureNode.AddAttribute("health",100)

is no more difficult than
WriteInt(FileOut,10) 'creature object
WriteInt(FileOut,8) 'Type is ogre
Writeint(FileOut,100) 'Its initial strength
WriteInt(FileOut,100) 'Its initial health
WriteInt(FileOut,creature.x) 'It's initial x position
WriteInt(FileOut,creature.y) 'It's initial y position

The former is even self documenting.
------------------------------------------------
8 rabbits equals 1 rabbyte.

Hardcoal

What's wrong in loading all tile data to memory?
Code

Derron

There is nothing wrong with that - and I think nobody suggested doing something different.


People here are talking about the "storage" outside of the executed programme - so "level files". Once loaded they of course live as the original "structure" within the programme (so objects with properties like gridx, gridy, ...)


bye
Ron

RemiD

#22
@Derron>>xml is right for you, a lot of blah blah  :-*


I use my own file format, if you are not stupid, you know exactly what you wrote so you know what to read...

And you can allow the users of your games to create maps/missions/items with a custom editable text file, you don't necessarily need to use xml...

Derron

#23
Quote from: RemiD
@Derron>>xml is right for you, a lot of blah blah  :-*

I use my own file format, if you are not stupid, you know exatcly what you wrote so you know what to read...

? ? ?
Can you please explain why you are attacking me now?


Hardcoal asked something which did not fit to the things we wrote about. So I assumed he misinterpreted things. This is why I explained that all the "level"-file-stuff (does not matter whether XML, binary or whatever) has nothing to do with the way the game internal represents the level data.
His reply was like if we wrote about storing images as PNG, BMP or TIFF - and Hardcoal was asking why we do not use a TImage or TPixmap object instance to have the image data in the game.

bye
Ron

RemiD

I am infected by the "Troll virus" and sometimes the load is too high and i can't control my words, sorry  ;D

Hardcoal

#25
I also use my own DataBase which I've built and serves me well

I offered it once for people, but there was no big excitement so i kept it to myself  :-X

Whats good I think about my Database is that its readable as well as an External File
Also its not too hard to learn and understand

Here is an example.. of a Database Structure of mine..



CameraStartZPos[-20.0000000]
CameraFOV[1.00000000]
ElementClasses[ClassTypeName[GroupClass_System]
               IsActive_flg[1]
]
MapElements[Element[Name[Mesh]
                    FileName[Platonic.3ds]
                    XPos[-0.249999955]
                    YPos[0.999999821]
                    ZPos[0.899997473]
                    ScaleX[0.999999881]
                    ScaleY[0.999999881]
                    ScaleZ[0.999999881]
                    Friction[0.980000019]
                    EntityOrder[Normal]
                    ExtraPath[Shapes\]
                    Info,IsPickable_flg[1]
                    IsActive_flg[1]
                    PlayMediaForces_flg[1]
                    PlayPhysical[1]
                    PlayRegularForces[1]
                    ToBeLoaded_Flg[1]
                    ElementGroupName[Players]
                    ColorR[255.000000]
                    ColorG[255.000000]
                    ColorB[255.000000]
                    Alpha[1.00000000]
                    TextureFilename[DefaultTexture.jpg]
                    ElementClasses[Name[ElementMainGroupClass]
                                   ClassTypeName[GroupClass_System]
                                   IsActive_flg[1]
                                   FlowchartXPos[100]
                                   FlowchartYPos[100]
                                   GroupClassFirstSonClassName[Func_RandomRoll]
                                   Class[Name[Func_RandomRoll]
                                         ClassTypeName[Func_RandomRoll]
                                         IsActive_flg[1]
                                         FlowchartXPos[400]
                                         FlowchartYPos[400]
                                         DataCell[CellName["[AffectedElement]"]
                                                  CellDataType[Element]
                                                  Data["[Self]"]
]
                                         DataCell[CellName[RndStrength]
                                                  CellDataType[StringOrValue]
                                                  Data[0.100000001]
]
]
]
]
]



This is an example of an object in my map.. with a function it has..
It's easy to Read and it helps sort errors when its readable like that.

I didn't improve it for years..
I use it as it is and it works pretty fine..
I had some Improvements Ideas, but no reason to invest in it.

This is only for storing Data..

Generally there is a Command for loading the Text and from there you extract info..
It has to be loaded into the Ram First.
thats how it works for now

Code

RemiD

@Hardcoal>>it is also possible to use tiles to build a map, but then don't use the tiles in the game (=the tiles of each room/area are merged in one mesh one surface with one texture), and then you can use a parent->child->subchild->subsubchild etc... system to determine which rooms/areas (and their childs) to hide/show update...