Sign in to follow this  
Followers 0
l0k0

Unity
Component Entity Model Without RTTI

67 posts in this topic

[quote name='Net Gnome' timestamp='1326584461' post='4902799']
I'm just curious as to why one would purposefully handicap themselves[/quote]

Handicap? I call it advantage.
One reason is simplicity. You have what you see. Not an unknown quantity which may be anything. It reduces the code size several fold. Also consider that C has no RTTI. On another end of scale is IoC and DI, both proven to scale to arbitrarily large projects by eschewing traditional typing.

[quote]by not taking advantage of even the most basic of OO techniques[/quote]
It's not necessary to abandon any OO techniques, it's about design. All of the above can be identically applied in any language.

Other reason is performance. You mentioned "1/1000th of a millisecond". That would be 1 microsecond, or on the order of several thousand CPU cycles. In that time, one can transform several thousand vertices or one model. In reality, the dynamic dispatch is considerably less (either no penalty due to branch prediction or only several cycles), but it adds up. Hence it's completely missing in GPU programming, where completely other techniques are used.

[quote]but its almost impossible to avoid OO in c# and therefore avoid RTTI.[/quote]
LINQ. Entity Framework. OO has been abandoned in .Net and just about any other framework. It simply doesn't scale management-wise.

Obivously, C# being designed on top of object-based VM means that syntax still uses Java-like constructs, but application design has moved completely away from OO. It's similar to how SOLID principles are commonly used in C applications despite language not supporting OO at all.


Performance plays a role here again, but in a different way. With emphasis being on web development, the latency of receiving data is simply too high. If dynamic dispatch costs only a cycle or two on CPU, equivalent design requires up to several seconds over internet. Hence the introduction of SPDY, the studies into async loading of assets in browsers, the preference of JSON vs. XML, the designs of web APIs. OO simply doesn't work over internet as Sun's falacies teach. One of biggest examples of such failures is CORBA.
0

Share this post


Link to post
Share on other sites
Oh, i completely agree with you on what you've said. I guess its just a difference in personal philosophy. I tend to favor flexibility over performance and it seems you're vice-versa. Don't take that to mean I'm against writing for performance, i just tend to go towards building a flexible framework first, then speed it up as needed.
0

Share this post


Link to post
Share on other sites
[quote name='Net Gnome' timestamp='1326634233' post='4902945']
I tend to favor flexibility over performance and it seems you're vice-versa.[/quote]

Not really. I find that I get considerably more flexibility and simplicity. Performance is not the crucial factor, but alternate designs are good fit for hardware realities.
0

Share this post


Link to post
Share on other sites
[quote name='l0k0' timestamp='1324411691' post='4895843']
However, RTTI (along with exceptions) is typically best left disabled in frameworks and engines if possible.
[/quote]

Sorry, I'm late to the discussion and the answer to my question may have already been provided. I'm also developing my own component entity system for my C++ Engine and I'm really curious as to where the above statement comes from. I use RTTI in my current system with essentially a base `Component` class and a one level of inheritance to derive Subsystem Components classes. I'm not using templates. Whats wrong with using RTTI?
0

Share this post


Link to post
Share on other sites
[quote name='T e c h l o r d' timestamp='1326690288' post='4903126']
Whats wrong with using RTTI?
[/quote]

The topic of the thread is
[b] Component Entity Model Without RTTI[/b]


I think thats all thats wrong with it.
0

Share this post


Link to post
Share on other sites
[quote name='T e c h l o r d' timestamp='1326690288' post='4903126']Whats wrong with using RTTI?[/quote]You can do better.

If you were to implement it yourself, would you do it like this?[code]struct TypeItem
{
const char* name;
TypeItem* parents;
TypeItem* next;
};
std::map<void*, TypeItem> g_types;

bool Match( TypeItem a, TypeItem b )
{
if( strcmp(a.name, b.name)==0 )//cache miss
return true;
else if( b.next && Match(a, *b.next) )//cache miss, recursive
return true;
else if( b.parents && Match(a, *b.parents) )//cache miss, recursive
return true;
else
return false;
}

bool Match( void* objectA, void* objectB )
{
void* vtableA = *(void**)objectA;
void* vtableB = *(void**)objectB;
return Match( g_types[vtableA], g_types[vtableB] );
}[/code]...because you shouldn't be surprised if your compiler implements RTTI in such a horribly-performant manner.

And if you knew that type-comparisons involved calling a function this ugly, would you think twice about calling this type-comparison function?


Also, as discussed earlier, there's no [i]need[/i] to have a [font=courier new,courier,monospace]entity->GetComponent<T>()[/font] function in the first place...
1

Share this post


Link to post
Share on other sites
[quote name='Hodgman' timestamp='1326691929' post='4903133']
[quote name='T e c h l o r d' timestamp='1326690288' post='4903126']Whats wrong with using RTTI?[/quote]You can do better.

If you were to implement it yourself, would you do it like this?[code]struct TypeItem
{
const char* name;
TypeItem* parents;
TypeItem* next;
};
std::map<void*, TypeItem> g_types;

bool Match( TypeItem a, TypeItem b )
{
if( strcmp(a.name, b.name)==0 )//cache miss
return true;
else if( b.next && Match(a, *b.next) )//cache miss, recursive
return true;
else if( b.parents && Match(a, *b.parents) )//cache miss, recursive
return true;
else
return false;
}

bool Match( void* objectA, void* objectB )
{
void* vtableA = *(void**)objectA;
void* vtableB = *(void**)objectB;
return Match( g_types[vtableA], g_types[vtableB] );
}[/code]...because you shouldn't be surprised if your compiler implements RTTI in such a horribly-performant manner.

And if you knew that type-comparisons involved calling a function this ugly, would you think twice about calling this type-comparison function?


Also, as discussed earlier, there's no [i]need[/i] to have a [font=courier new,courier,monospace]entity->GetComponent<T>()[/font] function in the first place...
[/quote]
I don't know how the compiler implements RTTI and I honestly don't think my implementation would out perform it. I would like to believe that the compiler scientists identified weak RTTI performance and implemented an optimization, after all one would have to go thru the compiler to compile a home grown implementation. I also don't use templates but, I can rationalize why there's no [i]need[/i] to have a [font=courier new,courier,monospace]entity->GetComponent<T>()[/font]. I'm still in the process of refactoring and haven't fully worked out how the communication between components.

I use RTTI in my current system with a base `Component` class and a one level of inheritance to derive Subsystem Components classes. I'm personally not a big fan of the extra typing involved with using [i]static_cast<derived*>(base[/i][i]) [/i]and [i]dynamic_cast<derived*>(base) [/i]keywords. Which is my only grief. Other than that I still have seen any data validating the claim RTTI is `bad` for performance. Can someone please point me to some documentation that supports this claim? If necessary, I rather change the implementation now than later. Thanks in advance.
0

Share this post


Link to post
Share on other sites
[quote name='T e c h l o r d' timestamp='1326697224' post='4903153']I don't know how the compiler implements RTTI and I honestly don't think my implementation would out perform it. I would like to believe that the compiler scientists identified weak RTTI performance and implemented an optimization, after all one would have to go thru the compiler to compile a home grown implementation.[/quote]Just think about the feature that it's implementing -- it's mighty complex.
Try and think about how you might implement such a general system so that this kind of magic is possible:[code]struct A {};
struct B {};
struct C : public A, public B {};
struct D : public C {};

D data;
B* ptrBase = &data;
D* ptrDerived = dynamic_cast<D*>( ptr );[/code]No matter how much you optimise it, it's still going to be mighty complicated. You can't optimise out that complexity, because the complexity of working in every inheritance hierarchy is the core feature that it provides. Also, yes, it is often implemented using string-comparisons and linked-lists, because the compiler authors know that no-one who cares about performance is going to use [font=courier new,courier,monospace]dynamic_cast[/font] and then complain when it's slow...

The reason that you can easily beat this, is because you don't need that much complexity! If you only need to be able to perform exact type comparisons (no hierarchy testing) on a specific, small set of types, then you can roll an ID system in two lines:[code]struct TypeIdBase { protected: static int NextId() { static int i = 0; return i++; } };
template<class T> struct Type : TypeIdBase { public: static int Id() { static int id = NextId(); return id; } };[/code]and implement type-comparisons in one line, with the ability to store type-id's in [font=courier new,courier,monospace]int[/font] members if needs be:[code]if( Type<int>::Id() == Type<float>::Id() )
printf("what?");[/code]
However, it's extremely rare to find a use for [font=courier new,courier,monospace]dynamic_cast[/font]ing that's justifiable in the first place. There's usually a simpler, cleaner, more maintainable way of doing things.
In what situations do you use [font=courier new,courier,monospace]dynamic_cast[/font]?
0

Share this post


Link to post
Share on other sites
I use pointers to the base component class to work with derived component classes. I only use [i]RTTI casting [/i]when a base class pointer needs to access a member of the derived class. My initial reason for this approach was make my life easier wrapping objects from 3rd Party libraries like Ogre::Mesh into a Component. A Derived Component inherits from both the Base Component and Ogre::Mesh Classes or contains members to work Ogre::Meshes directly. I'm relatively new to C++ and still trying to wrap my head around a components implementation.
0

Share this post


Link to post
Share on other sites
For my assignment of entities to components i use an array of arrays to contain components by type. When a component is added to the framework, a type Id is established. This is nothing more than assigning an incrementing integer to a static int in the component. Since its static, each and every component of that type will report the same exact type Id (i also perform an early registry when a system is established to ensure a type id is created as well). so when i need to retrieve component x from entity y i use x.id to index into the array of arrays to pull out the applicable component array, then use the y.id (entity) to retrieve the relevant component. (i.e., no type comparisons are ever required other than checking for index safety).

now of course this also adds some memory overhead, but the trade-off is access performance. of course my implementation uses RTTI to access the type id, as its generally accessed through an interface. Now if i could get a way to do that without having to go through an interface but still remain agnostic in implementation thats faster than an assembly table lookup (from my digging around, that is approximately how interfaces are implemented by the compiler), i'm all ears [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img] Or will i need to loose the agnostic approach?
0

Share this post


Link to post
Share on other sites
Well, hrm... now that i think of it, i could make the component be a mapping container, where it holds a type id and then another mapping id which would say which index I would want in a dedicated array for that data type. The component manager and mapper would just use another layer of lookup to get/set the data needed. I would need to use something like a switch to direct it to the correct retrieval mechanisms, but would this be faster than an interface?

The component would be something like this:

[CODE]
class Component
{
int entityId;
int componentType;
int componentId;
}
[/CODE]

though, the componentId and entityId could be merged to do the indexing if you dont mind an entity only able to own one component of any type. If you did that, you could remove the need for a class entirely as long as you knew the entity id and component type desired.

But with that approach, you would need a unique retrieval mechanisms for each and every component type to be defined in a component manager/mapper, even if you reduced that class down to a global constant...

At that point you no longer have an agnostic framework though =/
0

Share this post


Link to post
Share on other sites
[quote name='Net Gnome' timestamp='1326719422' post='4903215']
Well, hrm... now that i think of it, i could make the component be a mapping container, where it holds a type id and then another mapping id which would say which index I would want in a dedicated array for that data type. The component manager and mapper would just use another layer of lookup to get/set the data needed. I would need to use something like a switch to direct it to the correct retrieval mechanisms, but would this be faster than an interface?[/quote]

Speed is not primary concern, at least not when it comes to design.

You talked about SQL-like mapping. Apply the same principle here. Take two systems, perhaps a physics one and perhaps a pickup trigger. We have this data:[code]Vector3 position[];
Vector3 orientation[];
Vector3 velocities[];
TriggerRadius triggers[];
ItemTemplate templates[];[/code]Physics requires position, orientation and velocities. Quest trigger requires position triggers and templates.

The logic that manipulates these would be akin to select statement (SELECT position, orientation, velocities ... and SELECT position, triggers, templates ...).

There is no presecribed way to express such relation or how items are connected. At most basic level, you could indeed to this:[code]class RigidBody {
Vector3 position, orientation, velocities;
};[/code]Then design listeners and whatnot to update these instances as they change. Then propagate them to pickup system, for example.

Alternatively, you can express all of these as pure code.[code]void stepPhysics() {
// do stuff with velocities, orientation, position
}

void checkForPickups() {
for every item that has a trigger
check for trigger radius
if in_range of trigger
use item based on template
}[/code]


How to map these things? Whatever is most convenient. One might use 1:1 indices. So that position[i], orientation[i] and velocity[i] belong to same entity. For triggers, there might be a a separate map that contains indices mapping between needed values.


Such approach lends itself well to cases where there is many things and there is expected to be many things. It's not worth complicating for one-off objects.

For UI, we know we'll have many buttons and frames. We also know that each button has associated action. So perhaps something like this:[code]Rect uiElements[];
delegate void UIAction(...); // note the abstract handler
UIAction actions[];

void onClick(int x, int y) {
find which element was clicked in uiElements, located at index i
invoke corresponding handler[i]
}[/code]

At each level, there's absolute minimum amount of data stored. An UI element doesn't need to know its type at first pass, it's just a rectangle that can be matched to a click. Later, we can differentiate between buttons, listboxes, .... Also notice the use of "complex" delegate. On each click, we'll invoke one element (or perhaps a few on multitouch).


Now consider that we end up with many UI elements and clicking is slow. No problem, all we have is a bunch of rectangles. Maybe build a quad tree over them and use that to query. Also, for simplicity, examples use arrays. These can be any container, List<>, Map<> whatever is most suitable. For performance sensitive work, they'd be either aligned arrays or in C# arrays/lists of structs.
1

Share this post


Link to post
Share on other sites
Figure i would write a minor test case, just to see how much performance i am loosing using the most basic of interface usage. i wrote this to test:


[CODE]
namespace InterfaceTest
{
class Program
{
static void Main(string[] args)
{
Test test = new Test();
test.runTest();
}
}

class Test
{
private IInterface interfaceClass = new ExtendedClass();
private NormalClass normalClass = new NormalClass();
private ExtendedClass extendedClass = new ExtendedClass();
private int test;
private long interfaceStart, interfaceFinish, normalStart, normalFinish, extendedStart, extendedFinish;

public void runTest()
{
interfaceStart = DateTime.Now.Ticks;
for (int i = 0; i < 100000000; i++)
{
test = interfaceClass.getInt();
}
interfaceFinish = DateTime.Now.Ticks;
normalStart = DateTime.Now.Ticks;
for (int i = 0; i < 100000000; i++)
{
test = normalClass.getInt();
}
normalFinish = DateTime.Now.Ticks;
extendedStart = DateTime.Now.Ticks;
for (int i = 0; i < 100000000; i++)
{
test = extendedClass.getInt();
}
extendedFinish = DateTime.Now.Ticks;
Console.WriteLine("interface duration: " + (interfaceFinish - interfaceStart));
Console.WriteLine("normal duration: " + (normalFinish - normalStart));
Console.WriteLine("extended duration: " + (extendedFinish - extendedStart));
Console.Read();
}
}
}
[/CODE]

inteface:


[CODE]
namespace InterfaceTest
{
interface IInterface
{
int getInt();
}
}
[/CODE]

extended:


[CODE]
namespace InterfaceTest
{
class ExtendedClass : IInterface
{
int i;
public int getInt()
{
return i;
}
}
}
[/CODE]

and normal

[CODE]
namespace InterfaceTest
{
public class NormalClass
{
int i;

public int getInt()
{
return i;
}
}
}
[/CODE]

interface: 2964005
normal: 312000
extended: 312001

so, its roughly 9.5 times slower than a direct call. interesting.

edit: realized i had a type conversion from int to long in there, its fixed now.
0

Share this post


Link to post
Share on other sites
interestingly enough, using an abstract class vs an interface results in a about 1716003 ticks, or ~5.5x as long as a direct class call and an internal call costs the same as a direct class call. So when in doubt, go abstract over interface... Interesting things to ponder...
0

Share this post


Link to post
Share on other sites
[quote name='Net Gnome' timestamp='1326739063' post='4903311']
interestingly enough, using an abstract class vs an interface results in a about 1716003 ticks, or ~5.5x as long as a direct class call and an internal call costs the same as a direct class call. So when in doubt, go abstract over interface... Interesting things to ponder...
[/quote]

I don't really want this to be about synthetic microbenchmarking, it's more about showing what happens if you turn your world completely upside down and throw away all existing notions of how a solution should be structured.

There's also another test that is missing above:[code]
public class NormalClass
{
int i;

public void testInt(int n)
{
for (int i = 0; i < n; i++)
{
test = i;
}
}
}
[/code]
It's considerably more representative of real world difference. Original test is a NOP, so it's measuring the overhead of pointless assignment. The changed example moves the separation line from outside of interface into implementation itself.

Ironically, this version is better OO than other tests. Getters break encapsulation.
0

Share this post


Link to post
Share on other sites
[quote name='T e c h l o r d' timestamp='1326704427' post='4903169']
I use pointers to the base component class to work with derived component classes. I only use [i]RTTI casting [/i]when a base class pointer needs to access a member of the derived class. My initial reason for this approach was make my life easier wrapping objects from 3rd Party libraries like Ogre::Mesh into a Component. A Derived Component inherits from both the Base Component and Ogre::Mesh Classes or contains members to work Ogre::Meshes directly. I'm relatively new to C++ and still trying to wrap my head around a components implementation.
[/quote]

A cleaner solution would be to treat the ogre mesh as a property of your derived component and through an interface, keeps the Ogre API out of the ECS framework.

[CODE]
/* Base mesh object */
class IMeshObject {
};
/* Ogre mesh object */
class OgreMeshObject : public IMeshObject {
};
/* CryEngine mesh object */
class CryMeshObject : public IMeshObject {
};
/* Base component */
class IComponent {
};
/* Renderable Component */
class IRenderComponent : public IComponent {
};
/* Mesh component */
class MeshComponent : public IRenderComponent {
public:
void setMeshObject(IMeshObject* meshObject);
IMeshObject* getMeshObject();
};
[/CODE]

If you wanted to keep it simple and refactor later, you could avoid wrapping the ogre API if you wanted and simply use get/set methods for the Ogre::MeshPtr object; however, I certainly would not inherit from any render API classes when creating my ECS components.
1

Share this post


Link to post
Share on other sites
[quote name='Hodgman' timestamp='1326158891' post='4901151']
It also has the problem of enforcing the there can only be one 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".
[/quote]

My current system uses said system without that restriction like so:

[CODE]
template<class T> void getComponents(T *components[], int32 &n) const {
n = 0;
uint32 i;
for (i = 0; i < componentList.size(); ++i) {
if (componentList[i]->asType<T>()) {
components[n++] = static_cast<T *>(componentList[i]);
}
}
}
[/CODE]

I think you make a great point about the hidden dependencies though. Accessing the pointers directly is also faster than a linear search/hash table look up when it matters too.
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 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 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 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