15 replies to this topic

[rouncer]

Are all the big games out there (including infamous :)) coded modularly? youd think they would be with internal object oriented scripts and real kick ass ai capabilities for making the really detailed action scenes in the games.

Funnily, i dont think doom 1 by id software was coded in plugins, it was all sorta packed into the exe as framesets, leaving modders limited room for modifying the game... but these days if your gonna do something serious, its probably best to get into the object oriented.

Theres more than one way to skin a cat, and if you want to go black box, theres more than just c++ out there for linking objects into useful heirarchies.

I just brought this up cause ive got a new intrepreted modular ai kit for games coming together myself, and its real exciting having a project that can never die unless you stop writing new plugs for it.
And you can almost turn an rpg into a top view shooter. :)

To be honest, im not sure why i bothered posting this cause id be pretty sure everything would be coded this way.

I saw a few posts showing off some repluggable abilities for ai controlling game objects, all you have to do is swap functions around and you can turn a curtain into a space invader. :)

thanks... sincerely, rouncer.

[Dom_152]

This a very broad question. The best answer I can think of is some might others might not. It depends entirely on what they're trying to achieve.

What sort of game are they making?
Are we building it from scratch or using existing technology solutions?
Will we be using the codebase as a basis for another game?
What programming language are we using?
What's the target platform?

You get the idea.

This is where case-by-case solutions becaomes a good idea. One size does not fit all to be cliche.

[Reedbeta]

Are you asking about plugins and moddability, or about object orientation, or about modular programming? The three aren't the same thing.

[rouncer]

They are similar tho.

plugins are modules are they not.

[Reedbeta]

Yes, but a modular architecture isn't necessarily pluggable. Plugins (as I understand the term) are an additional infrastructure on top of a modular application. Although modularity is a pretty general principle for good software design, plugins are probably only supported where there's a specific need for users to extend/modify the app's functionality - like Maya supporting plugins to add new node types or file formats.

[rouncer]

but in a modular program, even the internal infrastructure can be pulled apart and remaintained, can it not?

any type in out of each black box can be replaced with any other internally different black box as long it only maintains the right plug type.

[alphadog]

Seems to me you are heading into component programming whose most important "devices" are the components, block of code and data structures that share/support a common concern/function such as rendering, and the interfaces thereof.

Of course, UNIX is the ultimate example of component-oriented programming. Eiffel is probably the premier language for this space, but any higher-level language can function here.

More programmatically, there are a few themes:
- it's when you favor composition/aggregation over inheritance.
- Things like Inversion Of Control becomes a preferred architectural technique.
- You block off a bunch of objects or resources that share similar concerns under one "interface". For example, you block off storage of game data and create a wrapper for it. The wrapper has an interface. You can then change the underlying mechanism behind the interface from flat-files, XML, or MySQL.
- etc...

The main architectural problem is that each component needs a copy of some or all the game's data and you get into complex issues of transformation and synchronization between components. That's usually why developers, always fighting NIH syndrome, recoil from such architectures. Of course, the recoil is often magnified beyond where it should be, but it is a valid concern...

[rouncer]

with OO, (and CO? which i didnt know existed, I thought it was all OO) Function pointers are the main tool I use in normal c.

In c++ I guess they are virtual functions, letting the coder replace functions of the same type with each other is the thing im mostly talking about when I mean modular.

If there was a function in basic that let you "goto x" x being a variable line number, I bet I could do something evil in basic heading in this direction too. :)

Whats the point in modular code?
I guess for me its code reuse mainly, and unlimited extendability.

I havent read much on the topic, everything I know is self concocted and I know little terminology... but we are just talking about taking your code up a notch for more powers.

[rouncer]

ROUNCER ORIENTED

I have so many types, each type can have so much data space to store variables and each type can have a certain amount of paramaterless pointers to functions.

Each type also has a polling function thats called once per game frame, inside the polling function can call out to these function pointers which are set on type instanciation (when they appear in the game) and due to how these functions point to other plugins is how the new plugged code is inserted into the main type.

That way I can insert AI, change weapons, change the player whos controlling the object, make it go into "ride steed" mode.

And everything is controlled by replugging this main type as it goes throughout the game.

As far as I see, I can code every single object in the game this single way and its a new way to code a game.

Does this sound familiar to anything that exists already?

Its very simple, if it wasnt simple I wouldnt like it as much.

That way, youd be inserting new quests into the game by writing quest code in plugs, adding items as plugs, and everything for that matter. It all becomes code
as I see it, even the conversing with npcs would be controlled by a high level script that plugs into the brain of an npc.

[monjardin]

Yes, it sounds familiar:

Object-oriented Programming with ANSI-C

Object Oriented Programming in C

High and Low-Level C

Can you write object oriented code in C?

[alphadog]

I'd love to see a more tangible example of your code, since you seem to not have the common lingo and I'm not really 100% sure what you are talking about.

It seems like you are treating functions as first-class objects. (The link would explain better than I have time to type! ) You may enjoy looking at some languages designed to be functional languages, such as Haskell.

[monjardin]

It sounds like he is just using polymorphism to me. The C programming language accommodates object-oriented programming. You just have to provide your own plumbing so to speak.

[monjardin]

I recently programmed a pong clone into a microcontroller while evaluating different OLED displays. C is an excellent language for this task because I'm as close to the bare metal as you can get. Still I coded in OOP style with a Sprite class and Ball and Paddles classes derived from it.

#define OBJECT_CALL(object, method)             \
    ((object)->method(object))

#define OBJECT_CALL_ARGS(object, method, ...)   \
    ((object)->method(object, __VA_ARGS__))

typedef struct Sprite Sprite;

struct Sprite {
    Rect extent;
    Vector velocity;
    Color color;
    void (*draw)(const Sprite *);
    void (*move)(Sprite *, int dx, int dy);
    void (*update)(Sprite *);
};

The paddle class inherits from sprite, re-implements the update method and adds two member variables that reference the switches for control.

typedef struct Paddle Paddle;

struct Paddle {
    Sprite sprite;
    int button1, button2;
};

static void
paddle_update(Sprite *self)
{
    Paddle *paddle = (Paddle *) self;
    ...
}

void
paddle_init(Paddle *self, int button1, int button2, Color color)
{
    const Rect extent = { 0, 0, 5, 20 };
    const Vector velocity = { 0, 0 };

    sprite_init(&self->sprite, &extent, &velocity, color);
    self->sprite.update = paddle_update;
    self->button1 = button1;
    self->button2 = button2;
}

I can then use the classes polymorphically.

Sprite * const SPRITE[] = {
    &ball,
    &paddle1.sprite,
    &paddle2.sprite,
    NULL
};
int i;

for (i = 0; SPRITE[i]; ++i)
    OBJECT_CALL(SPRITE[i], update);

[rouncer]

Moonjardin, thats really clever and its pretty much what im talking about, you can actually code it a thousand different ways.

Its actually just the correct way to code once your past your newbie stage i guess, taking into account code reuse and the all important extendability so you dont have to go redesign the program just in case you forgot something.

For example, with your small design there, you could go add space invaders to your pong game and it wouldn't be as bothersome as it would be if you coded everything flat. (like basic for example)

I think it makes games better, for sure.

Theres always opportunities for more modular object oriented languages to come out, superior or maybe more custom designed to maybe making just a video game.

Thanks everyone. :)

[alphadog]

Well, I understood rouncer differently.

To me, it seemed like he was talking about plugging into classes an arbitrary list of varying functions, possibly at runtime. Sounded pretty functional to me. I guess I didn't get it right.

BTW, (Paddle *) self sounds kinky...

[rouncer]

AI -> PLUG -> NPC
CONTROL -> PLUG -> NPC
EVENT -> PLUG -> NPC
WEAPONS -> PLUG -> NPC
plugged in buddies.

Only problem is the weapon gains the characters brain in a way that the weapon controls the character not the character control the weapon, get your head around that, and get your head around this...

Make you smoke pot out of a stone bong hitler.