If you're going to use both C and C++, then you will need to learn the coding standards for both C and C++. Cross-referencing them by thinking in terms of anecdotes and generalisations won't get you very far.

If you code C-style in C++, that simply means that you probably don't understand either.

Talk about generalizations

@Klaim lots of good points, and while things have certainly evolved, it doesn't make things in the past methods and styles invalid either.

Yet I do suppose as time goes on, the complete C++/STL/Boost style will become more and more the standard way.

Yeah lets also remember that there wasn't even a C++ standard until like 98. I've actually never worked at someplace that used STL let alone boost in their C++ projects.

I don't know that game developers have traditionally been big on it either.

I'm admittedly a C with Classes coder though, and I like to keep classes very flat.

I've only started using the STL lightly in the last two years or so. So far it has worked well enough to not need to be ripped out, but that might change if I started doing more work with custom memory allocators. As to boost, it maybe my C roots, but I really can't stand looking at any of that code and its syntax.

The main problem with learning C first is that you have to understand pointers and const char arrays to do something useful, while in C++ you have to avoid them as much as possible.

I don't recall C++ needing you to avoid pointers and char arrays.  Many of us never used the STL, and still don't.

I'd say our character here has a decent outline as well, yet the tiles don't.

Anyways not an artist, just my opinion. I can't think of many games that normally have outlines around their tiles like that. For instance the nes mega man sprite and enemies usually had a black outline, but tiles didn't.

Good luck at any rate.

Not a fan of all the main tiles having a black outline.

what do you people do when you aren't working on any game and feel bored. what do you code?

Tools and engine/framework enhancements.

Alright won't be much activity here for the next week or so. Need to wrap up the last bits of Gravitum and get it out of the door.

Yes obviously you can splice your large image. Which may mean you only ever need two or four large chunks loaded into memory depending upon the game world layout.

Yet dumping textures out of memory, and then needing to later re-load other into memory, decompress them, and then upload to OpenGL can easily lead to frame rate stutter and other problems.

Newer mobile devices are better at this, than older ones. Theres also ways to speed this process up, like not using a image format, but rather saving the texture as raw bytes ready to upload directly to OpenGL. There is also things like PVR compression which can have fantastic speed gains.

Its all capable of being done, its just something to be aware of. Using tiles you often can fit everything you need in a simple 1024x1024 sheet or less. There are many advantages and disadvantages to both approaches.

You guys feel like you're ready for all this?

Haha well thats an interesting question.

I like to think so at any rate.

Combined I and Kawe have something like 30+ years of experience in the associated fields. No doubt the project will take a good amount of time to do though.

This sounds like the game will need to process quite a bit.

Tons, and its complicated by all the single player campaign stuff, where you want to be able to lay out map triggers, and other junk.

Also we want most things in the maps to be destroyable, so there needs to be alternate graphical states for tons of stuff, as well as associated data like health, armor types, and so forth. (Like infantry machin guns are likely to do squat to a concrete building, yet larger weapons from a tank or a mech, etc...)

What I mean is, that you can't just say, that 1,1 is a wall. You need to say that 1,1 has a wall at North/South/East/West and I am not sure what the best "architecture" is to store this information. If a tile could either be a walkable or a wall, it would be pretty easy.

Usually most tiled maps end up being multiple layers of tiles. So you often end up using a 3 dimensional array for this [Layer][Width][Height].

Your layer zero would be ground tiles, layer one might be walls and other objects that need to sit above the basic terrain.  Direction of the wall seems like it would be meaningless? Its just a tile id that references a graphic in a sheet somewhere.  You sometimes than have a dedicated layer for walkability info. In this way a tile is still purely always walkable, or always blocked.

So developed the initial draft of the the data format to feed into the editor.

Its using XML and basically defines an environment, which contains a number of tile sets, followed with a number of brush categories, that contain a number of brushes.

I can loop through and read the brush categories to generate the parent folders in the tree view, and then read in each individual brush and add that as a child.

The tricky part is the brushes themselves, as I need quite a few different types, given you have terrain, buildings, obstacles, units themselves, and even meta stuff like marking deployment zones.

One big thing to consider about the single image approach when it comes to mobile is texture size limitations.

Many devices can only load a 1024x1024 or 2048x2048 max size image. You also depending on the device can quickly run into memory issues.

Also when looking at metal slug consider that the Neo Geo had a resolution of 320×224.

So work continues on the map editor.

One of the slowest parts of everything is just figuring out how to break down and organize all the data.

Part of that is deciding how to organize the tile sheets themselves, which then factors into rendering performance and other engine characteristics. I've decided to break down tiles by environment set, and then layer. So you would for instance have a jungle environment, which than has tile strips/sheets for base ground, fringe, shadow, objects and structures, and maybe overhead/foreground.

Each layer than can have its own tile ids starting at 0 and incrementing for however much is needed. This is important since you have properties associated to tiles as well which are looked up by tile id like height for instance. Its also needed in the editor to handle the definition of brushes. Though this does also mean I need to create tile property data on a per layer and per environment basis as well, vs just in a single giant file. Potentially a bit more annoying for us, but on the plus side its not nearly as memory wasteful.

Now I just need to create the actual sheets, and also figure out how to define it all. I'll probably actually use XML for that bit, despite generally disliking XML. Given the early stage of development, being able to easily hand edit some definitions is likely a big win. These can always later be converted to binary or some other format down the road.

Not sure what the problem is exactly. You just put the walls on another layer of tiles. Thickness or thinness is just an artifact of how the art is drawn.

Five dollars seems cheap to me. Though I'm an indie dev that actually sells games, and pays contractors, and so forth..

I wouldn't personally be interested in this pack though, as we do PA games, and well my partner is an artist with like 20+ years of assets laying around.

Some more progress on the editor. Basic tree control is working, though ideally need to work in icons on the left side of the items.



Also need to work out an XML spec or something to define what actually goes into the tree, and how these items work.
For instance Roads should act a single brush, but should randomly pull from tile ids 0-20 when painting.

Any suggestions for the editor's name?

I was amusingly considering M.I.N.T.E.R

@c023-DeV

Those shots look quite cool, would love to see them in full resolution.