Looks like I left my power adapter down there. I will be getting a replacement today...

My back is present, I am not.

That was probably our least talkative jam in a while.

I resolve the "carbon copy" problem by inventing or borrowing design models to work from. Each game I make is a combination of "things I like" (copied ideas) plus some theoretical experiment, so a combination of original elements and familiar tropes are always present. Over time I refine what works and discard what doesn't.

I'm using these models while making Moto, at the moment:

Piece-centric design(think of fun pieces to play with first, let mechanics and dynamics emerge from them; this makes the game naturally interesting and self-tutorializing)

Game dynamics as systems of interacting feedback loops - the actions of one player on the game world or on other players can be broken down into various "loops" which describe how game mechanics are used. I apply this to some very high-level concerns like "how the game markets itself" and "how the game is paced."

Bartle player types to add breadth to the core gameplay; on top of the basic dynamics I search for "things a Killer likes," "things an Achiever likes," etc. and find ways to insert them into the gameplay.

Language is the foundation of culture, not artifacts or higher level concepts like "art" or "science".

We can use artifacts to probe into people's state of mind at a particular moment in history, and we would call those part of the extant culture - there are tools we used to make use of  and have since discarded, for example, even going back as few as 10 years(fax machines? pagers?) - but we need linguistic abilities to interpret the artifacts correctly, else they would just be "thingies" we can't understand.

We would have trouble even distinguishing between human artifacts and animal skeletons, as there would be no history, oral or written, to draw the ideas of "prior culture" from. We would see that there is some difference, when they are placed in front of us, but we would have to individually invent all our concepts of how they differ from scratch.

Likewise, the higher level concepts need language to be described, and might as well not exist if they can't be communicated.

I'm pretty sure my game is (usefully) Turing-complete now.

In the last week I've added:

• Electricity: electric generators make "pulse" entities that follow the circuit, splitting at intersections unless otherwise directed. Circuit designs can force merges or delays, enabling pulses to be timed and ordered.
• IR sensors that send pulses each time the player crosses them
• Turrets that fire bullets on each pulse, which can turn the generators on and off
• Faucets for rocks, sand, bombs powered by electrical pulses

Between those, you can make some absolutely diabolical traps, and (someday, if someone feels up to it) computers...the pinnacle of sandbox gameplay.

Not grumpy right now, just ambivalent.

--

I'm writing another bit of collision code to represent the movement and interactions of electrical pulses as living entities, sort of like in

but more generalized to tile-based circuits, and not really focused on killing the player so much as a mechanism to drive Rube Goldberg creations. It's very special-case(cardinal directions, constant speed, etc.) but that doesn't make it any less tedious.

--

I just refactored a whole pile of stuff, originating from a little change in the tile data structure:

Code:

tallIdx : Int // the "tall piece" that acts as part of the environment
entIdx : Int // the "entity tile" that spawns into a real entity at scene init

to

Code:

tallIdx : TallDef // pointing to a definition class so I can easily get properties, costs, display methods, etc.
entIdx : EntDef // similar

It touched almost all of the gameplay code in the end. Only took a few hours though and it means I'm no longer doing silly things where I test six times to see if tallIdx equals one of the six tiles that all share the same properties.

Another debate leading into definition wrangling.

"Maintainable code" and "pretty/polished code" are two different attributes. And two different programmers will come up with different estimates of these attributes for almost any given listing.

My own definition of maintainability is "can be easily changed later." Examples:

The Doom code that Jon Blow speaks of is maintainable by virtue of doing maximally simplistic things where possible, because the simple methods are short to write and easy to comprehend, so there's few risks if they have to be blown away later.

Demonstrations like the 200 line TCP/IP stack show that we can achieve massive simplicity gains by changing our view of the problem, even if it means a somewhat complex construction(a new language) along the way. So maintainable code is not just "dumb" code either. It's entirely possible that the Saturated Dreamers source could shrink to under 5,000 lines if it were approached with one or more customized languages. That is a win, and not just in a software-engineering sense; it will help the game design too by enabling faster iterations.

What Blow argues against is - basically - overengineering software, which is always the wrong thing. It can occur because of a misguided ideal of "good" and "bad" code(speed, modularity, etc.), or because you fear something you don't understand; either way, you work hard to "protect" against the percieved problem. The resulting code ends up being a bigger problem.

I frequently see that programmers equate smaller issues of style, structure, commenting, and convention with maintainability, but I see them as a form of "code polish" and not a means of illuminating the problem itself in the way that occurs in the above examples. I think rinku is arguing mostly against these practices, which are of the most benefit to a large team working over decades, and not to solo indies who ship in weeks or months.

Your own codebase is almost never as bad as you think. Just bash away at it for a while and you'll pretty quickly figure out something refactorable. Refactor that. Rinse and repeat until you're ready to work on features or to turn bits into library code. The real nightmares come not from your code but from multiple people's code interacting with subtle differences.

In games, a lot of the code is pretty throw-away because it's all one big messy integration job. What you're left with after a project is over is some tuned data structures, algorithms, and a few "main loop" type things. Just keep the "points of integration" small(even if they look ugly) and you won't have many problems.

well you could probably call get/setpixel32 for each pixel of an entire 500x500 bitmap in real-time still as long as you remember to lock the bitmap first.

I have some experience with making drawing tools in AS3. Image size is the main pain point here. It's a bit too slow to just use setpixel everywhere if the image is largish like 500x500 and you're doing a real-time thing like brushes where doing it at high FPS matters, but starting from a Vector and then regularly emitting the result to a bitmapdata scales out pretty well.

That said, if it's a pixel art tool, single images that cause a performance problem will be the exception.

Re: indexed vs. RGB - the utility of a "hard" indexed tool is lower today than in the past, the platforms indies might target are mostly high-end and don't need to coordinate one large shared palette.

So as I perceive it "implicit" use of an indexed palette is better than literally writing the data that way; it's cheap to rewrite the palette of colors-in-use as the user works, and just not add functionality that causes an explosion of unique colors - a "fuzzy brush" type of tool could simply posterize down to the working palette for example. This would also help make for a better treatment of alpha, which is poorly resolved in the pixel art tools I've seen - Pro Motion for example treats it as a magic masking layer with a special mode to itself...super-confusing stuff, and it doesn't seem to fit into a typical sprite workflow well.

My new game, a simple puzzle/action platformer. Moto tries to get the gear and then reach the exit. You can build your own lair and share it with others. There's an in-game currency called "scrap" which you use to build lairs. Completing other people's lairs, or other people finishing your lair, will give you a bigger scrap budget, so that you can build bigger and more complex things. (Once earned you don't lose scrap; you can revise as much as you want as long as you're in budget.)

An 8 minute introductory video I did last week(it explains the concepts with some extra detail, and is the closest thing to an instruction manual right now):





Play the game:

http://www.ludamix.com/games/moto/

or if you want to play a level:

http://www.ludamix.com/games/moto/?u=Triplefox

There is an optional $5 "alpha pre-order purchase" which you don't need to play. It gives a scrap bonus and later will give some sort of exclusive feature - more pieces to play with etc. I plan to keep developing this and adding more features, maybe get some better art+sound...this is just the start.

Notch did go too far to claim what the technology is and isn't; however there are numerous points which need addressing besides the ones brought up by assuming an SVO approach.

The biggest one in my mind is pipeline. They show off a poly->pointcloud converter, which is great, but what kind of compilation time are we talking about? And how do you compile the final world; are there any tools? If the numbers are more than "a few minutes per asset," and no tool support exists for integrating a final scene, it is out of the question to use this for a game even if it delivers on everything else promised. Iterations will take too long; you will be more likely to achieve a cohesive aesthetic and hit design goals using other, proven technologies.

Resource consumption is another open problem. If the tech demo is using too much memory or cpu time, there will be no room left over to run a game with animated characters and collision and particle effects and sounds and HUD and all those things that make video games "alive." Since they haven't demonstrated these things we have to assume the worst; that an actual game running this technology will have lower quality than is shown in the video.

Last of all, I don't think there's demand for this. The portion of the market that outright demands more detailed polycounts(vs. improvements in lighting, texturing, animation, shader effects, etc.) is quite small. And this is far more than is necessary to round out blocky silhouettes; there are existing real-time subdivision/tessellation methods that the video card industry has pushed for at least twice now(ATI back around 2000, and nVidia



). To date they haven't been much used for games because the polycount can still be pushed in base assets, but within the next few generations the approach is likely to bear fruit. The linked videos put "Unlimited Detail" to shame.

If you actually want to write code in the textual form you might as well bite the bullet and go for a parser and pretty-printer. General-purpose languages shoehorned into data formats are fairly atrocious to work with no matter what you do - YAML is the closest to sane, since significant whitespace removes a lot of the clutter, but it's a complex format and doesn't have great support everywhere like XML or JSON.

But use-case is the thing. If the only reason you need the text form is to do initial testing, some copy-paste, or search-and-replace stuff, it can look pretty crude, as long as you can still do those operations in the text editor.

The bit of advice I typically offer in these threads is to look up and study computer science course material(e.g. a college syllabus or textbooks) after you learn some programming language syntax, as that's probably the last major threshold to cross before the possibility of programming "anything" becomes real.

(That said, CS gives a warped view of the programming world with its emphasis on academic correctness/provability/optimality. It's entirely possible and even preferable to use "dumb" or "caveman" techniques in game programming, if it makes it easier to change the design. See John Blow's talk on this for more.)

And in the meantime there are many other skills to develop in "executing" a game design besides coding - making the content, adding "polish" elements, bringing the game to a shippable state, and promoting it are all huge endeavors that involve both named and nameless skills, and you have to have experience at all of them to know what is involved and whether it's out of scope for you. Always be starting something, and you'll be on the right track. Finishing something is even better but you can't expect to get it right until you've failed a few times with those "nameless" skills.

Some sarcastic answers:

The idea guy. Cause you need ideas.

God. Because the best games are divine works.

And my serious one:

Skills matter far less than mindset and management; while you can make the argument that a good programmer is necessary to engineer more complex things, that's an argument for minimum requirements, and the assets have minimum requirements too(art style, sound fidelity, etc.). A development team with modest skills that is organized to a coherent vision will be able to design around these technical limitations by picking modest goals for the programming, art, etc., and not overdoing their scope. If they aren't all on the same page, though, it doesn't matter if they're a superteam, they won't even be able to ship.

And, surprise surprise, this has already been demonstrated and put to rest within indie games; for example, Derek Yu made Spelunky in GM by himself. He worked in all the roles, even though he's known primarily for his art skills. XBLA Spelunky has a full-time programmer working on it, but his job is relatively straightforward - take the original game's vision, and engineer it more tightly with some new features. So adding more skill  makes the game more polished and more marketable, but it's not the same as making the game.

For comparison, there are innumerable proud-programmer projects that litter the floor here and elsewhere through the history of video games. They had code without a purpose, or code built for a scope that couldn't be matched by assets. Similarly, artists and writers will push out mountains of assets intended for games, but they don't make actual game designs. And designers will write up docs and theorize on all sorts of things, but then fail to make a functioning prototype.

And there are many big-budget retail games that got a large, skilled team together, shipped and made it to shelves, and then failed because they were "zombified" games - while they look and act like a game, and pull off a great presentation of skill, they don't deliver on basic expectations.

Fortunately, all of the skills can be learned in "fake it till you make it" fashion, even game design. So to me it really just comes down to the mindset.

I use XML very rarely if I have a true "document" type that looks like HTML.

If it's just data JSON is almost always better. The meaning is far more clear since JSON doesn't have a property/node distinction.

If I want even lighter syntax I can take a day or two out to write a DSL parser.

You want to use modulo.

(10 * sin(n)) % 2

would be somewhere in the ballpark.

-if your objects are relatively uniform, it can be better to increase the cell size so that it's larger than the largest object and then only track the single cell containing the center of each object (rather than dealing with all cells touching the object, which is more complex) This also really helps if you're doing a "persistant" grid (i.e not resetting+reinserting each frame, but tracking and moving objects from the previous frame) since it simplifies the implementation a lot vs an "an object is stored in a variable number of cells" approach.

You have to include a minimum of four cells because of overlap when the center is near cell boundaries; so either you search more or you store more. You can't get away with one-and-only-one unless you are moving in exact cell increments.

SAP does not face this kind of problem which is why I consider it simpler as a general-purpose algorithm(even though the basic concept of "how do I iterate over the list after it's sorted" is tricky).

Have you tried one of my methods yet?

I tried implementing the "sweep" one.
http://pastebin.com/ALMbCASg - Sweep class

In every moving body, every frame, I do this

Code:

MinX.Value = Left;
            MaxX.Value = Right;
            MinY.Value = Top;
            MaxY.Value = Bottom;

            World.JasmineSweep.UpdateBody(this);

            List<SSSPBody> bodiesToCheck = World.JasmineSweep.Query(this, 10000);

It seems to work, but some collision outcomes aren't the same as the old collision system.
The problem here is that it's too slow. 500+ objects run at 6-7 FPS.

This code implements a simplistic sorting algorithm in UpdateBody, which is almost guaranteed to be buggy and less optimized than the native sort in the List class. So to make it faster, replace that pile of code with a sort call, using your own comparison function if necessary(might not be needed, dunno how "smart" C# sorts are).

To make it correct, you'll have to rework Query too. Points.indexOf() is a very delicate way to do things; when two points overlap it'll just take the first one and that will be wrong for the maxX case. It's easier to run the loop in such a way that it stops when it goes _past_ the ending boundary. But that's not all...

It's faster to run all queries in a single pass because then you don't have to go "forwards and backwards" - you can travel in only the left-to-right direction for each body and only look for "right overlaps left" cases. It still picks up all of them, because contacts will always have a right overlapping a left at some point. You don't need the other unless you're doing them one at a time. So don't do them one at a time. That halves the total time of the query.

First of all, don't do SAP with two axes, it's a premature optimization:

The average-case overhead of sorting two large lists is larger than the average-case overhead of brute-forcing entire rows or columns, especially in the 2D case: Since you already know at the time of collision that they collide along one axis, you only have one more comparison to do to have a complete AABB, which is very cheap. The only time this isn't true is if you set up a pathological situation where hundreds of objects are sitting in a row and the combinatorial explosion occurs. If that happens, then you can think about sorting the second axis too. It has never happened to me.

Second, the implementation is over-abstracted. You are maintaining a structure for sorting and a separate structure for the actual collision, and now you have to reconcile the two all the time for sorting purposes, which is probably the source of your errors. What a pain! You're not going to swap out broadphases very frequently; if you do, it won't actually affect the narrowphase, so it's not worth it to do this tricky abstract implementation. Instead, get and use an actual position along a specific axis for sorting, and you'll have it integrated and working with less total code and a lower likelihood of error.

This is my AABB-only SAP coded in haXe, it could be extended to other shapes by adding another collision check after collidesX():

Code:

all.sort(sortY);

for (n in 0...all.length)
{
entEnt(n);
}

...

public inline function sortY(a : JShape, b : JShape)
{
return Std.int(a.ry-b.ry);
}

public inline function entEnt(n : Int)
{

var pos = n+1;
var cont = true;
var cur = all[n];

while (pos<all.length && cont)
{
var other = all[pos];
if (other.ry<cur.ry+cur.h)
{
if (
(
((cur.key & other.mask)==cur.key) ||
((other.key & cur.mask)==other.key)
)
&& cur.collidesX(other))
{
contacts.push(new JContact(cur, other));
}
pos++;
}
else
cont = false;
}

}

public inline function collidesX(ax : Float, aw : Float,
bx : Float, bw : Float )
{
return (!((ax <= bx-aw) || (ax >= bx+bw)));
}

The game was okay, but it would intermittently start sucking up an entire core of CPU and start performing like dogshit for no reason. And then be fine a little while later.