Most Metroid games don't have pattern bosses. It happened in the Metroid Prime series, and a few scattered bosses in other games (e.g. Metroid Queen in the second game), but for the most part Metroid bosses involve the player and the boss slinging attacks at each other, the player dodging as best they can, and one side eventually falling over.

I would generally classify a pattern boss as a boss who would be unbeatable if he didn't use a specific move that lets you hurt him. Changing the context of that move is good for keeping the fight fresh, but the concept is the same. In that sense K.Rool of DKC is a pattern boss. He slings a few attacks at you, then gives you a cannonball which you use to hurt him.

Lavos Core sets itself up as a flunky boss -- there's the alien-astronaut main body, and then two bits that help it out. But when you kill the main body, the fight doesn't end, and one of the bits revives the main body. Thus that bit is actually the main boss, and the body is just its offensive "arm".

The Zelda-style fights are what I'd call "pattern bosses", where the bosses are invincible except for when it's your turn to hit them (which may come after you counter a specific attack they use, for example). Generally I find these fights not very interesting, since a) once you figure out what you're supposed to do it's just a question of iterating the strategy until they fall over, and b) they'd never lose if they didn't do that one counterable attack since they're otherwise invincible.

There's also "avoid and attack" bosses, which the Devil May Cry series (and brawlers and the like) use a lot, where the boss is always vulnerable, but attacking him can be risky depending on what he's doing at the time. This can devolve into waiting for the boss to attack, dodging the attack, and then countering while he's in the recovery portion of the attack animation, but the key is that an aggressive player can keep the heat on the enemy all the time, only stopping right before the enemy does his attack.

Of course, non-3D genres tend to have different boss mechanics entirely. One of my favorite sets of bosses is from Einhänder, a 2D scrolling shmup. The bosses are built up of components which can be individually destroyed. The boss itself will die once you destroy its core, but until then its attack patterns keep changing as you destroy weapons, remove its bulky body armor, expose backup weapons, etc. One enemy you can fight is a giant mech, and you can eventually tear off both its arms and all of its torso weapons, leaving it with only a shoulder-ram option for attacking. Awesome.

A networked real-time (low-twitch) strategy game where the focus is on manipulating the game map instead of moving units around. At the start of the game, each player has a small area of influence, in which they are literal gods. Expansion is done by building shrines; shrines must be built within the player's current area of influence and expand that influence (much like building creep colonies for the Zerg in Starcraft). The player's ultimate goal is to expand, destroy his opponents' shrines, and have a supermajority of the map under his control.

The trick here is that there are numerous different terrain types, and shrines spread influence much faster over coaligned terrains than they do over opposed terrains. For example, a forest shrine will rapidly take over adjacent forests, and fairly quickly handle grasslands and jungle, but has little effect on nearby deserts or mountains. Thus, much of the gameplay is in manipulating the terrain and weather in the regions you control so that terrain outside your area of influence is converted to be favorable.

Terrain is determined by a combination of available water, temperature, and elevation. For example, high water and heat make a jungle; low or no water makes a desert. Water is transported by rivers and weather; temperature is determined by the proximity of magma. Because actual biomes would make this already-complicated fluid sim even worse.

The player's ability to influence the board is strongest in his own domain, weaker in regions where nobody has influence, and nonexistent in areas controlled by his opponent. This is represented by the cost for these actions varying depending on board control. The player has a pool of energy which is depleted by taking actions and replenishes slowly over time.

Thus, the player has the following abilities available to him:
* Construct a new shrine. This can only be done in tiles where the player currently has at least 50% influence (and if influence drops below 50%, the shrine is destroyed). Shrines continually spread influence to nearby tiles, but have no effect on terrain. Shrines also restore energy to the player based on their terrain; the more tiles in their region match the terrain the shrine is built on, the more energy the player receives.
* Raise or lower terrain. This can do such things as flood areas below a now-elevated lake, redirect rivers, block airflows, etc. Sufficiently high terrain turns into the "mountain" terrain type.
* Create fluid sources (wind, water, and magma), which disturb the fluid simulation in various ways.

The fluid sim for this game will be necessarily chunky (vaguely Dwarf Fortress-style), since it needs to be feasible to transfer game state information across the network, and of course players have to be able to reason about the current board state, which precludes things getting too complicated. For now I'm thinking the board starts out ringed by mountains except for specific ingress points (where air comes in) and egress points (where air, water, and magma flow out). Magma will generally flow out the bottom of the world, I suspect; water will mostly leave by evaporating and going out with the air.

Potential issues:
* Flooding the world. Well, whoever has the most land left wins, I guess.
* Burning the world. Control desert -> win? Magma needs to get used up in burning a tile, I suspect. Otherwise, balance this by the cost of making a volcano and the rate at which new magma is generated.
* I'd like players to be able to burrow under their opponents and create volcanos and springs where they aren't expected, but that seems like it would be tricky to implement. There'd have to be some kind of layers system, and then I start thinking about tectonics...
* I've never written a fluid sim before. Oh well!
* For that matter, I've never written a networked game or a true-3D game before. At least I know how to do basic networking and OpenGL already; it's just a matter of combining them...

Just as a random observation here: Super Metroid has what is known as the "noob bridge", a bridge made out of crumbling blocks. You can run across them just fine, but if you walk then you fall through. Why is it the "noob bridge"? Because it's there to teach newbies that there's a run button. You'd be amazed at how many players get roadblocked by that thing (and, apparently, didn't look at the controller config and/or try out all the buttons).

Super Metroid does also have a few useful glitches that are only accessible by modulating your use of the run button, but they're pretty obscure and aren't really what you'd normally consider to be a feature unless you're a romhack creator.

I bet that numpy + scipy would allow you to speed up the neighbor-counting. I want to say that the search terms "convolution" and "kernel" are relevant here but it's been a long time since my image-processing class in college.

Grids of tiles do scale better and are easier to make pathfinding for, but I only heard of connecting blotches by lists of which one can go where (because of their irregular shape).

Actually, brog's right and I was wrong -- blotches are pretty easy to deal with from a computer perspective, easier than tiles would be. You just need to get used to thinking of the game in terms of a (mathematical) graph of nodes and edges. Each node is a blotch on the map, each edge is a shared border between two blotches.

Want to pathfind from blotch A to blotch B? Do a breadth-first-search starting from A and continuing until you reach B. You can even adjust the route the AI is likely to take by "weighting" edges differently based on the game state and using Dijkstra's algorithm to find the best path. For example, you could increase the weight of edges that require the unit to pass through enemy terrain, decrease the weight for passing through territories that have developed rail systems, etc.

In general, graphs are amenable to elegant recursive or queue-based algorithms that should make analysis rather straightforward.

Tiles are more amenable to algorithmic analysis of the board; Risk-style splotches create more variety. It's much harder to make a natural-looking map with chokepoints, territories with many borders, etc. if you're working strictly within tiles than if you work with irregular blotches. However if you want to have things like elevation, terrain effects (jungle, desert, etc.) then blotches become unwieldy because they tend to only work reasonably at very large scales.

Do you even pay attention to the world you live in?

Yes. Are you going to sling insults, or do you have something constructive to do like point out where you think I went wrong? Economics is a hugely complex field of study filled with irrational actors. If you think you can model that easily you're delusional.

To take one example, Puzzle Pirates has crafting stalls that players can buy, which basically enable access into the crafting portion of the economy -- they can buy raw materials, store them, use them to make goods, and sell the goods to other players. A naive economic model here would have users buying and running stalls so long as they could make a profit or at least break even.

What often ends up happening, though, is that players buy the stalls and run them at a loss for extended periods of time, propping up their stalls with their own "supplemental income" from the rest of the game (i.e. where most non-crafting players get their money). Because they're more interested in participating in the crafting aspect of the game "as an owner" than they are in running a profitable stall, this still makes sense to them, even though it's completely bonkers from a macroeconomics standpoint.

Of course such behavior still makes sense from a microeconomics standpoint, since the player is deriving non-money good from running the stall (satisfaction of participating in the economy) sufficient to make up for the extra cost they have to contribute. On the other hand, the players running at a loss are also harming the economy by undercutting players who are trying to run a stall "properly" with no outside infusions of capital after getting set up. Arguably, irrational economic action in the game is a form of griefing; certainly it's worth considering trying to set up your economy so that poorly-run stalls can't exist for long.

Economies are tough to model. You have the basics there, but getting them balanced so that there isn't inflation or deflation is going to be fiddly work.

The only two MMOs I know of with well-developed economies are EVE and Puzzle Pirates; of the two, Puzzle Pirates is far more accessible, but EVE has more detailed publications on the status of their economy (that said, I'm pretty sure I've seen some PP articles on economies on their various servers). It'd be worth checking both out to get some idea of how their economies function.

Of the many languages I've tried, I have to say that Python does the best job of getting out of your way and letting you focus on the design. It's a good place to start learning.

However, good program design requires a lot more than just practice (though practice is a huge part of it, don't get me wrong...). Understanding things like runtime analysis, data hiding, interfaces, and so forth (just to name a few!) are all key to making large games; without them you'll end up with a slow, buggy, and unmaintainable mess. I got a primer in all that stuff at college, which then solidified as I tried to work on my own projects. It's of course possible to self-teach, but I wouldn't know where you'd start.

My project uses interpolation for rendering, and it really does make a big difference. It's also not too hard to do; I just store the previous position of each sprite, and the render function takes a number between 0 and 1 which is the fraction of time that has passed since the last physics update. Just do a weighted interpolation (prevPos + progress * (curPos - prevPos)) and draw the sprite at that location. I have it capped to always render at least once per physics step, so there's no issue with physics running away from rendering, but as long as the computer can keep up, the animations are significantly smoother than they would otherwise be.

Non-interpolated sprites really don't look all that good unless you either have a very high physics update rate (which, depending on what you're doing, may end up limiting how old of a computer you can run on) or have sprites that don't move very quickly.

Also, if a certain information is important to the player at all times, show it at all times and as precisely as possible (unless uncertainty is part of the game's design of course). I personally prefer health bars or numbers over, for instance, gradually turning the graphics black-and-white, as seen in Uncharted and Infamous.

Something interesting I read in the Penny Arcade newsposts is that their D&D group has taken to having the DM be responsible for tracking each character's hitpoints. The players only get general descriptions of how badly they just got hit ("The orc's swing opens a deep gash in your side", "you get lightly singed by a fireball") and healthy they're feeling. This turned out to vastly reduce metagaming ("I still have 20HP left; I can survive another round of combat before needing to be healed") and thus greatly increase immersion.

Sometimes, numbers get in the way of enjoying the game.

It took until I saw the "buttons" label for me to realize that Wyv is a guy in a red coat, not a dwarf with a red beard. One of the dangers of tiny spriting, I guess.

Best of luck with the rest of the series!

So where does "action RPG" end and "beat-em-up" start? Is Devil May Cry an action RPG? It has realtime combat and upgradeable equipment, but I'd wager most would call it a 3D brawler instead of an ARPG. Do you need more plot? DMC3 had a fairly involved plot (at least as involved as, say, Secret of Evermore). More characters? "Town" segments where you can wander around and talk to people?

Take a look at Half-Life 2 for a good example. At the start you're standing in a train car -- there's nowhere to go, but you can walk around and look at things. If you don't figure out how to do this on your own, after a few seconds the game will prompt you with the appropriate controls -- but if you do already know this, then no prompt occurs, and you can spend your time just looking around and annoying the other passengers. That gets your basic movement done, then each new element is introduced as it's needed. You aren't told you have a flashlight until the first time you have to crawl through a darkened area. You aren't told how to attack things until you're given your crowbar, and you aren't told how to switch weapons until you get your pistol.

Part of this is also that each of these new elements is introduced in isolation. The game starts out with only movement. Then only picking up and dropping objects is added. Then only melee combat. Then only simple ranged combat. And so on. You're given plenty of time to figure out each mechanic before the next one is introduced. Obviously if you start out with the player able to do everything, then you have to front-load more information...which is a good argument by itself for introducing mechanics slowly and one at a time, so long as the gameplay doesn't suffer for it.

The water in the tech area is part of the "pit" tunnel type, which currently only tries to place itself in the tech region. The idea there is that you have to jump from pillar to pillar and if you screw up you fall into the fluid, which might be nastier than water depending on how early that particular map is generated. It's not very evolved right now. I need to add an expected exploration direction for each tunnel and bias the feature placement around that (so e.g. falling in could require you to walk back to the start of the jumping puzzle).

My current expectation with bosses is that each will be largely confined to a specific arena that won't take up too much space on the map -- a few tunnels' worth or so. Trying to plan out a race without creating a large empty space that isn't very interesting to explore would prove difficult. I'd also like each boss I make to have difficulty level tweaks so I can have it show up earlier or later in the "powerup chain" and still have it be a reasonable challenge. Ideally every boss should be a good fight both when the player has absolutely nothing and when they're armed to the teeth, though that may prove difficult to implement.

I do plan to leverage boss tropes I like, though. Reflected attacks (so long as that's not the only way to damage the boss), evasive bosses, big bosses, etc. No puzzle bosses. They have terrible replayability.

Figured I may as well post this. I've modified the generator to encourage loops within a given region, which should make exploration less tedious. I've also fixed the pretty-printer, so now you can see just how barren the other regions are in comparison to the "jungle" region.

The greyish areas are filled with water.

Here's one I found in my code just a bit ago:

Code:

if not shouldContinue:
    continue

Of course, when I named the variable, I was thinking in terms of "should continue with the rest of the iteration", not in terms of Python keywords...

Also, some of you might be interested in this blog I found on the internet! http://simblob.blogspot.com/2010/09/polygon-map-generation-part-1.html

Neat! I stumbled across a similar method for my game -- I semi-randomly place nodes, generate the Delaunay triangulation, then use the edges in the triangulation as the basis for a spanning tree. I wrote up a more detailed article here. The main thing of note, I think, is the method I use to create tunnels that press up against each other while maintaining a wall between them:



Here's an oversized map generated using this system. I wouldn't want to play this map, but it's neat to look at.



EDIT: reading back a couple of pages, someone was experimenting with water fills. Jetblade has water fills, as you can see in the large map. Moreover, it has fills with consistent water levels throughout a given body. This is done by floodfilling with the extra rule that the floodfill is only allowed to move to higher tiles if it remains below the current water line. Here's the code for the water "environment effect". It's moderately lengthy but should be fairly self-explanatory.