Facebook is no longer worth bothering with as of July 1st.

Why? Facebook Credits. They want to hold your game hostage to their platform, so the TOS now requires you to use their payment system and no other if you use "Facebook Platform," which I believe covers almost all of their APIs.

If you want to bash out a quick product, sure, use Facebook or whatever. But if you're in it for a longer-term business you should be the one in control, not Facebook, nor Apple, nor any platform holder. For my recent efforts I've been using the Player.IO API, which is "open" in the sense that it lets me migrate away from them if my needs change. What they offer - logins, payments, multiplayer and database functionality - is quite a bit more appropriate for indie game developers than most of these all-encompassing "platforms."

Quick tutorial. You can implement it in a number of ways but I think this is simplest.

Data structures:

1. A pointer to the full collision structure of each object.
2. A list containing all the pointers.
3. A second list containing the "open set" of collision structures we're looking at.

Then you proceed in these steps:

1. Sort the list by the "starting" position of each pointer.
2. Clear the open set.
3. Walk through the list from start to end.
4. In each entry:
4a. We remove the structures in the open set that are past their ending point(e.g. if we are using x axis, we look for x+width).
4b. We check the remaining open set against the new entry with a full collision test.
4c. We add the new entry to the open set.

As you can see, the entire collision set is traversed in a single pass. We simply go through it, adding and removing from the open set.

Sweep and prune along one axis.

It's rarely necessary to use anything else.

There are a number of potentially conflatable concepts so let's lay down some terminology:

Knockback is the process of the character getting pushed away.
Hitreact is the state of "being hit" where the character looks weak and pitiful
Stun is a state where the character gains/loses powers temporarily(e.g. invulnerable but unable to attack)
Juggling is the game dynamic where a character can be put into stun indefinitely

In a very typical effect, we would transition into a hitreact state on the collision. The hitreact would contain a timer that adds stun invulnerability and knockback. The timer decrements every frame until it hits zero; while it's active, entity-entity collisions do nothing, a blinking effect appears, and player velocity is forced upwards and backwards.

There are tons of variations, of course. To make challenging enemies, platformers often play with the hitreact state by adding an invulnerability stun, and then immediately transition into some attack state(e.g. fire weapon or charge at player) after the hitreact. Sometimes juggling characters in stun is a major part of the gameplay. Stun can be decoupled from hitreact so that the invulnerability or loss of power goes on longer than the initial hitreact effect. There can be additional states besides "normal" and "hitreact" such as "knockdown" or "recovery." Et cetera. The more unique states you have, the more likely you will need to add some way to formalize the states and how to transition between them, but for a simple platform game it's usually unnecessary.

Some second-hand tidbits on why the game looks the way it does:

Extremely long(~6 years) dev cycle. Multiple artists worked on it at different times, and assets were not always remade. Original spec called for 800x600 only. The main character has 250 frames of animation, so no, nobody's going to be modding it.

The art style attempted is way out of scope for a tiny indie team, so it's miraculous that it actually shipped this way.

I made falling rocks like in Boulder Dash, only these play well with AABB entities too(well, they die when they fall on the characters, but they can fall with accelerating gravity and stuff - I don't think I need "suspended over the head" behavior for the gameplay). It took several revisions to get this right.

How the final version is done:

1. When open space is detected under a rock or at the diagonals, it changes from tile to a spawned entity and is given a target x, an initial "safe tiles" mapping, and the safe tiles are marked occupied(these will be explained in a bit).

2. When the rock is spawned, it decides if it's rolling horizontally or falling and sets x/y velocity appropriately.

3. A collision hull is calculated. This hull contains tiles that the rock plans to travel into in the current frame.

4. The hull is filtered to see if the tiles are solid or the occupied flag is set. If the hull tile is in the "safe tile" mapping, then only the solidity test is used, not the occupied flag. This gives every rock the ability to declare movement priority over others: set occupied, then add to safe tiles, and you are guaranteed of a clear path.

5. If the size of the filtered hull(in tile count) is different from the size of the original hull, the rock's movement has been blocked, so we can despawn again.

6. The occupied flag is cleared periodically(every 12 frames, as part of the general cell-update loop) so that new rocks can move in.

Agreement with the others. What you're feeling is the "prestige trap," where it feels as if a certain quality bar of detail/effort in art is needed to succeed. There are countless examples of this not being the case. And if you're after the prestige, the AAA studios are still there, still spending multiple man-months on every character - you automatically pit yourself against them, by saying you'll have better art. But as an indie you have to accept a compromise somewhere.

What is important for game art is what has been true since the oldest known board games: People should understand what the pieces are and what they do, and be able to easily read the situation. If you do that, everything else is fixable. Some things do better in screenshots and trailers, but the rule-of-thumb minimum for market acceptance as a "pretty" game is "looks shiny and glowy, things tween and animate gracefully, text is aligned well, and I can identify the shapes." It's very easy to pull that off even if your artistic abilities are modest.

The last game I did (Subpar) I even forgot those rules and had to go back to fix up to near-acceptable over a few days; then I decided I had the core concept wrong and stopped all updates. I didn't agonize over graphics very much at all, when if I had said "oh, I need 3D and bladebla" it would have been another 6 months to discover I had the wrong concept, because I had to ship it to get accurate feedback. And I'm not really agonizing with the current game either; though I have some nice technology to bring to bear on it and am putting a pretty large amount of attention on polish-type stuff, it's 90% focused towards UX, not beauty for its own sake. The actual assets are almost all very fast to make (with the exception of character sprites, of which I'm trying to keep to a few, modular, with limited animation). Doing that lets me skip to making the game faster.

I would add that although we consider game engines to be "reusable" they are all a form of integrated software; technical assumptions are made throughout, and up to a certain point more assumptions will let you build faster(since the places where features get integrated are designed to work well with each other). Past that point of "assumptions hold true," flexibility becomes more desirable and we might call things that the game implements to be game-specific or customized. So a good way to build a stronger engine is simply to copy the useful parts of your previous games, and gradually rework them as flaws are found.

Two features with enormous impact on an engine are networking and serialization. Including them forces the data layout and event model to be constructed with much more care.

Two features that surface easily and are popular choices for newbie engine developers are rendering and collision. Both of these also turn out to be incredibly game-specific, though.

If you are looking for the most reusable bits to implement, try these:

• Event and entity models
• Timing system
• Resource management, asset pipeline, loaders, packaging
• Text rendering
• Controller support/configuration
• Misc. debug and UI scaffolding(Quake-style console, config file, a basic placeholder title menu)

With entities, events, and timing we can do a great deal to structure how the game world is organized and what happens in one "moment" of gameplay. It's a really good idea to keep iterating on these with each project, since a good organization will help to get you away from hacky game logic.

A good plan for assets - whether it's supporting file formats, converting them to an in-game representation, managing how you allocate memory to resources, how figuring out how to package the final result for distribution - is similarly very important. If it's hard to get an asset into the game, it'll probably also be hard to iterate on it.

The last bits are "nice to have." Everyone needs to throw text on the screen at some point. Almost everyone wants controller support, or at least keybind configuration. And debug and UI helps you to iterate.

Dunno why people are hating on Terraria, though, it's much better than most of the other stuff I've seen come out of the indie game community.

Come to Noisebridge tomorrow and I'll tell you how I might be planning to make a Terraria-beater. "Might" because the design of this thing keeps changing on me.

I'm making a Mega Man improvement. Sort of. I didn't start with that idea in mind, I started with a platformer exploiting cellular automata - instead of generic tile collision, having a variety of materials with different physical properties that make level design really fun(think Boulder Dash, the Lode Runner series, or Falling Sand for the kind of inspiration here - perhaps the single closest game is

). Then I made the main character a robot, and started leeching some pose ideas from the Mega Man sprites... needless to say he'll get some powers and upgrades at some point, it's hard to avoid with a well-developed robot character, it fits into "puzzle design" aspects of the game, and I've fallen in love with the sprite I made anyway.

My jump controls are actually closer to Metroid(releasing anywhere on the upside of arc gives a fall speed equal to releasing at the peak) as I find that allows for less frustrating shot placement. I'm not focused too much on pure platforming or combat, so much as "putting the robot in emergent situations" as a result of the materials interacting with each other. The robot powers can further interact with the materials, making all sorts of possibilities come up.

I'm also toying with what adversaries to give this character. Bosses don't fit into the model of this game, so the entire "robot master" model of Mega Man is out the window. But rescuing people works as a goal. So if I have a named foe it would probably be something like zombies or "grey goo" that threatens the people and has to be cleared as part of the win conditions, as well as more general hazards like rocks, fire, acid, fall damage, etc...

My main doubt about the design I have so far is that the goals might "swallow up" the fun. I'm hoping it'll be good as a sandbox experience as well as a pure puzzler, but I'm not sure if both are possible. Most of my inspirations for this design are pretty puzzle-focused.

I'd like to suggest for a group activity, discussing the merits and challenges of entering in the IGF.

Good topic

Procrastinating on a tilepicker(blah blah assets). Improving the player sprite instead.

It's amazing how much "action" you can pack into what isn't animated at all - the player doesn't have a walk cycle, just stand and jump, and yet it feels lively as long as you don't spend your time walking. Maybe I should just have him slide everywhere...

As it happens I implemented some platformer collision over the last ~2-3 days, and the result(after a few rounds of being rusty and getting it wrong in various ways) follows this fairly elaborate velocity-based structure:

0. Create velocity values for the frame.
1. Broadphase detector(in my current detector, tiles within the swept AABB of shape+velocity; later I may add other shapes)
2. Eliminate stuff that never hits after velocity is applied, it is irrelevant for the next part:
3. Get adjustment vectors(SAT/AABB) along both axes for everything left in 2; split into single-axis versions as well so that I can preserve sliding movement after adjustment.
4. Eliminate any adjustment vectors that don't work when retested; I reuse the entire broadphase for this for more accuracy. If there are any adjustments to begin with, also include a failsafe "doesn't move at all" for the case of inside corners, where collisions are found but none of the generated vectors will work.
5. Use the smallest manhattan-distance adjustment, of the ones that work.

Only implemented for square tiles against a AABB player, but I think I can extend it to moving plats or crates if needed.

To generalize, the main thing I'm doing is mapping the "OMG, geometry!11" problem into a sorting/ordering problem - of the adjustment vectors generated, look at all of them to find a "best one," and guarantee that it works before you use it; then the result will be sane and predictable. It depends a lot on having a "good" initial state(not already overlapping, velocity vectors available) but once that's in place, things can work very smoothly with few hacks, and basic entity-on-entity solid interaction becomes straightforward(add priority, order collision updates by highest priority first, higher priority objects ignore lower priority ones in broadphase; done). And if things get stuck, they can always be popped out following the main algorithm.

I'm pretty sure that I can improve my strategy more so that instead of searching for a single dual-axis vector, it combines the existing velocity and the suggested adjustments into a "valid range" rectangle, and turns that into the vector which preserves the most velocity. This will help if I want to support non-AABB shapes for slope movement or such, and still get sliding behavior without a player-state hack.

Looking forward to epic jam. Hopefully in 3 days I will have some new gameplay to show

It's a target market thing. Levels are just one of several kinds of content you could be offering(story/campaign, items and powers, achievements, etc.) Some gamers are looking mainly to maximize value for money. They'll go for free or subscription games first and foremost because they can get more content for less money. Others want a specific type of experience and will pay extra for the niche product.

So it actually depends a lot on the context. Some examples:

If it's a web portal game, you're selling it to a sponsor, not the players, and they play it for 5 minutes tops. Most of the players on portals are similarly not going to complain over short or unpolished experiences since the game is free for them and it's one game of tens of thousands. The flip side of this is that if you try to upsell players on content and not features, they tend to freak out because the value of web portal content is so low.

If it's on a platform with cheap downloadables(Steam, App Store, etc.) and you're pricing it at the <$5 level you will get buyers who, like the web portal players, are mostly interested in trying out the game. Content matters more to these buyers, but content quality matters in particular. If the game lasts a long time that's a "bonus" but it's more important that they feel the purchase was worthwhile from the beginning.

If the game is at or above the $10 price point, either you have an amazing feature to sell or you have an eye-opening, tell-all-your-friends experience on the content side of things, even if it's relatively short. Open-world/procedural content can also do the trick here. (Minecraft, Mount & Blade...)

If the game is structured like an MMO or social game, the expectation is that there's always one more piece of content to motivate a continued grind. It doesn't have to be great content, there just has to be lots and it must feel unique.

There are two general strategies: "inside corners" (walls and borders that you want to end before tile boundaries) and "outside corners" (terrain that spills over past the boundary), but they're variations on the same theme of using brute force logic:

am I next to the same tile at (-1,-1)?
am I next to the same tile at (-1,0)?
am I next to the same tile at (-1,1)?
...

And then adding the booleans into the binary keys describing each transition subtile.

The first article you link to uses outside corners universally, while the second uses inside corners.

With outside corners, you can pull the type of the adjacent tile at the same time that you do the comparison, and then use that type and the priority system to make each edge different with correct overlapping. With inside corners you only have to know that it's the same type, and can basically ignore having a priority system as long as you don't expect things to blend.

If you have the right type of terrain/art you can get around having priority too, by making the blend follow a sine curve that spills over halfway on each side.

In Magnate I use both strategies: outside corners are used for the "blend" pieces(stuff below structures) while inside corners are used for "tall" pieces(walls, trees, rocks). And I have a special case for water.

Tagging is "the way to go" IMHO. For simple tagging - one identifier key per entity, one list per key. More complex - a list of keys per entity. The latter lets you do boolean properties as keys: e.g. "stunned" "dead" "idling". The language does matter for ease of implementation vs. performance tradeoffs - but in general once you've got things "tightly" indexed, even if the add/remove of tag entries is a bit slow it'll be a performance boost overall since the bulk of your processing comes from the big iterations. and you will have tools to make those very neat-and-tidy.

My last system:

Subsystems are static classes. I give each one a reset() function. Entities are just another subsystem based around dynamic types - they're an id, tags, and a property list. The subsystems are designed around this integration strategy.

Upside: Easy to work with once it's in motion.

Downside: Kind of annoying to transition between scenes, sometimes. Not particularly error-prone, though.

My current system:

Game contains a scene, some global data(assets, user profile, a scene-transition object). The scene has a kill() method. When a scene declares itself dead it gets repopulated in the next frame(presumably with a different scene). The scene-transition object determines what's shown during the loading process - this is important for Flash-world because you can't just interrupt the loop arbitrarily, you have to use ENTER_FRAME.

Scenes are just one screen of the game and could represent menus etc. as well as in-game sequences. The game passes in delta times and expects the scene to do the rest. They exploit polymorphism(via dynamic types) heavily, and the kill() propagates in recursive fashion through the hierarchy.

I haven't determined this yet but will either:

1. Continue using static classes with reset() for subsystems other than rendering.
2. Put those subsystems into the scene object, add backreferences to the scene object, and use kill() instead of reset(). Then it'll behave like my old system but have the benefit of being in a single tree.

Kind of liking 2 right now. It seems like it might work out cleanly.

In general I don't worry about global-isms "within" the game state; you always end up with a reason to access anything in the game from anywhere. But it's still important to have a way to tear it down and populate the next instance cleanly, and to have subsystems neatly defined.

I should advertise the build script I use for SWF projects here:

http://lib.haxe.org/p/sambuild

It's written in Python and uses SamHaXe; it will give you "easier" embedding and preloader capabilities.

[Before]

I started changing the concept of this game/editor as I mocked it up and looked for ways to cut it down from it's original "physics sandbox" concept.

Before



After



Now it will use platformer physics with tile-based celluar automata; a low-res Falling Sand with one goal(to start) - reach the exit.

And instead another self-induced coding crunch to make it semi-usable within the next month, I can focus the majority of my effort on making it look+feel good and have a cool tileset.