next »

[eigenbom]

First I should say that this stuff is pretty tricky ... so unless you're super motivated I'd just stick to your original plan. Evolutionary algorithms are one of those ideas that seems really powerful, but hasn't really resulted in anything significant yet.

With that out of the way ... there's two main ways to proceed...

If you use a single string to represent your ships genome, e.g., "AAABBBABCFG" then mutation and crossover are simple: for mutation either add a symbol, delete a symbol, or change a symbol. For crossover (where two parents are mixed), just cut the parent strings in half and join the different halves together. The problem with the string-based representation is coming up with the string->ship mapping (e.g., how does "ADBFG" get turned into a ship?)

The other way to do it is to have a higher-level representation. For example you could have modules like "Engine" and "Gun" and relationships like "Attach" and "Mirror". The modules would then be connected in a graph. This is what Sims did with Evolved Creatures. The tricky bit then implementing cross-over and mutation.

If I were to do it, I'd probably use the string representation. The encoding part can be done in different ways. One way is to map each symbol to a property (as you've pointed out.) So the string "253" might mean: build a ship with 2 guns of size 5x3. The other way, is to map each symbol to a building instruction: e.g., "ABGC" might mean map to: "A": make a 2x3 box, "B": select the top-most boxes,  "G" add guns to all selected boxes, "C" take the current design, translate it by 3 units, and then mirror it, etc ...

The benefit of the instruction-based mapping is that if you let the string length change, you can evolve more and more complex designs. At least that's the theory, in practise it's going to be tricky. But .... if you can pull it off, I think it would be a crazy addition.

Whoops, I think I just derailed this thread...

[peous]

Hi

Thank you eigenbom for explaining !

I made few tests and generated random ships. These results use symmetry. (In this screen, triangle parts still have a problem).


There is noting genetic now. I have to think about genome. Both solutions could be nice, but I have to find the good operations.  Now, I add a fix number of thrusters and lasers that makes ships even.
In the future, if I let this choice to genome, I have to evaluate ship performance, and this is a lot of work !

Anyway I'm already quite happy with random generation, as shapes can be really cool  already !

[eigenbom]

Yeh, put it on the TODO list. Those random ships are looking pretty cool!

[Kriechgebuesch]

In your article you have mentioned using Box2D despite working with Unity. May I ask why you didn't use the built in physics engine?

[peous]

In your article you have mentioned using Box2D despite working with Unity. May I ask why you didn't use the built in physics engine?

1. I'm more used to Box2d
2. Unity engine is 3d, and I'm a bit hesitant in using it in 2d mode (like constraining the rotation to one axe and the movement to 2 axes)
3. I have full sourcecode for Box2d, and I can implement new shapes & new constraints if I want. As I want to have lots of shapes, lots of bullets, I want to be able to optimize if I want.

I hope I made the good choice ! Box2d is full C# so maybe it's slower than built-in physic engine... Have you any experience about using Unity physics in 2d with lots of bodies ?

[eigenbom]

Box2d is full C#

Last time I looked it was c++, or are you talking about a port?

[Kriechgebuesch]

I'm not sure about the performance of Unity physics in the kind of ballpark you're going for. However what I would like to note is that back then 2D physics weren't really supported and the suggested solution was a configurable joint which worked awful as soon as you got anything else but clean colissions with no unwanted torque. But lately they just added those general constraints for rigidbodies and they work just like a 2d engine. However if you feel familiar with Box2D anyways I don't see why using that would be a bad idea either.

EDIT: I just got an idea: if each ship is just one rigidbody made out of a composite collider (e.g. every "tile" is a box collider) the performance should be completely fine. Then whenever some parts break off you just transfer the children colliders to a new gameobject with a rigidbody. Since you're already calculating the center of gravity of the ship and all I suspect you treat it as a single rigidbody for movement anyways. The only problem I'd see with this is if you'd want parts to break off when driving into each other (joints and breaking force and all).

[peous]

Box2d is full C#

Last time I looked it was c++, or are you talking about a port?

In Unity you cannot use C++, so I used a
C# port called Farseer. Not perfect (It was ported from an XNA port so it uses a Open source version of XNA), but works fine !

[peous]

I just got an idea: if each ship is just one rigidbody made out of a composite collider (e.g. every "tile" is a box collider) the performance should be completely fine. Then whenever some parts break off you just transfer the children colliders to a new gameobject with a rigidbody. Since you're already calculating the center of gravity of the ship and all I suspect you treat it as a single rigidbody for movement anyways. The only problem I'd see with this is if you'd want parts to break off when driving into each other (joints and breaking force and all).

Guess what : That's what I do with Box2d !

Each ship is made of dozens of square shapes, but a single rigid body. All connenections are remembered in my own code and not in physic engine. And when a collition is detected with a body, I create a 2nd body and transfer elements to it. So skeleton you see here is not handled by physics and does not costs anything 99% of time.

By the way there is the new way of generating skeleton, that gives a much more logical structure than there (specially on big ship).

[Kriechgebuesch]

Oooh, well in that case!
But then I wouldn't worry about performance with either system except perhaps on mobile systems (although I say that with little experience and authority ).

I'm wondering about your "skeletons" btw. Wouldn't it be nicer if only pieces fell off that arent visually connected to another (e.g. a box with 8 adjacent boxes is connected to all of those)? It seems more intuitive if huge chunks would only break off if they are connected by only one box to another large part of the ship. Especially if the player can't tell visually how the ship skeleton is composed, or influence the skeleton himself in design (might be frustrating to have a shitty skeleton layout and not be able to do anything about it)

[peous]

Hmm to be honest I already had this feedback, but I'm a bit stubborn

I understand your doubts about these skeletons, but I would like to have a more subtle way of destroying ships than just breaking all the connected blocks. Two visually identical ships could have a different structure and be beaten different ways, finding their weak spots. I think gameplay would be more interesting and I'd like to explore this way.

So how could the player know this structure & find the weak spots ? The thing is to find a rule so structure is obvious for the attacker.

- I could display/orient the graphical blocks depending on where they are attached, or add some overlay (like the debug arrows but with nicer graphics).
- Maybe a display mode laser scan could display ship structure for a short time, and so player could find the weak spot  I like this one

If all this doesn't work (from a gameplay point of view), I will switch back to another way of connecting parts. The one you suggested, a 4-connected could work but is more classical. I could also test a 2-connected approach, or 3-connected... Just have to find a good rule. This won't be a lot of change, as the structure algorithm is not merged with the destruction algorithm.

I just thought, maybe some blocks could be 1-connected like now, and other special blocks 4-connected, and thus bring a more solid structure to the ship ?

[Kriechgebuesch]

I can see why you like the mechanic adding depth and all but I'd still strongly advise against it. Especially because if it plays anything like captain forever I'd already have a hard time aiming at specific general areas of a ship, much less exact joints of skeletons. The only case in which this would add depth is, if the player is both able to hit what they want to (at least kinda) and to actually bother to analyze weakpoints in the structure of every enemy.

If the ship would not fall apart at all and you have localized damage it would still allow for attacking decisions like would I like to disable the engines/steering or disable the weapons etc. And when building you'd still have considerations like positioning of weapons,engines and armor.

[peous]

Hmmm I understand your concerns. I don't want to stick to Captain Commander. I'd like do something different !
But I'll see what gameplay becomes. If aiming at a specific part is too complicated, I'll make ships less fragile.

Here are some more random generated ships, and showing structure. Some use symmetry, some don't.
I agree that with random ships, skeleton is really not obvious to know.

Anyway, looking at the picture, if you had one shot for each ship, I think it's fun to try to find the best spot to fire...

So, I'll do some test, and we'll see... nothing is written yet ! and feedbacks will for sure influence the result ^^

[Kriechgebuesch]

Certainly can't argue with letting the gameplay do the talking And with a combination of your seemingly open mind and a relative ease of changing the program that should be no problem then!

[eigenbom]

Got some great ideas there, I'm looking forward to seeing how it works out..

[peous]

Some tests with ship generation and trying to learn them something...
Quite failet yet ^^

[peous]

I stopped wasting my time with genetics & random generation (for now ^^) and I added some background and some "real" combat

- Explosion effects
- Background planet
- Zoom in/out
Also, enemies can now fire on you. You can see in the video that it's really hard to survive when they are setup to be aggressive !

Youtube video

I'm nearly dead at the end... need to tune this

[peous]

I'm doing some research on thrusters & trails, as I think it's one of the more important effect on a space game.

Here are some examples of quite different thuster trails:

Unfortunately I don't know much about the subject, but I'd like the player to influe to the way his thruster trails are generated.

If someone has some references on these kind of trails, some theorical information, or some techniques used in videogames, I'm interested

[peous]

Not much reply
Anyway, I made some tests about a thuster & trail generator
Having a lot of fun ^^

The grey part on the left is the engine.

All this is WIP, I'll post more when I work on my algorithm !

[eigenbom]

i'm still watching dude, keep it up, it's looking great, especially the 3d planet in the background