(Some of this has already been mentioned whilst I was typing, but...)

1) What the hell is level0?

Informally speaking, it's the (base) layer of hardcoded stuff created using the Flash UI drawing tools. If you create everything via ActionScript it never gets used. So presumably you must have placed something on the stage manually?

2) Can a class both extend movieclips and also inherit from another class?

No.

Once you start designing more complex classes like that (which is a good thing, generally) there are two things which help:

1) Using interfaces. Interfaces are good. Learn to love them.

2) Thinking about the difference between "class Foo is a MovieClip" and "class Foo has a MovieClip". This distinction is important in any OO language, not just ActionScript. You only want to inherit in the former case. Doing so in the latter case is lazy and a habit that can cause trouble for you as your program complexity increases.

I'm starting to think that I need separate classes for the different units in this game, but it would be highly efficient if they could all inherit some common functions from a parent "Unit" class.

In this scenario a third option would be to have Unit inherit from MovieClip, then individual unit types inherit from Unit.

As for AS3, what exactly is it that makes it easier to use?

AS2 allows you to cheat in various ways when writing things, primarily by being sloppy with types and properties. It in turn is sloppy internally in the way it does things. All this is superficially convenient, but means that as you write more complex software you will start getting nasty problems associated with this sloppiness (such as runtime type errors, runaway memory consumption, poor performance and so on).

AS3 may cause brief growing pains as you learn to do things properly, but then the compile-time type checking will find a lot of your bugs for you and everything will run faster and be more stable. There are also numerous ease-of-coding benefits due to improved libraries. For example: Not all DisplayObjects are drawable Sprites and not all Sprites are MovieClips. You can load in or draw graphical data to offscreen objects unconnected to your visual hierarchy and then add them anywhere. Clearly tremendously useful for games.

in that case it might be worth it to take the jump to AS3 instead of going incrementally through 2 first since 3 is going to force you to forget a couple things you learn about in 2

Seconded.

Also, AS3 is actually much easier than AS2 overall. Even though it might not initially seem so to an AS1 programmer, it simply has fewer nasty gotchas and pitfalls.

void pointers are about the most dangerous things in the world, I think...

Yup. They did a controlled test under laboratory conditions comparing a void* to a tiger with a ninja gaffertaped to it. The void* was over 18% more dangerous.

[Good interface design is hard.]

Good interface design is hard. And most programmers don't learn it.

This is true, but there's a second problem which holds back games in terms of accessibility: often it's almost impossible to integrate any kind of learning system without breaking the mood.

In a whimsical game like Little Big Planet it's fine to have voiceovers and even in-game characters breaking the fourth wall and talking about PS3 controllers and button presses and so on. Indeed, the Pod even has a PS3 controller in it in game.

But if your game is a dark game of personal horror where your avatar begins the game locked in a dingy prison about to be tortured for some secret you don't even know then having a bunch of dialogs pop up talking about what all twenty of your controls do is a bit mood breaking. And even trying to discuss the problem is sometimes hard because there will always be some designers who maintain that a game with twenty controls is innately broken.

And if your game has any kind of pace to it, it's similarly hard to find a good moment to interrupt with in-game help.

My motivation here is to be able to do palette effects such as color cycling or drawing a sprite in different colors without going the brute force method of storing a sprite sheet in every possible color combination.

You seem to be having a lot of fun, so I won't spoil it by mentioning ColorMatrixFilter.

Oops.

It would undermine actionscript, which is already on shaky grounding

:D

Erm... no.

True, even ActionScript 3 has a few nasty features left (leaky local variable scopes!), but there's no sense in which C++ or bytecode access risks replacing it. It's a high level language. As computers become more powerful, such languages become more important, not less.

When I was a little kid learning to program, my Dad showed me Fortran 77. This, he explained, was the language used for most serious programs for performance reasons (it was the fastest for numerical work due to highly optimised libraries and efficient compilers). Needless to say, I do not find myself using Fortran all that often these days!

Incidentally, for anyone who enjoys the ideas in Flatland, I recommend Planiverse. A rather better attempt at the same concept (no disrespect to Abbot - Dewdney had his work as a starting point).

Once we start talking about what causes perception of curvature, language gets in the way a bit. In normal speech, when we say something "is curved" we are talking about its 3D geometry. When we say that a non-digital object in real (3D) space viewed with the naked eye "appears curved", we're already taking into account the way our brain processes visual data before interpreting it.

The statement by brog that "the curving isn't introduced by the eye, but by the object being three-dimensional" is therefore really ambiguous. The 3D object has a straight edge, so the "curve" is not intrinsic to it. We can talk with mathematical precision about the correct appearance of a particular projection of a 3D scene onto a plane. We cannot, however, talk with similar precision about the perceptions of the human eye. And that's true of just one eye, it gets even more complex when we talk about binocular vision.

Terry> That game looks intriguing! In particular, it looks like the kind of thing I would happily spend all day playing when I'm supposed to be working. Release soon!

(Aside: is there any way to upload a picture to the main body of a post instead of as an attachment? If not, is there a thread somewhere for uploading pics?)

Didn't I just give three examples of semantic change?

Overloading and inlining are both syntactic, not semantic. To be fair you did provide an example... except that I don't think pointers really are pointers (see below).

The Doom and Quake are working examples of complex C games quickly ported to Flash with Alchemy.

Ah, OK. Apologies, I misunderstood you. When you said "being able to write Flash games in C++" I got the impression you were talking about it as an alternative to using AS3 as a control language. But yes, if you don't mind the potentially scary efficiency overheads you can use it to deploy some kinds of PC retrogames to people's browsers.

Seems like you're contradicting yourself?  If Flash is an environment, language shouldn't matter.

A very insightful comment... but I think that in fact it sometimes does.

This is caused by the way that all but the very lowest level languages contain all kinds of implicit library calls and other functionality in what appear to be language elements. If some of that functionality isn't supported in the target environment then the language won't make sense there.

Moving a high level language to a low level environment there's an obvious cheat we can do: run some kind of VM on top of the low level environment that supports what we need it to (typically stuff like runtime exception handling).

I assume that if you allocate something in C++ you have to manage that memory yourself. Potentially you'll leak, but that's C++ for you.

The trouble there is that Flash runs in a sandboxed way. Leaking memory (or worse, crashing something) would break that contract.

My guess is that malloc returns you a block of memory allocated by the garbage collector. So you suffer the insane inefficiency of having all your graphical bitmaps and so on swept for garbage collectable pointers.

As such, what seem to be "pointers" are really just indices into big Arrays!

It's pretty easy using PERL...

Code:

perl -pi -w -e 's/\/\*(.*?)\*\//\/\*\my new header here*\//m;' *.cpp

(Disclaimer: not tested the above line!)

That assumes .cpp files. Substitute the appropriate file extension.

This means that there is genuine C++ semantics that you can use that was previously unavailable.

Do you really mean semantics here, or do you mean syntax?

Assuming you really do mean the former, can you give an example please?

pointers

Which correspond to what in the VM exactly?

Outside of being able to write flash games in C++

That's never going to work well.

Flash in not a language, Flash is an environment. What Alchemy does is let you write things in C++ and run them in the Flash environment. But the other way around is never going to work. As soon as you create a non-Flash object instance or allocate some memory for something in C++, you've potentially broken everything because the Flash garbage collector doesn't know how to handle it.

Systems like Alchemy are realy doing little more than allowing you to use C++ syntax to write AS3 code. Or to put it another way: allowing you to write really bad AS3.

The main point of the system is to port libraries to AS3 which are neither space nor performance critical but which are complex enough that the porting effort would otherwise be offputting.

I'm pretty excited, cause I can't understand AS3. At all.

In an odd way that's quite amusing, because if you can understand C++ it's a bit like a unicyclist saying they really can't get the hang of a bicycle!

Personally I wouldn't mind an AS3 to C++ compiler, because my C++ is very poor indeed.

Or do you mean if you have code referring to pockets?

Believe it or not, that's Inform 7 source code!

I've written some stuff in Inform 7. It's fun.

However, I can't say I really like the language style. As a set of libraries for writing IF it's just amazing, but quite often I found myself wishing it had a more obvious formal syntax. Because the thing is, it doesn't really write like English. It reads like English, but that's not the same thing at all!

The other big problem is that it doesn't scale well. For example, in a small game it's really cool being able to write stuff like:

Code:

Understand "pockets" as the battered leather jacket.

...so that when the player writes "examine pockets" it will magically work.

But once you write something big you then get horrible namespace clashes, so later on you write:

Code:

Understand "pockets" as the trendy pink jeans.

...and you're doomed!

SDL threads, perhaps? I'd say those are multiplatform enough, right?

SDL uses pthreads, I believe.

But that's not really the problem...

It's not that finding/using a thread library is hard, it's that writing code which supports multithreading is hard.

The pThreads stuff will let you create a new Thread and call a function from it, but done incautiously this will just break everything because many libraries do not support concurrent calls from multiple Threads.

(Apologies Dacke, I don't know OpenGL well enough to suggest a solution.)

I nominate

, from the original Lemmings.

It's a great design because of the way it initially baffles weak players whilst at the same time providing them with enough tools and clues to work gradually towards a solution. And when you can see the solution it's nice and easy to execute.

The use of analog values in programming sounds interesting. It means that I could use ANY value between 0 and 1, unlike with digital values, to which there is a limit.

You have to be careful if you go above about 0.88 though. Due to lack of proper bread standards, some users will likely have bread which will become inedible at around 0.9 and possibly even catch fire above 0.96 (which will likely cause problems for your game).