1
\$\begingroup\$

I'm building a 2D tile-based puzzle game in C#, using Monogame. The game board is an 8x6 grid of tiles, each of which can contain a number of objects. Conveniently, the number of possibilities for what each tile can contain fits nicely into 1 byte. I was wondering what the most sensible way to store level design data would be. I'd like it to be at least vaguely human-editable, as I need to construct a level or two while I build the game. Once I'm sure the game logic is all working and it's playable, I intend to build a level editor to construct the rest of the levels, but I need to build the first few manually.

Currently I'm tempted by the idea of encoding the levels in the colour data of an 8x6 pixel bitmap, but that's possibly overkill. Thoughts?

\$\endgroup\$

closed as primarily opinion-based by Seth Battin, Anko, Josh Aug 7 '15 at 16:36

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    \$\begingroup\$ The "best" way will probably morph over the course of your development. You need 2 levels now; later you want lots of levels. You want readable data now, maybe later you tightly compressed or obfuscated levels. It's unlikely that there is a correct answer. As usual, if you are not yet sure, do the simplest thing that could possibly work \$\endgroup\$ – Seth Battin Jul 29 '15 at 19:22
5
\$\begingroup\$

I'd like it to be at least vaguely human-editable

I would take this to be your first requirement. Storing it in the colour data of a bitmap is probably not going to help here so I'd go with something else.

For a 2D tile based game it might be worth investing some time to learn how to use an existing tile based map editor like Tiled. I'm currently adding Tiled support to the MonoGame.Extended project.

Although, if you want to keep it really simple even that might be overkill.

It's interesting to look at how games of the 80's and 90's stored levels. For example, I used to play an awesome little puzzle game called Heartlight PC and I've studied how it works.

You can actually download the original game in the DOS games archive and see for yourself. The levels are stored in a text file called LEVELS.HL and look like this:

%%%%%%%%%%%%%%%%%%%%
%....@.....@.$.....%
%.*..@$...@@@@...@.%
%....@...$.......@.%
%%%%%%%%%%%%%%%%.$.%
%....@@...@....@...%
%.@...$..@...$.@...%
%.@.%%%%%%%%%%%%%%%%
%$.@...@.@...$@....%
%....@@..@$...@$..@!
%.$....@.@..@..$..@%
%%%%%%%%%%%%%%%%%%%%

You can watch that level being played on youtube

The awesome thing about doing something like this is that any text editor becomes your level editor. Obviously it has some limitations, but it's really simple and works pretty well for some games.

\$\endgroup\$
  • \$\begingroup\$ Text-based was my first thought, yes, but I either need two layers of data, or I need more possibilities than there are characters. Yes, the char data type takes exactly 1 byte, but many of those are control characters or otherwise non-printing. \$\endgroup\$ – Tam Coton Aug 1 '15 at 9:57
3
\$\begingroup\$

XNA has an automatic xnb serializer which means you can write levels in xml (very human editable) on your dev machine and the XNA build process will serialize it into binary for compact storage and distribution. Then the XNA content pipeline will load them for the end user just like it does for a model or texture or anything else the content pipeline can handle. If you want to modify a level, you simply modify the xml and rebuild the project, that simple. Your game ships with the binary, not the xml.

Here is a good place to start: http://blogs.msdn.com/b/shawnhar/archive/2009/03/25/automatic-xnb-serialization-in-xna-game-studio-3-1.aspx

\$\endgroup\$
0
\$\begingroup\$

Just store it in JSON. Storing it in the colors of a bitmap seems like you're being tricky for no real reason.

\$\endgroup\$
0
\$\begingroup\$

if you need multiple layers, using an image is perfect. I've implemented an image level system for a similar project myself, and it worked perfectly. I used system.drawing, it has a bitmap class (system.drawing.image.bitmap) with getpixel and setpixel functions. Using getpixel you can load the color of a pixel at a certain coordinate. If you loop through all the pixels, using getpixel, you can get the values of your tiles (for example the r value), add enemies to your enemy list/array(using the g value, switch is useful over here), and perhaps get the lighting values or whatever using the b value. Hope it works for you. If you get stuck, I will send you my implementation in like a couple of days. Good luck :)

\$\endgroup\$
0
\$\begingroup\$

For starters, you should only use an image if you need multiple layers of data. If you just need a single layer, a text file is the best option. Since an ascii char is basically a byte, you could just read every char, and then you should be able to convert char to a byte using typecasting. Next you equal for example tiles[1,1] to the char you just read on line 1 of the file, first char

*you could even use the a value for something else. Problem is this makes editing a bit harder

\$\endgroup\$
  • \$\begingroup\$ That was my first thought, but too many char values are control characters or otherwise non-printing. \$\endgroup\$ – Tam Coton Aug 1 '15 at 9:53

Not the answer you're looking for? Browse other questions tagged or ask your own question.