Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

 
Advanced search

876970 Posts in 32841 Topics- by 24283 Members - Latest Member: gildabq52

May 18, 2013, 08:10:00 AM
TIGSource ForumsDeveloperFeedbackDevLogsSpaceBeam
Pages: 1 [2] 3 4 ... 7
Print
Author Topic: SpaceBeam  (Read 5579 times)
peous
Level 2
**


Indie opportunist


View Profile Email
« Reply #15 on: April 16, 2012, 07:26:25 AM »

I'm already preparing a feature article on structure & destruction, but it takes time to have something interesting & polished !
I'll add a link here when it's done.

By the way... yes I'm French why ? Toi aussi ? (If so PM me if you want to talk in fr Smiley )
Logged

zoq
Level 0
***


View Profile
« Reply #16 on: April 16, 2012, 08:05:57 AM »

I'm already preparing a feature article on structure & destruction, but it takes time to have something interesting & polished !
I'll add a link here when it's done.

By the way... yes I'm French why ? Toi aussi ? (If so PM me if you want to talk in fr Smiley )


I'm not French myself, but I'm happy to see a fellow European space-game maker Smiley
Logged

eigenbom
Level 10
*****



View Profile WWW
« Reply #17 on: April 16, 2012, 02:34:49 PM »

Fun video. Smiley

I just realised that this system could be perfect for using evolutionary algorithms to design a myriad of enemy ship types. The seminal work is Evolved Creatures, but basically it could work like this:
1. Set up an environment/fitness function you want the ship to excel at (e.g., distance travelled, resistance to being shot from the side, etc..)
2. Generate 100 random ships
3. Loop (as long as you want)
3a. Simulate each ship alone in the environment
3b. Choose the top N ships from that run (e.g., N=10)
3c. Create 100 children from the N ships via mutation, crossover, and direct copying

You might even be able to evolve simple controllers using tournament simulations..
Logged

Belimoth
Level 9
****



View Profile
« Reply #18 on: April 16, 2012, 06:09:51 PM »

Yesss simulated genetics, I am all in favor of that experiment.
Logged

peous
Level 2
**


Indie opportunist


View Profile Email
« Reply #19 on: April 16, 2012, 11:43:11 PM »

Yesterday I spent 3 hours trying to figure out why Unity was not working, on none of my projects... I found that my antivirus quarantined the Unity compiler, "Mono.exe" ! Wtf !

About genome, interesting idea, maybe for generating ennemies ships. It was not the main roadmap idea, but I could give a try Smiley ! First step, I can try to generate random ships.

Because to do some genetics, I think I need genes, I mean description of how to generate ship. Like
- Gene A brings more engines
- Gene B adds more turrets"
- Gene C builds more "massive" ships
- Gene D adds some tail
...
This could be a lot of work. Any idea on how to proceed, what genes use ?
Logged

eigenbom
Level 10
*****



View Profile WWW
« Reply #20 on: April 17, 2012, 12:55:46 AM »

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... Ninja

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... Who, Me?
Logged

peous
Level 2
**


Indie opportunist


View Profile Email
« Reply #21 on: April 18, 2012, 02:39:28 AM »

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 !
Logged

eigenbom
Level 10
*****



View Profile WWW
« Reply #22 on: April 18, 2012, 03:04:56 AM »

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

Kriechgebuesch
Level 0
**


View Profile Email
« Reply #23 on: April 18, 2012, 05:57:48 AM »

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?
Logged
peous
Level 2
**


Indie opportunist


View Profile Email
« Reply #24 on: April 18, 2012, 01:14:09 PM »

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 Smiley
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 ?
Logged

eigenbom
Level 10
*****



View Profile WWW
« Reply #25 on: April 18, 2012, 02:15:51 PM »

Quote
Box2d is full C#

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

Kriechgebuesch
Level 0
**


View Profile Email
« Reply #26 on: April 18, 2012, 10:12:27 PM »

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).
« Last Edit: April 18, 2012, 11:03:29 PM by Kriechgebuesch » Logged
peous
Level 2
**


Indie opportunist


View Profile Email
« Reply #27 on: April 18, 2012, 11:27:25 PM »

Quote
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 !
Logged

peous
Level 2
**


Indie opportunist


View Profile Email
« Reply #28 on: April 18, 2012, 11:35:44 PM »

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 ! Smiley

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).

Logged

Kriechgebuesch
Level 0
**


View Profile Email
« Reply #29 on: April 19, 2012, 12:07:23 AM »

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 Tongue).

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)
Logged
Pages: 1 [2] 3 4 ... 7
Print
Jump to:  

Theme orange-lt created by panic