Design paradigm... Thought?

Okay everyone,

This is an advanced topic, but I would welcome everyone's thoughts on this. Perhaps the topic is complex but the solution is simple.

Lets say you are making a mario like game. Every character that runs around in the game is playable by the player.

Lets call these characters, "Characters". Lets also assume we are not using the platformer behavior (numerous problems with it prevent me from using it even as a base, but if one wanted to use physics the needs would be the same).

Every "Character" needs a way to track whether or not it is on the ground, on a wall, etc. as well as points to check for collisions. Every character also needs a control interface. If the player is in control, the interface will get input from the player, otherwise it gets input from the AI

On an individual level, programing a character is simple enough. Each character becomes a compound object placed in a container. Other objects are used to determine state, and just to keep things clean I will also use other objects to store certain information about the player. Since the character is wrapped up in a container, object picking is easy. You can simple say things like, every tick -> set position of foot state to maincharacter image point whatever.

But, though it may be simple enough to make this, repeating the above events (can be around 600) for every character type in the game is an obvious no go.

This is where families and functions come into play. But this is also where I can't figure out a fool proof way to hook everything up sensibly. As I said, on an individual level, containers make this a breeze. But I can't get that eeze of functioning to the family level.

On the last project I switched to unity so I could code, but I want to keep the next project in construct.

Does anyone have some good hookup ideas to get this system going without a lot of tedium and code repetition, the complete lack of OOP in construct can really bite at times and it seems to take more work to get simple oop ideas working.

If one could create a compound object but have contruct2 work with it as a single object... that would be nice

container like prefab made of objects in a family... idk

I would just have one player object (invisible) and change the character sprite that I pin to it. When they are not pinned to the Player, they are pinned to a parent controller (using UID references). The player FSM could be huge but I think this would be the easiest to implement - for me, at least! Then you won't need to worry about how to control lots of different objects, each with platform behavior etc; max speeds / jump powers all contained in an array, loaded from csv for ease. If you're not using spriter, put the characters in a family and control animations that way.

I think this is what I would do, at least to start...

This is a concept I had a while ago, but I got distracted .

Colludium

Just to clarify, when you say pin, you are not meaning the "pin behavior" but rather the use of UIDs to stick where it belongs?

So instead of having families, you simply create a single character object (compound contained in a container). You then just stick the appropriate sprite to it based on what it is? What is csv?

Lastly if it is just a single character, it seems like it would be rubbish trying to figure what to do for the character laws (how fast to deccelerate, maxspeed, and so on)

For example... (burried in the fsm): Assume the player is in the air and the controller has indicated right.

velocity X += Airacceleration * dt.

But how do I know what air acceleration to use? If I was a pikachu it should be higher than a geodude.

then you would need some variable on the character that is Character type, and then you have tone of repetitive branching ifs:

if Geodude AirAcceleration = 20;

if Pick'a'Chu AirAcceleration = 10,000,000;

continued for 100s more...

velocity += Airacceleration * dt

edit

or, on start up you load the character laws from a xml file Character.AirAcceleration = xml file "characterName" AirAcceleration.

Does this make sense, or am I missing something

Colludium "comma seperated values" , excel

I think rexrainbow plugins should be added to construct. Officially bought and added. His expertise has been invaluable.

I think rexrainbow plugins should be added to construct. Officially bought and added. His expertise has been invaluable.

Yes indeed. C2 is largely devoid of usefulness without them!! I'm just putting together a quick example of what I mean in my explanation above - I'm going to ditch the csv import for now, but hopefully you'll get the idea. I'm not saying it'll be pretty, or even the best way to do it, but it's how I would probably start.

I think rexrainbow plugins should be added to construct. Officially bought and added. His expertise has been invaluable.

+1000.

Speaking of rex: http://c2rexplugins.weebly.com/rex_ginstgroup.html

Here you go - a very simple character swap platform demo link to capx. It's not pretty, but it's a simple way to inherit the platform perf of the next character. I hope it helps!

TiAm - nice, that is pretty sweet

Colludium - cool thanks for the capx. That is a neat way of handling that stuffs. Perhaps I am not seeing beyond the first order application of this but my primary concern is tied to the inability to use the platformer behavior. In order to recreate the behavior on your own, you need compound objects, and making those compound objects abstract so that anything can use them is my primary concern.

Does this make sense?

Let me see if I can fish out a capx that explains it.... well... I can't actually use my capx (Not willing to share at this point)

Basically, To keep it simple I'll pretend characterManagers, and characterColliders, are the only objects that make up the compound object.

There is two families. Managers and colliders. When a manager is created, it creates 4 colliders, and stores the uid of each. The biggest problem is actually to do with creating an object and immediately getting its uid. I had to create an object and its components and then hook it up the next fram by testing for overlaps. This is not ideal if two objects spawn on each other to start out...

C2 loves making difficult things easy and easy things difficult. What you're asking doesn't sound terribly difficult though. Just use generic input functions, UIDs, families, and maybe custom containers because C2's aren't very good.

Colludium - I remember the problem more specifically.

Okay:

Lets say you create a new character. You create a PilotCharacter manager, from the family managers. It then needs to create pilot states, of the familiy states.

But here is the thing, you can't abstract any of this away. If you have generic code in the manager family to handle creating and setting up components, those components have to be an actual type. You can't create a family and send it a type to make from. This makes it impossible for a family to hook itself up with other families. It has to occur at the type level. Which means repeating tons of hookup code, for every character. You can put specific types into a container, so that when you get a pilotManager you get the pilotStates. But again, that automatic hookup means you can't get families to talk to each other generally. A manager needs to talk to states, so then you need uid referencers as part of the family. This sort of means you are replicating code that is already happening at the container level on the specific type.

In the end, families don't solve the inheritance issue. Which is the core of the problem. I can't simply say, this specific type needs to call a function at the family level....

So in the end, lots of code has to be repeated. OOP is meant to make code simple, and need to be only written once.

Tokinsom - ya I think you nailed it, I have a solution that does that but it isn't as easy as I think it should be. It's awkward and still involves alot of work to set up a new character. Wrapping this up in a script and attaching it as a single behavior would be probably be better... but behaviors and plugins don't play nice with each other. You have to sit them down and make them play with each other. I really like the constuct way of solving the whole game engine and global events things... but man, the simple stuff gets to me. I like construct where I hate unity and I hate construct where I love unity. >.<