Try to add

Code:

if (e.getID() != MouseEvent.MOUSE_PRESSED) return;

a MouseListener listens for several events, not only clicking. Usually when you "click" the MOUSE_PRESSED, MOUSE_RELEASED and MOUSE_CLICKED events are fired in that order. Since you don't check the event's ID, your code is called three times.

Judging from the name, i assume your role is to find differences between several items that make up the buildings, remember each stage of the building's development and attach version numbers to them.

I was watching Rozen Maiden these days and it gave me a couple of ideas for a game around a doll (although the ideas came from the

more than the story itself - also i absolutely love animations of strange complex shapes mixed with drawings, music, etc :-P). A while later i come here and i see this :-).

Good luck with it, i really want to see what you'll come up with, especially with the "marionette strings" aspect :-).

Also i love the art so far. Will you keep it this way (paint-like smooth shades) or you'll go for a more comic-like artwork as in Aquaria?

I can't read anything Alevice types, because the cute asian chick is of more immediate interest.

@BorisTheBrave:
I'm not inventing anything, at least i don't try to. After i "invented" the linked lists myself out of need to get over the limitation of

Code:

var foo:array [0...30000] of something;

in Turbo Pascal (DOS era and 640k limit - or 256k practical limit if you wanted to execute other DOS apps in TP ) and learned a while (one or two years) later that this is one of the oldest things in programming, i'm pretty much sure most things i come up with have been thought by someone else, probably one or two decades ago 

What i'm doing is basically evolving what i use now and then.

I don't really care about patterns, models, etc - i might take an idea from here and there but i'm not going to follow any rules about what is good or not. My primary goal is to make software that works and is good according to my standards .

In that sense, i don't care about losing the concurrency of the messages* if adding a return value makes the programming much easier and i wouldn't think twice about adding broadcasting if that would help me.

Also i believe that following patterns is a bad programming practice because in the long term considering some things as 'bad' limits your programming imagination and harms your problem solving skills. However that is another story for another topic and some people are very "religious" about their patterns    so i won't go into this.

In any case what i do is read from here and there bits (but rarely whole stories) about stuff -especially applied things- and try to form my own based on the task at hand .


(*=of course assuming concurrency is not a requirement)

I agree with Core, animated avatars (unless subtle, like Melly's) are distracting. 

Interesting article. And its a "model" not "pattern" :-). A model is a general thing applied not only to programming languages but other things too (the wikipedia article mentions email as an example of the Actor model).

What i find more interesting is that while i didn't thought this as a system for concurrent applications, just yesterday a little before i went to sleep i was thinking that now i learnd about CUDA (see the blog article i wrote yesterday) i can probably write a virtual machine that runs small autonomous programs in CUDA kernels and each kernel being some sort of node that communicates with other nodes and the host (the CPU program) via asynchronous messages. In fact i had this "asynchronous communication" with messages for a while at the back of my mind but when you learn something new sometimes you explode from ideas :-).

But anyway thats just one of the ideas i had.

However, what i have in my mind while looks similar to the Actor model, it isn't the same. While i do use message passing, this sort of communication between nodes in a system is not necessarily the "Actor model". A difference is the notion of a central registry for the objects which provides knowledge for all objects (in Actor model, as described by the wikipedia article, actors only know about themselves and the actors they talker to). In the C example the registry is the linker who knows all the function names. Another difference is that when a message is sent, the sender waits for an answer, even if it means that the answer is that the message is ignored (nil answer), because this simplifies things greatly in a practical system (imagine if you had to ask of a monster's X coordinate for calculating the distance between it and some other object and you had to do it by sending a message and waiting from the monster to respond at some point in the future with another message that contained the answer). Which brings me to another point: the article doesn't mention what happens if an actor doesn't know about a message. The python example given in nihilocrat's link shows that an actor responds that it doesn't know the message and the way it is written looks like that it considers it as an error. In my design a sender doesn't know if the receiver will respond to the message or not and a receiver has to ignore a message if it doesn't know how to respond. This is intentional because of what i call "combined objects": that is objects which are made of other objects. A C example of a combined object, based on the C example i gave above is:

Code:

int combined_proc(object_t* sender, int msg, void* data)
{
    primalpha_proc(sender, msg, data);
    return primbeta_proc(sender, msg, data);
}

The "combiner_proc" object procedure can be used wherever a normal object procedure can be used, yet the way it acts is different than a normal object procedure's because it passes the same message and data to other objects (primalpha and primbeta). These other objects can contain incomplete logic, a some sort of building blocks, which once combined form other complete objects. An example in a game would be:

Code:

int gun_proc(object_t* me, int msg, void* data)
{
    if (msg == MSG_FIRE) { /* the entity fired */
        ... code to fire the gun animation ...
    } else if (msg == MSG_RELOAD) { /* the entity is reloading */
        ... code to fire the reload animation ...
    }
    return 0;
}

int exploding_gun_proc(object_t* me, int msg, void* data)
{
    if (msg == MSG_DIE) { /* the entity is dying */
        ... explode the gun ...
    } else return 0;
}

int running_away_monster_proc(object_t* me, int msg, void* data)
{
    if (msg == MSG_DAMAGE) { /* the entity is damaged */
        if (... health low...) ... run away ...
    } else return 0;
}

int monster_proc(object_t* me, int msg, void* data)
{
    if (msg == MSG_THINK) { /* periodic think update */
        if (... player is near ...) ... set state to attacking ...
    } else if (msg == MSG_DAMAGE) { /* the entity is damaged */
        ...update health...
        if (... ran out of health ...) send_message(me, MSG_DIE, NULL);
    } else ...other stuff...
    return 0;
}

int panda_monster_proc(object_t* me, int msg, void* data)
{
    if (msg == MSG_CREATE) { /* the object is created */
        ... setup panda ...
    }
    gun_proc(me, msg, data);
    exploding_gun_proc(me, msg, data);
    running_away_monster_proc(me, msg, data);
    return monster_proc(me, msg, data);
}

In this case the "panda_monster" is a combination of the incomplete objects objects gun, exploding_gun, running_aray and monster. With a large number of incomplete objects and different combinations, you can create a variety of complex objects. You might know this sort of "incomplete objects" as "behaviors", especially if you used Construct which is based on them (although much like message passing, behaviors are not tied to a single model and can be implemented in a variety of ways).

Of course since combined objects are basically C functions, the "combination" can be done in a variety of ways with the combined object inspecting the message and refusing to pass it in the incomplete objects or modifying it before passing it. The incomplete objects themselves can modify the message or even send messages to themselves. For example the "running_away_monster" object when decided to run away could send a MSG_AFRAID message to itself. The "running_away_monster" wouldn't respond to the message but another object, say "crying_monster" could catch it and setup the monster's state to start crying or a "hiding_monster" could catch it and make the monster semi-transparent (hide it). A combined object could use any combination of "running_away_monster", "crying_monster" and "hiding_monster" to introduce variety to the behavior of an entity and all it would need is a 3-4 lines of code in the combined object's code.

I don't think Alan Kay had a pattern in mind when he thought about OO since patterns were thought much later (i believe). In any case i didn't had a pattern in my mind when i thought about this (although i mostly based it on Windows' messaging, which was based on Mac's messaging, which i believe was inspired a lot by Alan Kay's work given Kay was an Apple Fellow at the time).

Also when i looked up "Actor pattern" in Google the results didn't had much to do with what i wrote. The only similar thing i found is this slide which doesn't say much.

Can you point me to a page that describes this Actor pattern?

In a very rare situation where i decided to write a new blog post, i wrote one titled Playing with CUDA, where i describe my experience with CUDA so far. So far means since yesterday when i installed it in my computer, ate... erm, read the programming guide and wrote this nifty raytracer.

If you're about to play with CUDA too, you can read it as some thoughts (and some parts i got wrong!) about the system. CUDA is a very nice architecture which i'm going to try to learn as good as i can since it provides many opportunities for writing faster tools and probably getting some idea on what could be done in consumer graphics hardware in the years to come.

The best Object Oriented system (one that is much closer to the original idea about OO than C++ or Java is) is this:

Code:

#include <stdlib.h>
#include <stdio.h>
#include <string.h>

#define MSG_NOTHING 0
#define MSG_CREATE 1
#define MSG_DESTROY 2
#define MSG_ATTACK 3
#define MSG_DIE 4
#define MSG_DAMAGE 5

typedef struct _object_t
{
    int (*proc)(struct _object_t* me, int msg, void* arg);
    void* data;
} object_t;
typedef int (*object_proc_t)(object_t* me, int msg, void* arg);

object_t* create_object(object_proc_t proc)
{
    object_t* obj = malloc(sizeof(object_t));
    obj->proc = proc;
    obj->data = NULL;
    proc(obj, MSG_CREATE, NULL);
    return obj;
}

void destroy_object(object_t* obj)
{
    obj->proc(obj, MSG_DESTROY, NULL);
    free(obj);
}

void send_message(object_t* obj, int msg, void* arg)
{
    obj->proc(obj, msg, arg);
}


int monster_proc(object_t* me, int msg, void* arg)
{
    switch (msg) {
    case MSG_CREATE: printf("a monster is created\n"); break;
    case MSG_DESTROY: printf("a monster is destroyed\n"); break;
    case MSG_ATTACK: printf("attacking\n"); break;
    case MSG_DIE: printf("ugh! dead...\n"); return 1;
    case MSG_DAMAGE: printf("woaaaaye!\n"); break;
    default: ; /* ignore other messages */
    }
    return 0;
}

int immortal_proc(object_t* me, int msg, void* arg)
{
    switch (msg) {
    case MSG_CREATE: printf("an immortal is created\n"); break;
    case MSG_DESTROY: printf("an immortal is destroyed\n"); break;
    case MSG_DIE: printf("i won't die that easy\n"); break;
    case MSG_DAMAGE:
        printf("your efforts are futile\n");
        send_message(me, MSG_ATTACK, arg);
        break;
    default: return monster_proc(me, msg, arg);
    }
    return 0;
}

int mouse_proc(object_t* me, int msg, void* arg)
{
    switch (msg) {
    case MSG_CREATE: printf("a mouse is created\n"); break;
    case MSG_DESTROY: printf("a mouse is destroyed\n"); break;
    case MSG_ATTACK:
        printf("squeak\n");
        send_message((object_t*)arg, MSG_DAMAGE, me);
        break;
    case MSG_DAMAGE:
        printf("squeee!!\n");
        send_message(me, MSG_DIE, NULL);
        break;
    default: return monster_proc(me, msg, arg);
    }
    return 0;
}

object_t* create_monster(const char* name)
{
    if (!strcmp(name, "mouse")) return create_object(mouse_proc);
    else if (!strcmp(name, "immortal")) return create_object(immortal_proc);
    return create_object(monster_proc);
}

void monster_attack(object_t* monster, object_t* target)
{
    send_message(monster, MSG_ATTACK, target);
}

int main(int argc, char** argv)
{
    const char* names[3] = {"mouse", "immortal", "foo"};
    object_t* monsters[32];
    int i;
   
    for (i=0; i<32; i++)
        monsters[i] = create_monster(names[i%3]);
       
    for (i=0; i<32; i++) monster_attack(monsters[i], monsters[(i*3)%32]);
   
    for (i=0; i<32; i++) destroy_object(monsters[i]);
   
    return 0;
}

It can do dynamic inheritance (just call another parent proc in messages you don't want to handle), encapsulation, interfaces (the MSG_xxx part), messaging (basically the whole thing is based on OOP by messages), abstraction (monster_proc can be used as an abstract entity) and even polymorphism if you use the MSG_xxx as an interface to actions.

And beyond all, there is nothing hidden from the programmer.

And its written in one of the most basic and simple languages: ANSI-C :-)

Sure, but writing in assembly would reduce the number of errors that get past the compiler too, wouldn't it?

No, actually it will increase it since the assembler has no semantic information. Data and code is the same for it.

The more specific and detailed you force the programmer to be, the more control they have, but the harder it is to maintain that control.

No actually its the opposite: the more detail you give over the program, the more control you have (and the less control the language/compiler has).

Replacing variable names with memory addresses would also reduce the number of errors.

No this is absolutely false. Why would you think so?

If you start coding in a dynamically-typed language with a large standard and non-standard library (Python) you will probably never look back at C/C++.

'probably never look back'?  I call BS.

Indeed i have worked with both dynamically and statically typed languages and i even wrote both kinds of languages and yet i still prefer statically typed to dynamically typed. The only case where dynamically typed languages are good is for small/hacky scripts where you don't really care what it'll look or work after a while because for the short term its easier to work with them.

As about goto, i frequently use it for cleanup cases in C/C++ like:

Code:

void foo(void)
{
    void* ptr1 = malloc(...);
    void* ptr2 = NULL;
    obj_t* ptr3 = obj_create(...);
    char* str = NULL;

    if (stuff) {
        str = strdup(...);
        ...
    } else goto cleanup;

    if (more_stuff) {
        ptr2 = malloc(...);
        ...
    }

    if (something_failed) goto cleanup;

    ...

cleanup:
    if (str) free(str);
    if (ptr2) free(ptr2);
    free(ptr3);
    free(ptr1);
}

(note: in some cases i could use alloca instead of malloc, but this isn't the case always and alloca needs extra care for a crosscompiler/crossplatform setup)

[sell]

Well after reading the latest version of his page (i just got a Digg shout for this) and the whole thread, i still don't get one thing:

I met with Nintendo in February- almost a YEAR ago- to ask for the SDK.
I did teleconferencing. I flew to GDC and had a face-to-face meeting.
I asked the WarioWorld division, and they sent me to marketing.
I talked to marketing, and they said apply with WarioWorld division!
The agreement on the application states I will receive a decision in 6-8 weeks. It has been 17 weeks!
I fulfill all the requirements- I'm a financially stable registered company with a FEIN working from a commercial address.

If he actually fulfills all the requirements, why Nintendo doesn't sell him the devkit?

You know, i'm actually thinking to re-buy Aquaria just to have it in Steam

Yeah, i know about that, but i find the window decorations to take too much space and i prefer to keep my eyes focused to a single point (center of the screen, where the image is) than moving left and right.

Is this a new genre?

Run-and-gun/action FPS games. Also action platformers (Duke Nukem 1 is one of my favourite) and one-screen platformers.

A secret area from my game.

He's fully animated, attacking and i died seconds after taking this shot.

Actually this game is by far the best :-D. I laughed a lot with it. Although its a little hard to hit him :-P.

I recorded myself (actually my screen :-P) making a treasure chest for my 3D Flash game in GIMP. Its something between timelapse (but only 2x speed - i would make it realtime, but it had to be under 10mins... also it would be a little boring i believe since i didn't thought out how to make it, i was just clicking here and there until it looked right :-P) and tutorial (since you can see what i'm doing, especially if you know GIMP's UI).

The video also shows placing the chest in the game using the map editor and the chest in-game (although in the final game it will appear smaller since i haven't added sprite scaling yet and currently it looks too big :-).