Sign in to follow this  
Followers 0
l0k0

Unity
Component Entity Model Without RTTI

67 posts in this topic

I'm writing my own component entity model in C++. At the moment, it is somewhat similar to the framework used for Unity Scripting (particularly in C# with templates). Since I'm still in the early phases of the project, I just used type info to handle the type based retrieval of components like so:

[code]
template<class T> T * getComponent() {
for (int i = 0; i < componentList.size(); ++i) {
if (typeid(*componentList[i]) == typeid(T)) {
return componentList[i];
}
}
return NULL;
}
[/code]

However, RTTI (along with exceptions) is typically best left disabled in frameworks and engines if possible. What would you recommend for a minimalist way to get this functionality for components only? I'm willing (and hoping) to use the preprocessor to declare classes and assign them a "type id" kept inside the components themselves. The tricky issue is that this must also support subclasses. So if I call getComponent on a base class it must also return a subclass if it is found.

Is a 32 bit type id determined at compile time my best option here? Any tips from people who have implemented the thing themselves?
0

Share this post


Link to post
Share on other sites
What I have typically seen is that there is a unique numeric value assigned to each family of components. You can assign this value either by doing it at compile-time in your code or by using some factory/class registration mechanism that handles the assignment at run-time.
0

Share this post


Link to post
Share on other sites
[code]
#define ADD_RTTI(BASE_TYPE, ID) public: enum { kTypeId = ID; }; bool isDerivedFrom(uint32_t nodeType) const { return nodeType == kTypeId ? true : BASE_TYPE :: isDerivedFrom(nodeType); }

class Base
{
public:

enum { kTypeId = 0; }

virtual bool isDerivedFrom(uint32_t nodeType) const { return nodeType == kTypeId; }

template<typename T>
T* asType()
{
return isDerivedFrom( T::kTypeId ) ? (T*)this: 0;
}
template<typename T>
const T* asType() const
{
return isDerivedFrom( T::kTypeId ) ? (const T*)this: 0;
}
};

class Foo : public Base
{
ADD_RTTI(Base, 1);
};

class Bar : public Foo
{
ADD_RTTI(Foo, 2);
};
void rttiTestBar(Base* obj)
{
Bar* bar = obj1->asType<Bar>();
if(bar )
{
std::cout << "obj is Bar\n";
}
else
{
std::cout << "obj is not Bar\n";
}
}
void rttiTestFoo(Base* obj)
{
Foo* foo = obj1->asType<Foo>();
if( foo )
{
std::cout << "obj is Foo\n";
}
else
{
std::cout << "obj is not Foo\n";
}
}
int main()
{
Base* obj1 = new Foo();
Base* obj2 = new Bar();
rttiTestFoo(obj1);
rttiTestBar(obj1);
rttiTestFoo(obj2);
rttiTestBar(obj2);
delete obj1;
delete obj2;
return 0;
}
[/code]
0

Share this post


Link to post
Share on other sites
I use this solution:

[code]
inline unsigned int new_id()
{
static unsigned int previous_id = 0;

++previous_id;
return previous_id;
}

template< class Type >
class id_container
{
public:
const static unsigned int value;
};
template< class Type >
const unsigned int id_container< Type >::value = new_id();

template< class Type >
unsigned int type_id()
{
return id_container< Type >::value;
}

[/code]
Keep in mind though that this won't work across dll boundaries, and you should make the new_id() function thread safe if you want to use type_id in mutliple threads.
0

Share this post


Link to post
Share on other sites
Simliar to GorbGorb's solution:

Code:
[code]
template < typename T >
inline unsigned int GetRTTI()
{
static char s_rtti;
return &s_rtti;
}
[/code]

[b]Pro:[/b]
One of the quickest implementations ever. Don't have to write much at all.
Fast comparisons.
Low memory overhead

[b]Con:[/b]
RTTI values are not absolute and will vary with memory layout. Tracking bugs between different code executions may be difficult.
May want more info other than a memaddress.
0

Share this post


Link to post
Share on other sites
[code]
class TypeId {
public:
virtual unsigned getTypeId() const = 0;

template<class Type>
bool isInstanceOf() const {
return getTypeId() == Type::getClassTypeId();
}
};

template<class Type, class GUID>
class AcquireTypeId : public virtual TypeId {
public:
unsigned getTypeId() const {
return GUID;
}

static unsigned getClassTypeId() {
return GUID;
}
};

//
// Elsewhere!
//

class Component : public virtual TypeId {
/* Stuff */
};

class SpecificComponent
: public Component
, public AcquireTypeId<SpecificComponent, 0xF5B30CDF> {
};
[/code]

Advantages:
+ Identifiers are static
+ No macros
+ Virtual inheritance allows for components to be written in script

Disadvantages:
- Unable to determine parent-child relationships
- Virtual inheritance
- No macros and no names; just a bunch of numbers
o V-table lookup required

Though my design can be improved by embedding the type-info with the object; thus avoiding the virtual inheritance and v-table lookup...
0

Share this post


Link to post
Share on other sites
This is my implementation of your entity class:

[code]
template< class Type >
void destruct_function( void *obj_mem )
{
static_cast< Type* >( obj_mem )->~Type();
}

class entity
{
public:
~entity()
{
for( auto it = components.begin() ; it != components.end() ; ++it )
( *it->first )( it->second );
}
template< class Type >
Type *query()
{
auto it = components.find( &destruct_function< Type > );
if( it != components.end() )
return static_cast< Type* >( it->second );
else
return 0;
}
private:
std::map< void (*)( void * ) , void * > components;
};
[/code]
0

Share this post


Link to post
Share on other sites
Just for some food for thought: it's entirely possible to implement a component/entity system without even providing a "[i]get child component by type[/i]" function whatsoever [img]http://public.gamedev.net/public/style_emoticons/default/wink.gif[/img] -- getting a component by type is just one way that you can choose use a component/entity system, with it's own robustness/predictability/maintenance pros/cons.
1

Share this post


Link to post
Share on other sites
[quote name='Hodgman' timestamp='1324860026' post='4897366']
Just for some food for thought: it's entirely possible to implement a component/entity system without even providing a "[i]get child component by type[/i]" function whatsoever [img]http://public.gamedev.net/public/style_emoticons/default/wink.gif[/img] -- getting a component by type is just one way that you can choose use a component/entity system, with it's own robustness/predictability/maintenance pros/cons.
[/quote]
Would you mind clarifying on that point? Would you instead get a component by instance id? Is what you're suggesting use tables in someway?
0

Share this post


Link to post
Share on other sites
[quote name='l0k0' timestamp='1326152893' post='4901125']
Would you mind clarifying on that point? Would you instead get a component by instance id? Is what you're suggesting use tables in someway?
[/quote]

You could have lists that consist of all the components of a particular type for all the entities that have that component. Then you would ask that list "Give me the component for entity id=1234".

So with that way, the entities don't actually store the components - instead all the components of one type are stored together. I think this is what the Artemis framework does.

Since most logic would generally iterate over all components of one type, rather than all components of one entity, that kind of memory layout is more favorable for reducing cache misses.
1

Share this post


Link to post
Share on other sites
[quote name='l0k0' timestamp='1326152893' post='4901125'][quote name='Hodgman' timestamp='1324860026' post='4897366']Just for some food for thought: it's entirely possible to implement a component/entity system without even providing a "[i]get child component by type[/i]" function whatsoever [img]http://public.gamedev.net/public/style_emoticons/default/wink.gif[/img] -- getting a component by type is just one way that you can choose use a component/entity system, with it's own robustness/predictability/maintenance pros/cons.
[/quote]Would you mind clarifying on that point? Would you instead get a component by instance id? Is what you're suggesting use tables in someway?[/quote]It depends on what your use-cases are for the "[font=courier new,courier,monospace]GetComponent<T>()[/font]" function, but I'll use an example to illustrate what I assume to be some common use cases:
* We're writing a "rocket launcher" component.
* When firing, it searches it calls [font=courier new,courier,monospace]parent->GetComponent<Transform>()[/font] in order to know where to spawn the rocket from.
* Rockets have a chance of mis-firing, which does damage to the holder - when this happens, it calls [font=courier new,courier,monospace]parent->GetComponent<Health>()[/font] to know where to apply the damage.

The user of the system is now happy that when they add a rocket launcher to an entity, it magically knows from where it should fire, and where it should apply "mis-fire" damage.

In my opinion, the above magic is exactly what makes this design a completely awful piece of architecture -- it makes the software engineering part of my brain feel dirty for hiding known dependencies away under an abstraction in order to achieve [u][i]spooky action at a distance[/i][/u], which is never a good thing when it comes to being able to reason about the state and interactions in your program.
It also has the problem of enforcing the [u][i]there can only be one[/i][/u] philosophy onto the user -- each entity can only have one transform and one health component -- which may seem like a trivial burden at the time of writing, but at some point your users will find a reason for there to be two of something, and will be forced to construct ungracious work-arounds involving several entities cooperating to function as one "entity".

All of these engineering taboos can be easily avoided if the rocket launcher is simply told in advance which health/transform components it is going to be interacting with, instead of acquiring them by magic (type). This could simply be done by giving the rocket launcher component some properties that the user can set, which contain the names of the linked components.

Another example of how you can connect them is during construction, e.g. in the "[i]entity is a vector<component*>[/i]" abstraction, you could write something like this:
[code]Transform* transform = new Transform();
Health* health = new Health();
entity->Add( transform );
entity->Add( health );
entity->Add( new RocketLauncher(transform, health) );[/code]
N.B. these ideas also translate over to the "[i]entity is an int, and systems are a map<int,T>[/i]" abstraction.
3

Share this post


Link to post
Share on other sites
[quote name='Hodgman' timestamp='1326158891' post='4901151']
All of these engineering taboos can be easily avoided if the rocket launcher is simply told in advance which health/transform components it is going to be interacting with, instead of acquiring them by magic (type). This could simply be done by giving the rocket launcher component some properties that the user can set, which contain the names of the linked components.
[/quote]Seconded.
0

Share this post


Link to post
Share on other sites
Seems like the rocket launcher would best be modeled as its own entity in a child-parent relationship with the other - it seems odd to me to have a RocketLauncher component. That would like having a Sword component that you add to an NPC entity.

And I'm trying to think of a scenario where the "there can only be one" problem isn't better dealt with by having separate entities. An entity with two transforms doesn't really make sense. I don't have that much experience in this area, so perhaps I haven't thought it through enough?
0

Share this post


Link to post
Share on other sites
[quote name='phil_t' timestamp='1326185543' post='4901227']
Seems like the rocket launcher would best be modeled as its own entity in a child-parent relationship with the other - it seems odd to me to have a RocketLauncher component. That would like having a Sword component that you add to an NPC entity.

And I'm trying to think of a scenario where the "there can only be one" problem isn't better dealt with by having separate entities. An entity with two transforms doesn't really make sense. I don't have that much experience in this area, so perhaps I haven't thought it through enough?
[/quote]

That is how I have seen it often modelled in the past. Typically the rocket launcher entity contains a component called "EquippedBy" or "UsedBy" that holds a reference to the using entity when equipped. So when the rocket launcher's fire logic is invoked, if it misfires or properly fires, you know both the entity to apply the misfire damage to as well as the location of where the shot originates.

The benefit of it being treated as a separate entity is that if you ever wish to model this launcher in a preview frame or want to animate it being dropped in favor of another weapon, you can do so by simply dropping the equipped by component from the entity. The rocket continues to hold onto it's mesh and other components as a free standing entity in the game world. Additionally when you want to animate death sequences and animate the dropping of the gun when the player dies, you can easily do so by again removing a single component from the weapon entity.
0

Share this post


Link to post
Share on other sites
[quote name='phil_t' timestamp='1326185543' post='4901227']
Seems like the rocket launcher would best be modeled as its own entity in a child-parent relationship with the other - it seems odd to me to have a RocketLauncher component. That would like having a Sword component that you add to an NPC entity.[/quote]The underlying point about hidden dependencies being bad engineering practice remains, regardless of the actual example content...
Actually, you can even ignore the "[i]there can only be one[/i]" advice, and the point about dependencies still remains.
[quote]And I'm trying to think of a scenario where the "there can only be one" problem isn't better dealt with by having separate entities. An entity with two transforms doesn't really make sense.[/quote]It's the same as the Singleton pattern. At the time you assume that "there can only be one" isn't going to get in the way, even though there's actually no requirement for you to implement that constraint. Adding a constraint that isn't required isn't often a good idea - all it's going to do is box future work into a constrained framework for no reason, other than laziness in the present... but if you think using singletons is a good design... ;p ;)

As for multiple transforms - I'm working on a sports game at the moment where each player is made up of over 50 transforms. Different parts of the code need to connect to different ones - the "look at" component connects to the head, the "catch"/"ball" components want to connect to the hands, the AI wants to connect to the feet, player-interaction actions want to connect different parts of different players together...
You could alternatively implement this by having each player own a "root transform" ([i]which is a transform struct[/i]) and a "transform hierarchy" ([i]which is an array of transform structs[/i]), or by treating skeletons as a special case that shouldn't be handled the same as other transforms, but then I've got to implement several extra components (and a whole bunch of special case logic) instead of just using the existing, simple, system.

This all also depends on what an entity means to you. If an entity is a single "prop", that you can easily instantiate, then yeah anything you want to be able to spawn by itself in one go should be an entity.
But what about when I want to spawn a monster holding a rocket, or a car with 4 wheels? Suddenly I've got to create two or five entities in order to create my one logical "prop" --- so you work around this by adding another concept of "templates" or "pre-fabs", which are collections of entities that you can spawn together in one go. Ok, problem solved, no big deal, right?
However, you can also solve this with a smaller framework if you don't implement the "[i]there can only be one[/i]" constraint, and you also say that "[i]entity is a component[/i]". If you do this, then you've got all the same benefits you had before ([i]there's nothing you could've made before that you can't make now[/i]), you're violating less engineering principles, and you get your "pre-fab" system for free ([i]a designer can make a "rocket monster" entity, which is made up of a "monster" entity and a "rocket" entity, with their internal components pre-linked to each other - when the monster dies, you can keep the rocket entity around[/i]).
2

Share this post


Link to post
Share on other sites
[quote name='Hodgman' timestamp='1326239248' post='4901458']
As for multiple transforms - I'm working on a sports game at the moment where each player is made up of over 50 transforms. Different parts of the code need to connect to different ones - the "look at" component connects to the head, the "catch"/"ball" components want to connect to the hands, the AI wants to connect to the feet, player-interaction actions want to connect different parts of different players together...
You could alternatively implement this by having each player own a "root transform" ([i]which is a transform struct[/i]) and a "transform hierarchy" ([i]which is an array of transform structs[/i]), or by treating skeletons as a special case that shouldn't be handled the same as other transforms, but then I've got to implement several extra components (and a whole bunch of special case logic) instead of just using the existing, simple, system.
[/quote]

It sounds like you are using Components = data + logic, right? (As opposed to Component = data, and Systems = logic).

[quote name='Hodgman' timestamp='1326239248' post='4901458']
However, you can also solve this with a smaller framework if you don't implement the "[i]there can only be one[/i]" constraint, and you also say that "[i]entity is a component[/i]". If you do this, then you've got all the same benefits you had before ([i]there's nothing you could've made before that you can't make now[/i]), you're violating less engineering principles, and you get your "pre-fab" system for free ([i]a designer can make a "rocket monster" entity, which is made up of a "monster" entity and a "rocket" entity, with their internal components pre-linked to each other - when the monster dies, you can keep the rocket entity around[/i]).
[/quote]

How does the rocket component know the monster died and the links to its health/transform component are no longer valid? What code is responsible for possibly wiring up the rocket component to another entity? Won't that code need to somehow find specific Health and Transform components for that new entity? (In which case you have the same "hidden" dependencies as you would have if the rocket was a separate entity that had a changeable parent whose Health and Transforms properties it requested - only you had to write extra code).

I'm just not yet convinced this simplifies anything.
0

Share this post


Link to post
Share on other sites
[quote name='phil_t' timestamp='1326242167' post='4901468']It sounds like you are using Components = data + logic, right? (As opposed to Component = data, and Systems = logic).[/quote]Transforms and "look at's" are just data, and the "look at system" uses both those pools of data to modify some transforms.

[quote]How does the rocket component know the monster died and the links to its health/transform component are no longer valid?[/quote]The easiest is for the rocket's links to it's "holder"/"user" to be weak links ([i]in UML terms: an aggregation/uses link, not a composition/owns link[/i]) - when the monster is destroyed, the links are automatically broken / known to be invalid upon inspection. This is a common problem/solution in all entity systems, whether they're one-component-type-per-entity, other component-based, or even old-school-inheritance based...

You could have the rocket entity automatically transition into a 'dropped' state when it's owner link is broken, or alternatively, when creating the monster, you could manually connect it's OnDeath event source up to the rockets Drop event target. This manual connection would be made by the designer of the RocketMonster, at the same time as they were connecting the rocket's "owner" property to the monster.

[quote]What code is responsible for possibly wiring up the rocket component to another entity? Won't that code need to somehow find specific Health and Transform components for that new entity? (In which case you have the same "hidden" dependencies as you would have if the rocket was a separate entity that had a changeable parent whose Health and Transforms properties it requested - only you had to write extra code).[/quote]The point is that any links are [b]not coded[/b] and automatic; the designer who authors the rocket monster creates the connections [b]as data[/b].

e.g. a quick description of the RocketMonster in Lua could look like:[code]function CreateMonster(pools) return {
Transform = pools.transforms:Create(),
Model = pools.models:Create("monster.model"),
AI = pools.monsterAI:Create(),
onConstructed = function(e)
e.AI.location = e.Transform
e.Model.transform = e.Transform
end
} end

function CreateRocketMonster(pools) return {
Monster = CreateMonster(pools),
Rocket = CreateRocket(pools),
onConstructed = function(e)
e.Rocket.user = e.Monster
e.Monster.AI.OnDeath:Add( function(e) e.Rocket:drop() end )
end
} end[/code]Ideally, you wouldn't have your designers writing Lua data manually though, so imagine instead that this is the output of their entity designer GUI, after they've created a "monster" entity made up of a transform/model/ai component, with the AI location linked to the transform and the model having a default path, and after they've then created a "rocket monster" entity made up of a rocket and monster entity, and with the rocket's user linked to the monster and the monster's AI component's on-death even linked to the rocket's drop event.
3

Share this post


Link to post
Share on other sites
[quote]
However, you can also solve this with a smaller framework if you don't implement the "there can only be one" constraint, and you also say that "entity is a component". If you do this, then you've got all the same benefits you had before (there's nothing you could've made before that you can't make now), you're violating less engineering principles, and you get your "pre-fab" system for free (a designer can make a "rocket monster" entity, which is made up of a "monster" entity and a "rocket" entity, with their internal components pre-linked to each other - when the monster dies, you can keep the rocket entity around).
[/quote]

I understand this concept, but I'm struggling to understand how it translates into more complicated situations. Are the entities themselves independent, linked only by specific components? How would you go about creating an articulate physics model with this method? Say, a vehicle. Would each wheel of the vehicle be an entity with a physics component, connected to the base by an entity for the joint? Would the parent entity "own" the child entities or would they simply link the physics components together? It's cases like these that get me all confused.

Would you mind explaining how you would implement a more complicated example with say, a car or tank?
0

Share this post


Link to post
Share on other sites
I thought more about this, and here's how I understand it to work. Please comment/correct as you see fit:

[CODE]
class IComponent {
public:
// Not sure what to put in here. Maybe type information? I thought we were trying to get rid of that altogether though.
};
class Entity : public IComponent {
public:
AttachComponent( IComponent *comp );
DetachComponent( IComponent *comp );
};

class Transform : public IComponent {
...
};

class RigidBody : public IComponent {
...
};

class Joint : public IComponent {
...
};

// Create a car
class Car : public Entity {
public:
...
Create();
};

Car::Create(Vec3 pos)
{
// Create transform.
Transform *t = new Transform();
t->SetIdentity();
t->Translate( pos );
AttachComponent(t);

// Create car base
RigidBody *base = new RigidBody(t, ...);
AttachComponent(base);

// Create car wheels
RigidBody *wheels[4];
wheels[0] = new RigidBody(...);
wheels[1] = new RigidBody(...);
wheels[2] = new RigidBody(...);
wheels[3] = new RigidBody(...);
for( i=0; i<4; i++ )
AttachComponent(wheels[i]);

// Create joints connecting the wheels to the car
Joint *joints[4];
Joint[0] = new Joint(wheels[0], base, ...);
Joint[1] = new Joint(wheels[1], base, ...);
Joint[2] = new Joint(wheels[2], base, ...);
Joint[3] = new Joint(wheels[3], base, ...);
for( i=0; i<4; i++ )
AttachComponent(joint[i]);
}
[/CODE]

The joints could then be destroyed and the wheels removed from the car entity, and they would still be free to bounce around the world.
Is that close?
0

Share this post


Link to post
Share on other sites
[quote name='ZBethel' timestamp='1326318426' post='4901766']
Is that close?[/quote]
Getting closer, certainly...

I'd take to task your decision to have components attached to entities though. Just give each joint a reference to each transform it is connected to, and process them all as generic joints.
1

Share this post


Link to post
Share on other sites
Would each joint still be an entity though? I guess I see your point. There is no reason to attach components to each other if you don't have a reliable way to query for a specific type (or would want to). The car still needs to have some level of ownership of the joints though, otherwise they get created and then lost in the void. How would you destroy them later? Are you suggesting that the car entity just keep specific references to what it needs rather than use some generic attachment mechanism?
0

Share this post


Link to post
Share on other sites
Yes, pretty much.

When you create a joint you pass it the two transforms it requires. When you create the car, you would pass it a list of associated joints, because the car needs to keep track of joints, and destroy them when it too is destroyed (given that both the wheels and the chassis will likely survive the destruction of the car itself)
1

Share this post


Link to post
Share on other sites
Would recommend then the car itself not create the joints, but instead merely be assigned them by whatever function creates the car? It seems to me that the car should be responsible for creating the joints and maintaining them. Otherwise the system creating the car has to worry about internal details. Do you see a benefit to doing it the former way?
0

Share this post


Link to post
Share on other sites
it depends how much flexibility you are going for.

I would say that a car is any entity with 'Wheel's, a 'WheeledVehicle' behaviour, and a 'VehicleController' attached. What makes it specifically a 'Car', is that it is produced by a 'CarFactory' function, that incidentally sets up an 'OnDestruct' handler to destroy the joints.

(the joints have nothing to do with the Car-as-entity, they have to do with the Car-as-wheeled-vehicle, and as such, I don't see that the Car entity needs to know or care about them)
1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0

  • Similar Content

    • By Edoardo396
      Hi guys, I'm trying to make a crossword puzzle game for practice.
      Sorry but I've no idea on where to start.
      It should be basic game where the user must enter the word in the correct place and nothing else. (I am sure you know how to play crosswords!)
      I have to export it to Android and (if possible) to iOS.
       
      What engine would I want use?
      I thought to use Unity in order to develop it but I'm not very good with it (and, honestly, I don't like it that much)
      How is Unreal Engine 4 with Basic 2D Games like this one? If I could use UE4 it would be better because I know more C++ than C#. 
      I also thought about making this app with a "basic" IDE such as Android Studio (and) xCode but I would have to do the work twice and I want to avoid that if possible.
      Does anyone know if there is a library or something useful for making crossword games?
      Thank you very much for the answers and have a nice day!
      I apologize for the bad English but I'm not American/English.
      Edoardo
       
    • By kyuubi
      Hello everyone,
      We are looking for some talented artists to join our team in developing a new classic style adventure game.
      Open Positions
      Our team is currently looking for two artists, one 3D model artist and one 2D concept artist.
      2D Concept Artist
      Help us translate the concepts into visuals to improve our 3D model workflow
      3D Artist
      Help with creating 3D environments, buildings, props, dressing etc.
      3D Animator
      Someone that can bring our models to life and make them feel less static.
      What we are looking for
      We have a fun and talented team working on an ambitious project, but we need help in creating 3D assets. We need people with experience, comfortable with defining streamlined workflows and producing work in a quick pace.
      We also need someone to help bring our ideas to life in 2d concepts first to better improve our workflow in creating the 3D scenes.
      Although it is a hobbyist project, we take the project seriously and we are committed to finish the project, so we need people that can commit to the project with the goal to end it.
      The ideal candidate
      Is used to work for milestones and timelines Used to working in a collaborative approach within a team environment Has time available to be present on a regular basis, appear on slack and provide updates Can output work on a fast pace That understands what it means to work in a project The skills
      For 3D Modeler
      Skilled in creative 3D environments, including props and scene dressing Ideally that has worked with Unity before Bonus points if you have talent for character creation Bonus points if you have actually worked on a title until the end. Experience with Unity (double bonus) For 2D Concept Artist
      Experience with concept art Bonus point if you have created concepts for a game Bonus points if you have actually worked on a title until the end. Experience with Unity (double bonus) For 3D Animator
      Experience animating humanoids and animals Experience animating inanimate objects Experience animating environments (vegetation, ocean etc) Bonus point if you have created concepts for a game Bonus points if you have actually worked on a title until the end. Experience with Unity (double bonus) The Background
      The game takes place in a world almost submerged by water, where all the land that is left are small islands, where the remains of the human race try to survive after the cataclysm known as the Seven Tides.
      You play the story of Jon Riley, a young boy living in the Island of Chelonii, in the Eastern Kingdom of Khalandrie. After a visit from an old mysterious acquaintance, his grandfather, the only relative Jon has mysteriously disappears and Jon embarks on a quest to find what happened to him, while discovering the truth about himself, and the underlying mystery of the Island.
      For a full description of the game check out The Game page. (user: seventides pass: indie)
      The Mechanics
      The game will be mainly feed from the traditional mechanics of adventure games popular in the 90’s with games like The Broken Sword, Monkey Island, The Longest Journey, Full Throttle, The Dig etc.
      It also introduces some RPG elements that promote exploration in order to immerse the player deeper in the world. The main driver of the gameplay experience is going to be the story as it's traditional in this genre of games.
      The Art Style
      Currently the adopted art style is a flat shaded, low poly style. You can see some examples below and the full gallery here (user: seventides pass: indie). Please not all of the screens are work in progress as we are working in iterations to move faster.

      The Music
      We are lucky to have an amazing musician and talented producer in the team that is composing amazing musical scores for the game. If you want to hear some music samples get in touch!
      The Tools
      The game is being developed in Unity 5 in 3D low poly flat shade style. We are currently using the following main tools:
      Unity 5 - Game engine Dialog System - Dialog System for non linear interactive dialog databases Adventure Creator - State machine for the traditional adventure game workflows FMOD - Sound Engine Blender - 3D Modelling Sculptris - 3D Char sculpting Slack - Communication Trello - Task Management Our Trello Board!

      The Team
      We are a team mostly composed by professionals in our areas but new in applying our skills in game development.
      Game Designer/Project Lead - Background in Computer Science and working professionally as the technical director of a leading web development agency in Sydney. Duarte brings maturity in project management methodologies and technical leading. An obsessive adventure game player and very seasoned technologist, Duarte is the founder of the project. Lead Developer - A very experienced developer, Joao is the main man behind the implementation in the Unity engine. He will translate the specs and game design workflows into the engine. He is a professional web developer currently working in Vienna, Austria. Music Producer/Sound Design - A professional musician and music producer, Richard is a guru in enhancing the experience with sound and musical scores. He works professionally as a musician and music teacher and lives in London. 3D Artist/ Character Design - An aspiring musician and hobbyist game designer and 3D artist, Kevin is mainly responsible for character art. He currently lives in Puerto Rico. 3D Artist/ Environment Design - A hobbyist 3D artist, Joshua is mainly responsible for environment art, buildings, landscapes and props. He lives in London. If you are interested
      If you want to join the team, get in touch and I will supply the full game design document, our wiki containing character references, sound design cues etc and provide access to our Slack team chat.
      If you are interested contact me through private message.
      Looking forward to hear from you!
    • By INTwindwolf
      DESCRIPTION
      The team is in need of an assistant Art Team Director that will assist the Project Lead and Art Director in the development of the game. The position does require you to have knowledge of the Unity Game Engine, 3D asset creation software, and a desire for project management.
      The INT team is a large, international team, focused on the development of a core demo which will showcase RPG elements and core features for fundraising and investors. We are a friendly and passionate bunch and hope you will apply soon to be part of our team. Please review the job requirements and responsibilities below.

      Starboard Games LLC is looking for a highly professional, qualified, indie team developer to join our ambitious INT project.
       
      As the INT Assistant Art Team Director you will report directly to the Project Lead and Art Lead. In the occurrence of an emergency you would become the acting Art Lead. The position does require a knowledge of the Unity game engine. This is because we would like our Assistant Art Team Director to have a knowledge of the game engine, and the ability to create scenes to showcase assets.
      Furthermore, you would need to be able to create assets for the core demo in a 3D modeling suite. Many of our artists use blender, but if you have a commercial license for another program then that would be acceptable as well. You will also need to possess team management abilities. This means you will be reviewing 3D artist work, 3D artist samples and test submissions, 2D concepts, and possess an understanding of the ‘big picture’ for INT which will be shared with you by our store, lore, and Project Directors.
      Responsibilities:
      1. Report to Art and Project Lead.
      2. Act as Acting Art Lead in the event of an emergency.
      3. Ability to think creatively.
      4. Ability to communicate effectively and work with other team leads.
      5. Desire to see the project through to completion.
      REQUIREMENTS
      1. Knowledge of the Unity Game Engine.
      2. Experience using Unity.
      3. Experience using 3D asset creation suites.
      4. Experience managing a team or being part of a team environment.
      5. Must be able to take feedback constructively.
      6. Must be able to interpret and decipher maps and notes.
      7. Must be able to work from 2D art.
      8. Commitment to the Project and the ability to spend large chunks of time working towards the completion of the project.
      BENEFITS
      We offer revenue-sharing generated from crowd-funding to team members who maintain consistent communication on company projects and meet Starboard Games deadlines. Currently we are unable to offer wages or per-item payments. Your understanding is greatly appreciated.
      Thank you for your time! We look forward to hearing from you!
      TO APPLY
      Please send your CV/Resume, as well as (the link to) your portfolio to: JohnHR@int-game.net.
      Kindest regards,
      John Shen
      HR Lead
      Starboard Games LLC
    • By INTwindwolf
      DESCRIPTION

      Starboard Games LLC is looking for a highly professional, qualified, indie team developer to join our ambitious INT project.
      INT is an upcoming Science Fiction RPG that has been in continual development for several years. The team is in need of a Level Editor and Designer to join the team to work on the development of the game. This position does not require you to be a programmer or 3D artist.
      The INT team is a large, international team, focused on the development of a core demo which will showcase RPG elements and core features for fundraising and investors. We are a friendly and passionate bunch and hope you will apply soon to be part of our team. Please review the job requirements and responsibilities below.
      As the INT Level Editor and Designer you will be the individual on the team who received art assets and builds the level to Game Dev requirements. This position will require a knowledge of the Unity Game Engine, but not programming or art asset creation knowledge.
      Our levels have been mapped out and annotated with setup notes. While these setup notes and blueprints should be followed, as our Designer you can feel free to be creative in the setup process. When you place assets and design exterior and interior spaces you can be creative in how you build these spaces out.
      Responsibilities:
      1. Report to team Leads.
      2. Report to weekly Dev Meeting.
      3. Ability to think creatively and design portions of the level when required.
      REQUIREMENTS
      1. Knowledge of the Unity Game Engine
      2. Experience using Unity and importing/setting up levels in Unity 
      3. Experience optimizing levels in Unity 
      4. Ability to work under Team Leads
      5. Must be able to take feedback constructively 
      6. Must be able to interpret and decipher maps and notes to set up the level
      BENEFITS
      We offer revenue-sharing generated from crowd-funding to team members who maintain consistent communication on company projects and meet Starboard Games deadlines. Currently we are unable to offer wages or per-item payments. Your understanding is greatly appreciated.
      Thank you for your time! We look forward to hearing from you!
      TO APPLY
      Please send your CV/Resume, as well as (the link to) your portfolio to: JohnHR@int-game.net.
      Kindest regards,
      John Shen
      HR Lead
      Starboard Games LLC
    • By xenohexx
      Hi, I'm an Unity programmer and I'm looking for an artist/group to make something togheter (2D), I was thinking of a Point and Click Adventure, a FMV game, an Adventure/RPG in a streaming 2D world or a Myst Like (panorama) game but I'm may be open to other suggestions although arcade/plataform games are not my thing, in general I love games in which the story plays an important part
      You can see some things I've done here:
      http://zenger.co.nf
      If you are interested please send me a mail (the mail is at the webpage)
      Thank you very much