LorenzoGatti

So far it looks like a straightforward Centipede variant, with permanent tubes instead of destructible single-tile obstacles.

I'd consider a free-roaming tiled 2D environment (e.g. Bomberman) instead of a constrained side-view one: the turtle can only walk on the lower floor, so enemy-only platforms are quite pointless.
An overhead perspective wouldn't affect tubes and plumbers much and it would allow the turtle to shoot in any direction for added tactical depth (turn while moving and shoot forward; maybe shoot something different backwards with another button).

The turtle should be moving at turtle speed: the marksmanship that makes constrained movement and fixed-direction shooting with a single bullet enjoyable in games like Space Invaders should be out of the question, so I expect the object of the game to be astutely combining movement and close-range shooting to kill plumbers and hold back tube growth; it should certainly be easier to accomplish with a greater choice of movement and attack moves and with more nuanced enemy behaviour than passing overhead, laying tubes and shooting down.

Obvious complications:

• Pickup items (again, like Bomberman): bouncing shots (particularly if they can be fired obliquely) and ways to destroy tubes (maybe a limited-use helmet for head butts) would be particularly useful upgrades.
• Fixed hazards, e.g. pits.
• Flooding the map from the tubes, tile by tile.

There's also a trivial but general issue with throwing dice at enemies: you'll be shot while you wait for them to settle, and while you go wherever they land (to pick them up again).
This is the sort of hazard that could be acceptable for high-risk, high reward weapons, like a reusable high-power hand grenade that doesn't kill friends; if the weapon is useless but dangerous it will simply be ignored.

_Tinker's suggestion is a simple, principled and "politically correct" zombie control system, but it could look too dumb with concave obstacles: the player could herd zombies into a dead end from beyond a wall, leaving them there until he passes in front of the opening.
In an urban setting, the typical concave obstacle is a room with a door: quite close to the worst case and presumably very common.

You could use preprocessing to identify dead ends that should only the be entered if the target is inside, or you could make individual zombies detect that they are walled in and repel each other, and themselves from the walls, with progressively increasing force or desired distance (with the intended effect of "wasting" a few zombies to sparsely fill dead ends and repelling and rerouting others that would enter the dead end).

The second mapping has horrible seams, the texture doesn't match the UV coordinates.
Whatever UV coordinates you generate, you simply cannot expect to use the same generic texture for a sphere and a teapot.

You can run a traditional union-find algorithm on your tiles to find connected components of non-wall tiles, additionally maintaining a set of connected components and a count of the tiles in each connected component.

An array of characters? Seriously? Your map tiles are going to be far more complex than one character: in a typical roguelike game they have various properties and flags and lists of things in that space, and when you start caching pathfinding results and querying nearest neighbours and connected components your data structures are probably going to be a bit more rich than a 2D array. Even as a derived intermediate representation of screen output, one character per tile isn't enough to represent colours and bold,italic and other attributes.

I don't think lightcycles are a suitable problem domain for techniques that employ very little abstraction and directly reproduce the moves that gave good results in cases that match the current situation:

• How do you maintain high level plans? Even if you figure them out from your examples, how do you ensure that you stick to the same plan when your system extracts other examples?
  Trapping an opponent can be a very long process: in a traditional racing game stringing together good short term reactions keeps you close to the ideal trajectory, but in lightcycles the only meaningful short term decision is avoiding crashes: clearly not enough to win, since the benefit of building walls is usually reaped much later.
• Minute geometrical differences (e.g. whether one more lightcycle path can fit in a certain gap) can have a great importance (e.g.whether the lightcycle can come back through the gap or gets trapped), but not always (e.g. you might not want to go in and out of that gap in the first place). How can you be confident that an example is relevant or irrelevant?
  The state space given by lightcycle walls is huge, probably condemning your example-based approach by sheer curse of dimensionality, and decent ways to simplify it are hard to find and time-varying.

I don't see how synthesizer settings could be considered copyrightable: such parameters are only a formal and more complex counterpart of the tunings of traditional instruments. You are simply programming your synth to sound exactly like the one you found in a certain game, and the only way to do it is with an identical program. Do you worry because your flute has the same notes as the one in a record you like? Do you think you are "copying" if you borrow someone else's characteristic electric guitar effects setup? Maybe you could be accused of hacking the game you are "ripping", but it is a different issue.
Unlike actual instruments, representations of instrument tuning, e.g. a floppy disk containing a hoard of DX7 sysex dumps, can be meanngfully pirated; but still they might be too trivial and constrained to be protected by copyright.

I'd avoid setting a game about pirates in an unglamorous place (the explored and disciplined seas of the 20th century), full of unglamorous people (your pirates would be random African, Arab, Indian etc. criminals, with only their cool and unique personality to make them likeable) using unglamorous technology (rifles and, even worse, radar; offshore bank accounts; boring steel ships without guns).
A modern naval setting could be redeemed by prominent marvelous elements (e.g. a secret war of mutant superheroes, sea monsters and mystical islands against Nazi sorcerers, submarines and undersea fortresses), but the game wouldn't be about being a pirate captain.

Instead, setting your game in 17th century and in the Caribbean Sea has the advantage of interesting and likeable pirates, appropriate and fun technology, and interesting political background (including the choice of privateering for different powers or going rogue). The ultimate purpose of a "classic" pirate game could be, for instance, becoming powerful enough and uniting enough people to make Jamaica or some other major island independent from European masters and turning it into a nice place to live.
This people-oriented approach would require management of crews (recruiting skilled pirates but not traitors), managements of diplomacy (being nice to other pirates and to governors and officers), management of secrecy (mainly hiding your objectives and movements), management of finance (raising capital, paying shareholders, making long-term investments) and less focus on upgrading guns and replacing ships (a real pirate uses captured or rented ships; even if he could pay for custom-built ones, being able to wait and plan for them would be unusual) and on trading loot (a real pirate is in the business of making raids, not of managing warehouses: there are trusted partners for that).

I don't know if you can do it easily and cheaply, but maybe you can examine the texture coordinates of adjacent pixels and choose a mip level according to how close or far to each other they are.
If you compute the maximum difference between the U or V coordinate of your fragment and the corresponding coordinate of each adjacent pixel, it translates directly to the ideal texture size for that pixel; then you can use trilinear interpolation to mix the two closest mip levels.

But is focusing on only one or two stats good, bad or unimportant from a strategical viewpoint? How does reorganizing stat effect portfolios make the game more fun?

It is a traditional criticism of systems with many stats (e.g. D&D and Angband) that less important stats are an useless complication, but if all stats are important for different characters they form a coherent system (no reason to cut them) and improving the important ones is an obvious strategy that can be

• taken for granted, with depth pushed into other aspects of the game (e.g. all fighters maximize Strength, but which weapon are they going to use?)
•   not trivial to execute (mainly by working hard to obtain stat-enhancing magic or extra experience)
• limited by diminishing returns (e.g. comparing risk of death and injury with benefits of experience and loot when deciding whether an optional quest or campaign is worthwhile)

I think the main design choice you are facing is not what stats should do, but how do you plan to customize and specialize characters within the same class: with high or low values for secondary stats (e.g. Strength only for a powerful fighter vs Strength+Agility for a tricky fighter), with skills and special abilities that assume more or less the same stat values (e.g. "Dodge", "Crushing Blow", "Feint"), with equipment (e.g. halberd vs rapier), with constrained spell lists, and so on.

I don't think applying genetic algorithms to rough drafts of car controllers (imperfect enough to crash into walls) is very productive. I'd try to get a pool of cars that can finish the race first, then apply genetic algorithms with lap time (on one track, or the total of several tracks) as fitness and eliminating mutants that crash without letting them perpetuate.

To obtain a pool of decent car controllers that finish the race, you could evaluate them on a long test track with a great variety of curve and straight sections and use length of the path before crashing (not speed!) as fitness: improved mutants would crash further along, until you get controllers that finish the race and you start making them fast.

Can you explain the car controller representation and the type of neural network you are using? Are you considering speed, acceleration, centrifugal forces etc. as inputs?

• Visual Studio "Professional" adds important features compared to the free version, but magically preventing memory corruption isn't one of them.
•   You didn't even post the Asteroid class, which is the obvious candidate for object slicing. It must be an interesting class: it doesn't even set its own texture and model.
• If you don't understand and solve the problem, it will come back.
  If you don't know what whole classes of bugs (e.g. object slicing) are, how can you tell that your code doesn't have them? Inspections are difficult enough when one knows what to look for.

The most replayable games are the ones in which every game is a new and interesting challenge, and winning doesn't mean the game is in any way "finished".
This includes:

• Difficulty, even with complete information, preventing mere humans from playing perfectly: checkers, chess, go...
• Major random influences that shift the emphasis from a repeatable (boring) detailed strategy to contingencies and general principles: backgammon, poker, Carcassonne...
• Major random or arbitrary elements that make each game different, turning one game (which could be mastered) into a vast family of related games requiring different strategies: random maps in roguelike games, Dominion...
• Tight interaction between players that shifts the emphasis from simply trying to do one's best (boring) to adapting to external factors and outsmarting the opponent: RTS and FPS games, fighting and soccer games...

Note that highly replayable games tend to have many of these qualities.

• Liero and similar games have some ballistic and acrobatic difficulty, random maps (often), randomly selected weapons, and relentless realtime combat.
•   Micro Machines has little randomness, but the different levels and vehicles are highly varied and bumping and shooting other players is both tactically deep and very fun.
• Starcraft tends to have well-defined strategic "recipes", but they aren't detailed enough to be boring, as they need to adapt to maps and opponents, and nobody is going to issue orders fast enough to play perfectly in any case.

You should probably separate  loading scenes from the scene representation.
Updating a scene is part of the public interface that defines responsibilities and makes a scene a reusable "service" in ApochiPiQ's terms.
Loading a scene from a file is one of many particular uses of he scene's public interface, and most users don't want to know about it, as scenes could be populated in other ways (e.g. hardcoded for tests, procedurally, by combining stuff from other scenes, and so on) before being treated in the same way.