Grid-based paradigm

[wzl]

Heyo,
I was thinking about something, and i'd like to hear general thoughts on it.
Normally when we create game assets, it is 98% of the time grid based tiles (arbitrary percentage, just for arguments sake).
Artists have been thinking about how to break the grid up by using smart placement and transitions of objects on tiles.

In earlier times when hardware resources were limited this was the right thing to do. nowadays, we still do it this way. Out of tradition? Out of habit? Lack of alternatives?

Proposal:
What if trees are not placed on a grid, but can be moved around freely on the grass field.
What if we can use a selection of rocks and jumble them together to build a pile.
What if we place flowers individually so we can have them sway in the wind.

I'm considering adding this to my editor. adding props from tilesets as individual objects that can be placed and depth-sorted (probably by y value) so i can create woods by just jamming trees all over the place.
Sure this will create potentially new problems to solve and address, but it might also give some opportunities and ways to make the world more interactable.
i'm curious to try it out, but i'd also like to hear your thoughts and input on the matter.

[eishiya]

Many level editors support adding objects in this way (it's the same process as creating/placing NPCs, the only difference is they have no scripts or have different types of scripts associated with them). It is rare to find engines that support tile-based non-grid "sprites" out of the box these days; it always seems to require custom code, but it can be done.

The reason it isn't done more often is because it creates a performance hit compared to doing everything grid-based, since it requires more sorting (per FRAME as different characters weave between the static objects) and more pixel-position calculations as the camera moves. You'd think that with modern computers the performance on 2D games shouldn't be an issue, but it still can be, especially if you're making a browser-based or mobile game. Also, for a well-designed tileset and map, the quality difference is often not that noticeable.
And of course, grid-based levels reduce the complexity of the code and the work a level designer has to do.

World tiles can be animated, even dynamically (e.g. to react to wind caused by a player's attack), so for something like wind animation, there's no need to turn things into game objects unless there's another factor requiring it, e.g. if you really want to erase the grid beyond an artist's capability, or those objects are also something the player can walk around and that you can't handle with clever layering. Keeping static objects as part of the world layers, even if they're animated, helps with performance since it avoids unneeded depth-index calculations and reduces the number of draw calls.

Truly interactive objects, such as piles of rocks that can be shoved apart by a player attack or by walking into them, should of course be game objects. Whether they're grid-aligned or not depends on the look you want, but assuming you want a very naturalistic world, why not have them off-grid? That is already how it's done in most games I think, although many keep their interactive objects grid-aligned for aesthetic and gameplay reasons.

[RAV]

Before I've done Blackbox, I've actually done a little non-tiled 2d engine that entirely sorted everything as floating images realtime, basically assuming everything movable. It worked surprisingly well, within certain bounds, that are plenty enough these days. Then consider that on top of that it can use a grid only internally just to occlude calculations.

For Blackbox I went the exact opposite extreme. Why? Because the grid is not only an annoyance, it's also a creative strength. One of the few advantages PixelArt can still claim, is how well it works along tiles, and how extremely fast and reliable you can construct worlds with that, if you don't fight it, but very much boost it to a natural conclusion. Done right, you can construct in a few clicks what would take you hours of fiddling if you were truly "free". So this is the heartpiece. With it, any massive world scale is easily managed on a creative level, that's what I wanted. After getting this right, I can still go off-grid for best of both worlds.

So more than anything, what's right for you depends on your scenario. If you want a small but fully dynamic and organic scene, it can work best without. But the bigger you go, you want the grid, for both, technical and creative reasons. I'd even go so far as suggest, if the grid bothers you so much, don't even bother with pixel art for it.

[Indigo]

I think the main reason why tiles are embraced is because they are actually quite efficient.  You can make less art to convey large ideas in a seamless way that is much harder to do with floating assets.

With that said, it's not uncommon at all to have entire engines using floating assets without a notion of the tile grid.  Owlboy for example is entirely done in this way.  Some pieces are drawn as repeatable tiles - but not because the engine requires it (it doesn't even care about that from what I understand), but simply because it's more efficient for the artist.

[wzl]

thanks for the replies so far. lots of things to digest 

it always seems to require custom code, but it can be done.

To be fair, i've been dabbling with different engines lately, and it seems all of them require custom code when it comes to tilemap rendering. The support for that is overwhelmingly bad, be it ue4 (although i havent looked at that for a year now) unity, which has no tilemap support at all (unless you're licensed and get into the unity2dalpha, which looks alright so far) or godot (which is just hilariously bad in that regard). Tilemaps are such an easy problem to solve, and it confuses me that some engines just totally neglect it. (to be fair, flashpunk's tilemaps were alright for a base implementation, and since you got the source they were easily extendable). So yeah, writing custom code is always necessary, if you want flexibility and performance, at least in the current day engines for 2d.

The reason it isn't done more often is because it creates a performance hit [...]

Performance impact shouldnt be too harmful on any system. even if you have a huge map with lots of objects, you can easily cull everything offscreen, and y-sort everything else. unless you have thousands of objects (like every single strand of grass being standalone) it should be more than fine.  Picking up on that you can also just shove every object into a single vertex buffer to get done with them in one draw call. It requires some technical finesse, true, it's not outlandishly difficult. But you're right about the level of complexity both on the codebase as well as the level design. Although the latter part could be solved by having good tools for it.

World tiles can be animated, even dynamically (e.g. to react to wind caused by a player's attack) [...]

Animated tiles are always nice, but i'm to be honest, i'm still sort of struggling for a decent implementation of those, both on the editor-side (how to define an animationloop of tiles), on the data side (how to store the animation loop tile id's and possibly times) and also the rendering (change uv's on the shader? rebuild geometry ever animation frame?). but that's besides the point.
What i was thinking about would be like a patch of grass swaying to the side when you walk through it. some high grass strands (foliage particles as done in 3d engines) to have the character sink into it instead of standing on top of it, having their feet occluded. have wind blow in different directions instead of a static wind loop on tiles. having high grass cut with a sword will cut down patches instead of replacing a tile with short grass. things like that come to mind to build a more dynamic world while remaining intrinsically pixel based.

One of the few advantages PixelArt can still claim, is how well it works along tiles, and how extremely fast and reliable you can construct worlds with that [...]

Yes, definitely. and i'm not trying to abolish tiles entirely. It is a solid foundation for floors, geometry, architecture, environments in general. I'm just considering another layer on top of that, something that might push pixel games from having mostly rigid and stiff world to something that reacts, something that seems to exists, as opposed to something you simply walk on. (lighting is another area that helps with that, if you want we can add this topic to the discussion too, since light often is not (pixel)gridbased  )

Owlboy for example is entirely done in this way

Ohhh interesting. I'll take a look. From what i see right now it mostly takes asset presets and patches them together. Interesting attempt. Definitely gonna study it some more!


Sorry if i wasn't quite clear on what was on my mind. It seems you got the impression i wanted to replace tile grids entirely, which was not my intention. I just wanna discuss if we still need to entirely stick to grids as we do for the past 30 years, or if we can do some things to drive pixelart forwards, as 3d was pushed throughout the years, especially through its technology.
Just think back on it.
We started with colored polygons, then had uv's, later adding vertex lighting, pixel based lighting, bump mapping - being replaced by normal mapping soon after, shadow casting, subsurface scattering, skeletal animations, morph targets for facial animations, physics simulations for cloth and hair, ragdolls. It just inreasingly getting more ridiculous how much stuff is discovered. Allthewhile pixel games today are pretty much the same games that could have been done in the 90s.
Dont get me wrong, there's nothing wrong with that either. I'm just thinking that we could and maybe should also consider that we have more capabilities with todays machines, to leverage what we have and try to think of something we can make of it.

[RAV]

Hrrm, if it's not abandoning tiles, is it a heavy layer of object sprites on top then? Plenty games done that. They also do lights and animation, etc. But whatever the case, Ubisoft's engine for Rayman does everything and then some. It also forgone pixel art in favour of concept art in Photoshop. Why hold yourself back after all? It's the 21. century. The inherent rigidity of Pixel art just wasn't well suited to all that flexibility. And why putting so much effort into breaking it over your knee. Is that really worth it? Be consequent. From technical to artistic, there are so many reasons why you shouldn't bother with pixel art, why its problems would just lock you in, slow you down and distract you from what really counts most. Or does it.

It also took a great deal of research and pre-production making that. It's not what a typical one-man army for hobby does. When people ask me, why I haven't done feature xyz, the answer is usually not that I couldn't think of that, or don't want it, but that I simply didn't have the time yet. That's probably true for most other devs. There's a million things we should do, even on the simpler route. It's important to consider the overall complexity of a project, not just the rendering. And concepts like a grid are usually tied to much more than rendering. You have to pick your battles and watch that in the end you're not stuck on forever fiddling on some systems or assets, but get a game done, if that's your end goal.

When people look at Blackbox, they sometimes say "oh it's just a bunch of cubes, subdivision and flat colours. So what? I have a general idea of how that would work." But it's really all the details of execution that made it plenty difficult as is. After all, you can describe Elk's Deathwing as "just a Dragon sitting on a rock". You can boil anything down like that if you want. Blackbox is not something that could be done even just 10 years ago, at least not to a level that makes sense and is worthwhile, and even today it's dancing the edge of what is viable with cleverness. And even for looking into tiles, there's a whole lot of work getting the most out just that, all things considered. You can dedicate yourself just to their problems and opportunities, and have your hands full plenty, if you want to bring it to the next level.

3d games are as free as it gets, since the original Doom, which was a conscient step away from the tiles of Wolfenstein, this sort of freedom is so ubiquitous and dominating, that to me, re-investigating the merits of a grid seems interesting again. Turns out, maybe it's more a matter of different kind of freedoms, instead of no freedom versus all freedom. Maybe there's different ways of doing things, maybe there is other ways to innovate. Maybe there is a relevant innovation in tiles too. I don't think that pixel art and tiling are principles that ever get old as such. Obviously it's not for everything. Not even for most things. It is not the only thing, but it is a thing. Maybe it's a creative niche more than anything. But there is a need and demand for it. Lego's base principle too is rigid and old. Yet it stays relevant and interesting.

But maybe I'm just too biased and invested. Defend the grid! I can only explain my motivation from my own work's directive. If this is more about what you'd like to do yourself, I can only tell you, go for it if you feel passionate about it. I'm sure there is plenty of great opportunity waiting in it for you. There are a great many merits and use cases to an emphasis on free form asset placement. And even pixel art can profit from that. Maybe that's what you really want to discuss here instead what a grid is worth.

[Helm]

Here's some ancient Amiga art (quite impressive) done with floating assets as you describe. There's pros and cons.

http://francksauer.com/index.php/games/15-games/published-games/9-unreal

[Arne]

I was just going to mention the Amiga. A lot of the little games I did back then used "BOBs" - Blitter Objects. The Amiga doesn't have a tile PPU like the NES. There were drawbacks to using BOBs floating about. It makes level / collision data a bit harder to manage.

 When you're in a grid, you can know right away what is at 140, 204 (bitshifted by 4 for 16px tiles). It's could be a block, or air. Solving collisions is super easy.

When your objects do not have a simple shape and are just coordinates, they become hard to find. You might have to do something like:

Split the playfield up into a grid. In each cell, store a linked list of objects inside the cell. However, because some objects overlap into adjacent cells, we might have to check neighbour cells as well, or make sure overlapping objects are stored in the cells they spill into. Then to see if the player have collided, iterate all relevant lists and call the collision method for each object and check against player shape. This could rely on a bitmap, vectors, or perhaps a bounding box or radius check. But because the shape might be irregular, we might need to do special angle math so solve things like bounces/pushback. If we want to do an AI with pathfinding, we probably need to set up a mesh of nodes... but will the setup routine identify those barely-squeeze though cases?

For single screen games (e.g. Sierra adventures) we could use a pixel-level collision map, but for massive side-scroller game maps, it's a bit... ugly. Lemmings used brushes for the level design and a pixel level collision map, but those levels were pretty small and the lemmings were so small they probably only had one or two collision spots to check. At any rate, all this is a lot more work than using a simple grid where we absolutely know most of the facts and structures instantly.

On the Amiga, because it used Bitplanes, there were also some issues with drawing things on non-multiples of 8 or 16 I think. If a byte spilled over into the next, you (the GPU) have to read both bytes and mask your new byte onto those and write both back. If you draw on a multiple, you can just write over and forget unless you have transparency. I think... The Blitter would plop down 16 bits (pixels) regardless, in each bitplane, with a custom or global mask, or no mask. When I worked on a thing with 12px tiles a while ago I had to manually poke a special transparency bit mask somewhere in memory so the tiles didn't overdraw the next.  On a modern GPU this stuff doesn't matter, but the collision problem still needs to be solved and analog situations can be tricky to deal with.

In Aquaria and such it's all done by magic.

[Ryumaru]

I enjoy tiles for the same reason I enjoy pixelart: the limitation. If I'm given free range of placement for everything, I would become paralyzed, obsessing over the correct weight and aesthetic of each placement choice. If I'm working on a grid, these options are heavily limited. Beyond that, I now have a box I need to creatively break out of, as opposed to wandering aimlessly.

And of course, if I feel that tiles can't do what I want to accomplish, I can always create unique assets and hand place some things.