next »

[etoir]

Does  anyone use Tiled's JSON export option? I'm trying to create maps with it for a game I'm making in C++. I want to find tutorials on using the JSON part of Tiled but none seem to exist. They are all outdated and focus on XML. Tiled doesn't even have the XML export option anymore.

[Teknokommari]

Does  anyone use Tiled's JSON export option? I'm trying to create maps with it for a game I'm making in C++. I want to find tutorials on using the JSON part of Tiled but none seem to exist. They are all outdated and focus on XML. Tiled doesn't even have the XML export option anymore.

Downloaded tiled and played a round with a bit and it seems that the save format of the editor itself is actually XML file it just uses ".tsx" extension to differentiate itself from other xml files.

I recommend using JSON because it's generally faster than XML and easier to parse. You could try something like SimpleJSON to parse it or check if the framework or engine you're using already has tiled support available.

The format itself doesn't seem too difficult to understand (just open it with notepad or something and you'll see).

[etoir]

I'm making my game completely from scratch in C++. I'll look into SimpleJSON then. Thanks!

[qMopey]

Or you could just parse the json yourself  

That's what I would do.

[Teknokommari]

Or you could just parse the json yourself  

That's what I would do.

There's really no need to invent the wheel for the umpteenth time over.

Using tried and true tools in your projects will make the game easier to maintain and faster to develop and meet those pesky deadlines. If you're working on a team, these tools might already be familiar to other programmers allowing them to jump in way faster.
 

[etoir]

So the next thing I'm running into is the base64 encoding. There are a few online converters, but I hope to have it done in-engine so I don't have to edit the map files every time I create one. Are there some recommended libraries?

[Schrompf]

You can also switch off Base64 encoding when saving the file in Tiled. That's what I did to be able to read it easier.

[qMopey]

Or you could just parse the json yourself  

That's what I would do.

There's really no need to invent the wheel for the umpteenth time over.

Using tried and true tools in your projects will make the game easier to maintain and faster to develop and meet those pesky deadlines. If you're working on a team, these tools might already be familiar to other programmers allowing them to jump in way faster.

Yes there is a need to invent the wheel. It's called: lowering dependencies. Using "tried and true" tools will bloat your project and wreck compile times. It will make maintenance a giant hassle, and make it harder for others to contribute due to large dependency setup requirements. It will make your release much larger, using up more RAM and download bandwidth. It will require new programmers that jump into your project to A) already know said large library, or B) learn said large library. As opposed to reading a single C/C++ file of code to parse some integers and strings. Those libraries will also tend to use way more memory than needed, have way more features than needed, and be way slower than needed (due to handling the generic case).

Common advice like you posted here is usually pretty bad advice, especially when it is recited without any context.

Throwing away the option to just write it yourself is a disservice.

[Teknokommari]

Yes there is a need to invent the wheel. It's called: lowering dependencies. Using "tried and true" tools will bloat your project and wreck compile times. It will make maintenance a giant hassle, and make it harder for others to contribute due to large dependency setup requirements. It will make your release much larger, using up more RAM and download bandwidth. It will require new programmers that jump into your project to A) already know said large library, or B) learn said large library. As opposed to reading a single C/C++ file of code to parse some integers and strings. Those libraries will also tend to use way more memory than needed, have way more features than needed, and be way slower than needed (due to handling the generic case).

Common advice like you posted here is usually pretty bad advice, especially when it is recited without any context.

Throwing away the option to just write it yourself is a disservice.

Firstly you're assuming that everything written by others is bloated mess, which is downright false. Secondly you're assuming that everything you do by yourself is automatically better than tools made by others, where as those might have been developed by people with more experience than both of us combined or a large community of active open source developers who have spend potentially years ironing out all the problems from said tools.

For something like parsing JSON you can find tons of options out there, hell the SimpleJSON I recommended contains like 2 source files and 2 header files. One only needs to look at the examples on how to use it and you're good to go, no need to dwell too deeply to the source code.

Trying to do everything by yourself is generally a sign of a inexperienced programmer.

[ThemsAllTook]

Arguments like these tend to further polarize the two opposing sides, which is pretty unfortunate. Sometimes a prebuilt third-party solution is the best tool for the job, and sometimes a custom implementation built to suit your exact needs is the best tool for the job. Promoting one over the other in all cases is dogmatic. A JSON parser is right on the threshold of complexity where a custom solution could be implemented robustly and suit individual needs better than anything the exists, but also is enough work to be worth considering using someone else's library.

[JWki]

Just to throw in another point, trying to write as much code as possible yourself can also help make you a better programmer. I mean, how are you supposed to get experienced? Right, by writing code. So it might be worth it just for the learning experience. But it really comes down to personal preference in cases like this one.

If it's a hobby project, or just a very small project, I'd recommend trying to write your own parser just to be able to say you wrote a JSON parser once, then see whether it's good enough for your uses and if it is just go with it.

[qMopey]

Yes, I definitely threw out a very polarized perspective. It's important not to shut down an entire option of churning out something specialized from scratch, because there is a lot of merit to this option.

It is definitely not the best option to write a feature from scratch in every case, and not all libraries are bloated. The decision to write something or use a pre-existing library is more often than not a very difficult, nuanced, and important choice. Pigeonholing into one side like a zealot will in the end be an inefficient use of time. Instead, decisions like these should be taken case by case with some care.

Firstly you're assuming ... snip

Assumptions like these are made just to show your statement "There's really no need to invent the wheel for the umpteenth time over." is wrong. The idea is: if a programmer goes and takes a look at a library's source code, if the assumptions you refer to are indeed true, they can then make an intelligent decision.

As opposed to a dogmatic decision of never having a need to reinvent the wheel.

Trying to do everything by yourself is generally a sign of a inexperienced programmer.

Ironically, trying to use libraries for everything to avoid reinventing any wheels is also a sign of an inexperienced programmer that stopped learning and growing.

At least if a programmer is diligently writing things themselves they are definitely learning and growing.

[Teknokommari]

Ironically, trying to use libraries for everything to avoid reinventing any wheels is also a sign of an inexperienced programmer that stopped learning and growing.

At least if a programmer is diligently writing things themselves they are definitely learning and growing.

Focusing on problems that need to be solved instead of ones that have already been solved does not stop you from learning and growing, quite the opposite really. You can also learn great many things from others, often faster than you'd do by yourself.

When working on a team of let's say 3 or more people with different skill-sets, the programmers will quickly become bottle-necks to the project even with bunch of 3rd party tools to help out to actually bring all the models, animations, audio, localization and levels to the game. There's always something that needs to be fixed, updated or implemented so you'll quickly start to appreciate how much these 3rd party tools can lighten your work-load and actually meet those strict deadlines.