Unity Is The "entity" Of Ecs Really Necessary?

This topic is 481 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

I am putting the finishing touches on my engine and I have a question about whether or not is is useful (to the general gamedev population) to have the "entity" abstraction as part of the entity component system.

In the current version of my system, the entity is just an ID, components are stored in packed arrays, and components can be a member of more than one entity. The "engine" is just a collection of arrays for the different component types. All logic is implemented in systems that can each modify the contents of the engine in their update() method. I have a prefab system similar to Unity that allows instancing of premade collections of resources. Each prefab instance gets associated with an entity ID in the engine when it is created.

I am thinking about removing the entity concept because it would greatly simplify the bookkeeping and make the overall architecture much simpler. In that case, there wouldn't be any explicit mechanism for grouping components together - the engine would just be a big unordered collection of resources that are part of the current simulation. This seems like it would work for my use cases but maybe I am not foreseeing all common needs (since I'm mostly a low level tech developer). I can envision a scenario where a user script might need to access sibling components of the same prefab instance, is this a common need? Or should I just require the user to explicitly link components via resource references so that the script could later access them?

Share on other sites

Binding different components together using an entity is almost the entire point of the system. It's about having different data and functionalities, and bundling that together in a way with minimal memory, runtime and abstraction overhead (the opposite of which would be huge inheritance trees).

In practical terms it's because too much code will need it. Have an animation system and a combat system? Well, if my character is hit (which inevitably ends up modifying that combat component somehow, which probably contains all the stats like HP, armor, damage, etc.) I'd like to use the animation system to set up a response for that particular character, which will in the end modify that particular animation component. Get the combat component and animation component using the entity... ez pz. Stuff like that.

If you're viewing this from a low-level perspective, it's easy to get the impression that you're mostly dealing with independent systems. A physics engine, that takes care of all its own stuff, a renderer that doesn't care about what happens on the outside, why would an audio system require outside components ever?? etc...

But that's not what ECS is really for (big IMO). It's about that part of the code above that which uses all these systems and bundles them together to make a game with it.

edit: Remember that a big part of the complexity of ECS is also requirements like being able to attach and detach components at runtime, being able to do data-driven stuff, etc... So in the end those users of your component system will just end up with similarly complex abstraction layers which tie this stuff together at runtime.

Edited by agleed

Share on other sites
It's entirely up to you. I personally don't like the "entities as an ID" approach because I think that de-emphasises the composition aspect. You ask whether accessing sibling components is a common need and in my games that use components this is absolutely essential. But other people engineer around that in other ways that suit them.

One reason why you might not want to force components to only communicate via explicit connections is that it makes hot-swapping of components a lot harder. Going via the entity allows that extra level of indirection.

(I also wouldn't have a component as part of multiple entities. Again, that seems to break the composition aspect. Something shared between entities is more of a 'service' to me.) Edited by Kylotan

Share on other sites

In the current version of my system, the entity is just an ID, components are stored in packed arrays, and components can be a member of more than one entity.

What's the purpose of sharing components among entities? How do you track lifetime of the component?

I can envision a scenario where a user script might need to access sibling components of the same prefab instance, is this a common need?

This makes me think you've designed your architecture before having a problem (game) to solve with it :P

As others have mentioned, it's fairly common to have code (a system) that requires multiple components from an entity. Although you might be writing something more like "for this entity, give me the A and D and J components", rather than "for this A component, give me the D and J components on the same entity".

Share on other sites
If the compnents arent associated in some way, how would you know which transform component to get the position from when rendering the mesh component (or render component or whatever it may be called)

Either you would need to combine EVERYTHING needed to perform some action within a system in the component that system operates on, or store a list of components within the component to see which ones are associated, or use a common id between related components (and so the entity id is born)

For example - many systems will probably need the position information for things in the game in order to do anything useful - would you store a copy of this in each component? If so, then why have "components" at all?

Share on other sites

Thanks for all of the input. It's clear that I still need some way to group related components, and that hierarchies of entities should be allowed. I think I will use Hodgman's idea of treating entities as just another component type. This allows me to get rid of the cumbersome entity-as-an-ID approach, and also allows multiple entity types and hierarchies of entities to exist. It also fits well into my existing prefab system.

Then the systems that operate on entities can go engine.getComponents<MyEntityType>() to access the current entities of a given type in the engine, the same as any other component type. The entity is just a list of pointers to components in this case, so it is easy to access child components with a certain type or name.

Edited by Aressera

Share on other sites

If the compnents arent associated in some way, how would you know which transform component to get the position from when rendering the mesh component (or render component or whatever it may be called)

For example - many systems will probably need the position information for things in the game in order to do anything useful - would you store a copy of this in each component? If so, then why have "components" at all?

For this particular case, I do indeed store the transforms separately for graphics/physics/sound objects. Communication between the components is implemented using a data flow graph that is processed by the engine before and after each system update. Data flow connections can have various types (trajectories (transform+derivative), tensors (scalar/vector/matrix values), sound, image, etc.), and can be updated at a user-defined rate (e.g. 60Hz, 1Hz, or only at build time). For example, to control a graphics object using the transform from a physics object, the "transform" output of the physics object is connected to the "transform" input of the graphics object. After the physics simulation update, the physics object writes to the connection's local transform storage, then before graphics rendering the graphics object reads the transform.

Share on other sites

What's the purpose of sharing components among entities? How do you track lifetime of the component?

I don't have a good answer for the first question. I guess I don't want to place unnecessary restrictions on how the components can be used.

Components are stored in an object called a ResourceSet that is a container of arbitrary resource/component types and is also the in-memory representation of my engine's file format. Components are loaded from disk into a ResourceSet, and can then be instantiated within an engine simulation context. The engine holds raw pointers to the components and doesn't care about the object lifetimes, components can be added directly to the engine, or a copy can be created (stored in another ResourceSet that contains only runtime instantiated data). If a component is shared among multiple entities, its reference count within the engine tracks the number of entities using the component. When the reference count goes to zero, the component is removed from the engine (but not deallocated). The object instancing system is higher-level and built on top of the engine and manages the lifetime of the ResourceSet(s).

Edited by Aressera

Share on other sites

If the compnents arent associated in some way, how would you know which transform component to get the position from when rendering the mesh component (or render component or whatever it may be called)

The ECS pattern is about having implicit (magic) connections between components. A mesh component can fetch data from a transform component without explicitly being told to, via something like: this->parent->child(typeof(Transform)) / this->sibling(typeof(Transform)).
The alternative to this is having explicit connections between components. When initializing/creating the parent entity, it explicitly plugs child components into each other, via something like: this->mesh->transform = this->transform.

If I had a data format for defining entity types, the only difference between these two systems would be:
Implicit linking: myEntity = { Transform(0,0,0), Mesh('foo.model') }
Explicit linking: myEntity = { transform = Transform(0,0,0), mesh = Mesh('foo.model', transform) }

IMHO, implicit coupling is evil, which is why ECS comes off as an anti-pattern to me, sitting alongside the singleton  :wink:

It's about having different data and functionalities, and bundling that together in a way with minimal memory, runtime and abstraction overhead (the opposite of which would be huge inheritance trees).

Comparing ECS and deep-inheritance is kind of a straw-man argument, because deep-inheritance goes against the rules of OOP as well. Jumping from "deep-inheritance based OOP" to "ECS based composition" is just swapping one extreme for another. IMHO anyone making this leap should stop and actually learn OOP first before throwing the baby out with the bathwater.

Share on other sites
A lot of the "ECS vs inheritance" argument comes from a very specific series of blog posts which basically proposes ECS as the solution to all the evils of OOP. For some reason the opinions within seem to have taken off in the community without much questioning.

I'm on the fence with it - I reject the strong assertions of the "entity is an ID, everything comes from a database, no OOP whatsoever" crowd. But I do like components, when they're flexible enough and not too far from how I'm used to working.

The explicit vs. implicit coupling issue is interesting. For me, it's like Python's dynamic types vs C++'s static types - you gain some speed and flexibility and lose some safety, and the route that gives you most benefit at the start of the project may not be the same route that benefits you most at the end. Personally I'd find explicit component connection really awkward, but maybe there's a way to make it effective and drag-and-drop compatible (like in Unity), rather than without feeling like I'm wrestling with an Inversion of Control container. Edited by Kylotan

Share on other sites

Well, ECS is just an extended form of composition with data oriented and data driven design measures added in. They just counter the typical problems you get from deep inheritance trees, so I think it's natural to assume that stance of discussion and those comparisons are entirely fair. Of course, ECS is just one possible solution to the problem, which you probably don't need if you don't have all of those particular problems, but everyone should already be aware of that and we're just discussing specifics of ECS.

Regarding explicit vs implicit: The problem with explicit is that it's not data-driven at all. You can't treat different component combinations in a polymorphic manner when needed. If you have an entity 1 with components A,B,C and entity 2 with components B,C and a system that operatoes on components B and C together, you can't have a system that iterates through all entities just like that because they're different types, instead you would have to manually work on all of those different combinations when updating a system. Like, first looping through all ABC entities, then through all BC entities, if you later decide to add an ABCD entity, you have to introduce that as well, and if they interact, manage that somehow as well.

This is probably solvable with dynamic code generation and re-compilation while working in your editor or whatever, but even then you'd have to find a way to let the user define system logic and then have the code generation cobble those different entity types together...

So I think explicit only really works if the entities in your game are not "different but some subset of components is the same" like that. Or to put it differently: If you have no need for data-driveness of your core entity types. I wouldn't go that route with a generalist framework. It probably works pretty well when you're coding your engine in parallel with every game, and adapt it to that game's needs.

So overall, it's completely true this is basically a static vs dynamic typing discussion, with all the same trade-offs and reasons why you're sometimes forced to dynamic typing in the end.

Edited by agleed

Share on other sites

Explicit can be data-driven. That's why I gave the example of an IoC container - that's data-driven composition as used in enterprise software. And it works fine with interfaces, inheritance, polymorphism, etc. (In fact, that's the whole reason it exists.) Personally I think there are too many hoops to jump through to make it worthwhile, but some people and companies swear by it.

Share on other sites

Regarding explicit vs implicit: The problem with explicit is that it's not data-driven at all.
...snip...

Sure it can be - the system I was describing was meant to load Entity definitions from a data file! And the rest of ...snip... doesn't have to be true; you can still have systems that operate on pools of specific components, with no knowledge of the parent entities whatsoever. i.e. you can use the typical ECS idea of having pools of components being operated on by systems, regardless of whether you use implicit or explicit component links.

Explicit can actually be more data driven than implicit. With implicit, the connections are always hard-coded -- e.g. Mesh will find it's transform by asking the parent entity for a Transform component GetSibling<Transform>(). With explicit, your data files can create inter-component relationships in different ways without needing to change any code.

At a previous job, we used an ECS, which supported implicit links (via something like GetSibling<Transform>()), but also supported explicit component links and data-driven entity definitions. As well as declaring entities in text files, as in my previous post, there was also a GUI tool for editing them and linking them up into interesting gameplay objects.
Designers could build Entities out of components in a node-based GUI tool, dragging and dropping to create components and define the explicit links between them, similar to:
and then you could use any entity as a component in a bigger entity:
In this system, the components themselves were written using extremely clean C++ code, plus some macros to create the "binding" code for the entity system:

class Mesh
{
public:
Mesh( Transform& transform );
void Foo();
private:
int m_foo;
};
BEGIN_COMPONENT( Mesh );
COMPONENT_CONSTRUCTOR( Transform& );
COMPONENT_METHOD( Foo );
COMPONENT_DATA( m_foo );
END_COMPONENT();

The macros would generate all the required code to serialize/deserialize them, create the component editor GUI nodes including all the draggable connection points, and allow the editor to enforce the construction requirements (e.g. above, a Mesh component must be explicitly linked against a Transform component). Declaring methods to the system allowed designers to write something akin to blueprint visual scripts.

The entities didn't exist as code at all, and were just text files in the data directory (compiled into binary files for shipping builds).

ECS is just an extended form of composition with data oriented and data driven design measures added in. They just counter the typical problems you get from deep inheritance trees, so I think it's natural to assume that stance of discussion and those comparisons are entirely fair.

The reason I say it's a straw man is simply because deep inheritance trees are usually just bad code, so these arguments compare their big entity framework against bad code in order to show that their framework is good, which is not an honest thing to do. Deep inheritance trees are usually not OOP code despite people calling it OOP. Lots of the blogs on ECS make the argument that "OOP is bad because deep inheritance, therefore let's use ECS for composition, as composition is better than inheritance, problem solved!"... However, they've skipped a really important step in the middle there, and have solved a false problem. The fact that composition is better than inheritance is a core rule of OOP, so it should be obeyed there too. You can (should) be writing composition based code without the need to set up a big composition framework in the form of an ECS library.

Share on other sites

Just to get on the same page... what are we talking about when we say explicit connections? I'm thinking about

struct ABCEnt
{
A *a;  //points to an A component in the big linear array of A components
B *b;  //same
C *c;  //same
}

Of course, you can do that at runtime with something like

struct Entity
{
Component *components; //can be filled in a data-driven manner
int numComponents;
}

Entity e;
A *a = GetComponent<A>(ent); //linear search in components

But that kind of stuff in my opinion is the opposite of explicit, on a code-implementation level. Are we talking about the same thing?

Share on other sites

It's more about the connections between components than the connection between an entity and its components.

If you have a function like GetComponent<A>(ent), then you're trusting that the entity has such a component, because nothing has explicitly guaranteed that it would be there.

But if you have no function like that, and instead a component takes references to other components in the constructor, you've explicitly supplied those connections to it, which is more robust. It is potentially more complex to initialise such a system, but it's less likely to be afflicted by run-time errors caused by missing components.

Share on other sites
@agleed Your first example is a hard-coded entity, but doesn't say antying about how the components link to each other.

Here's three examples of how components might communicate -- using the example that Mesh has a function "Foo", which relies on Transform's "Bar" function:
//Explicit:
class Mesh
{
public:
Mesh( Transform& t ) : transform(t) {}
void Foo() { t.Bar(); }
private:
Transform& transform;
};
//Implicit, component has explicit link to parent entity
class Mesh
{
public:
Mesh( Entity& e ) : parent(e) {}
void Foo() { parent.GetComponent<Transform>.Bar(); }
private:
Entity& parent;
};
//Implicit, shared ID's between global systems:
class Mesh
{
public:
void Foo() { EntityId id = MeshSystem::GetId(this); TransformSystem::Get(id).Bar(); }
};
In all three examples, the components might be allocated inside large pools owned by systems, and the entities might be defined in data files instead of code.

Or in an ECS where the logic is in the "systems" not the "components":
//Explicit:
struct Mesh
{
Transform* transform;
};
class MeshSystem
{
std::vector<Mesh> data;
void Bar() { for(const Mesh& m : data) data.transform->Foo(); }
}
//Implicit, component has explicit link to parent entity
struct Mesh
{
Entity* parent;
};
class MeshSystem
{
std::vector<Mesh> data;
void Bar() { for(const Mesh& m : data) data.parent->GetComponent<Transform>().Foo(); }
}
//Implicit, shared ID's between systems:
struct Mesh
{
};
class MeshSystem
{
std::vector<Mesh> data;
void Bar(TransformSystem& transforms) { for(uint id=0, end=data.size(); id!=end; ++id) transforms.data[id].Bar(); }
};

Note that in the explicit system, the entity only needs to exist in the data files. It's a template created by a designer, a kind of pre-fab of components that get spawned together and share a lifetime.
In the "Implicit, component has explicit link to parent entity" version, the entity is a "bag of components".
In the "Implicit, shared ID's between systems" version, the entity is "just an ID". Edited by Hodgman

Share on other sites

Or in an ECS where the logic is in the "systems" not the "components":
I'd argue that if you have logic on your components you have an "entity-component" architecture (Unity-like I guess) instead of an ECS.

I think nowadays, ECS's Wikipedia page is quite clear of what an ECS is, what each letter means, and what is the difference with entity-component architecture, it also provides nice links (like t-machine one) about it: https://en.wikipedia.org/wiki/Entity_component_system

And I'd also argue that it isn't "deep hierarchies" versus "composition", but actually object oriented programming versus aspect oriented programming.

First comparison focuses too much in the means ECS uses to achieve its goal, it focuses on it viewing it purely from an object oriented perspective where its either composition or hierarchies, and nothing else. It so happens you gravitate towards composition of objects because 95% of the time you're using an object oriented programming language to do these things and it happens to be the right tool for the job in that environment.

The higher level objective in itself isn't composition, is simulating aspects of entities. Thus you try to have a framework in which you don't deal with strict "types" of entities but with entities that can have aspects that can change the behavior of the entity, either individually or via a combination of aspects.

Share on other sites
I think nowadays, ECS's Wikipedia page is quite clear of what an ECS is, what each letter means, and what is the difference with entity-component architecture, it also provides nice links (like t-machine one) about it: https://en.wikipedia.org/wiki/Entity_component_system

Note the massive disclaimer at the top though: "This article is written like a personal reflection or opinion essay that states the Wikipedia editor's personal feelings about a topic, rather than the opinions of experts." :wink:

That particular strict form of ECS is basically just relational data modelling, rediscovered, without the rigor or flexibility.

For the most part, whether your logic is in a system or in the component is just syntactic sugar and makes no functional difference (assuming you still have systems of components that get batch-processed in both cases).

BTW The T-Machine blog is one of the many that give a dishonest comparison between (bad/incorrect-)OO and their flavor of ECS, while also failing to compare it with relational.

Share on other sites

That particular strict form of ECS is basically just relational data modelling, rediscovered, without the rigor or flexibility.
Eh no. Because you have a one to many relationship model between entities and components it doesnt means its relational. Unless you focus on a very tiny aspect, in which case the comparison would be meaningless, an object with a list of things would be "relational modelling" with the same criteria. Specially since relational models are about data, not behavior. As I said, ECS tackles behavior.

For the most part, whether your logic is in a system or in the component is just syntactic sugar and makes no functional difference
Yeah, in the same way as the lack of functional difference you'd have by say, writing your entire game in a single function. Functionally, they're the same. You'll still see pretty pictures on the screen.

Having logic in the components themselves means that components will need to know about other kinds of components, or about all of the other components of the same type. And you end up with these kinds of questions in the forums "What do I put in my components?" "How can I make component X relate to component Y?" "Omg I cant make the component logic isolated from other components! ECS sucks!". What if the same component is used for two different things? You just shoehorn the two different functions in the component and call it a day? It opens a whole can of worms.

The "system" part deals with that issue, providing a platform where you can place these dependencies between components and between entities. Systems know about entities, know about other components, and know about other systems. It is the place where you solve your data passing and communication issues.

Most of the component handling issues I see being asked in this forum stem from forgetting what systems have to do, and making components and entities do more than they're supposed to. So you end up having components having to know about other components, systems managing components and having to share them among other systems, which ends up in fighting hard with which system owns what components, and other kind of issues that shouldn't be really there if you follow ECS strictly. Then you end up with people implementing event systems for all the apparent shortcomings of ECS, and just pumping the data through there.

BTW The T-Machine blog is one of the many that give a dishonest comparison between (bad/incorrect-)OO and their flavor of ECS
Thats irrelevant. I did not argue with that point. I just said T-Machine blog is a nice source to learn what an ECS is, not what is good for. If it pairs it against bad OO or whatever is irrelevant for that purpose.

Share on other sites

Having logic in the components themselves means that components will need to know about other kinds of components, or about all of the other components of the same type. And you end up with these kinds of questions in the forums "What do I put in my components?" "How can I make component X relate to component Y?" "Omg I cant make the component logic isolated from other components! ECS sucks!". What if the same component is used for two different things? You just shoehorn the two different functions in the component and call it a day? It opens a whole can of worms.

The "system" part deals with that issue, providing a platform where you can place these dependencies between components and between entities.

That just moves the problem into a new place, and gives you 2 headaches (how do I carve my game up into orthogonal systems and components) instead of one (how do I carve my actors up into components).

The main reason newbies are confused about what goes in components is because they're trying to obey blog posts about how games should be structured before they've made a game and therefore before they understand how they would do things differently.

I just said T-Machine blog is a nice source to learn what an ECS is, not what is good for.

It's a nice source to learn what one particular person wants these approaches to be. I don't think we should accept that one particular definition gets to be called "Entity Component System" and other approaches, which also have entities and components, do not. (Especially since the blog tries to attach the label 'entity system', which is woefully underspecific.)

Share on other sites

That just moves the problem into a new place, and gives you 2 headaches (how do I carve my game up into orthogonal systems and components) instead of one (how do I carve my actors up into components).
Its a "headache" that separates the concerns better. It separates component ownership better. It separates component usages better. It separates the system dependencies better. If separating concerns is multiple headaches for you, then put everything in a god class. Only one big headache there.

I already listed the kind of issues you have to think  when stuffing the logic in the components. Moreover I already listed the issues people come here with when they do so. I'm just not seeing your POV here. Could you explain further the "two headaches" you mention?

I don't think we should accept that one particular definition gets to be called "Entity Component System" and other approaches, which also have entities and components, do not.
Then don't complain latter than there isn't a "clear definition" of what an ECS is. Its like handing you a MVC definition, then saying you dont like it because there are other architectures that use models and views, but not controllers. I know, thats why its called MVC, not MV.

I agree on the "Entity System" label though. It is vague, and stupid. Quite hard to come up with an architecture in a game that doesn't uses some form of entity, actor, or similar.

Share on other sites

That just moves the problem into a new place, and gives you 2 headaches (how do I carve my game up into orthogonal systems and components) instead of one (how do I carve my actors up into components).

It actually serves a couple of purposes:

- Moving logic into a higher level piece of code is a common way to address undesired cross-dependencies (which, as someone mentioned, is a common question on these forums when people attempt to implement an ECS "incorrectly").

- Moving logic into a place that knows about *all* the components of a certain type allows that logic to reason over them in an intelligent way (say, for optimizing spatial location queries).

Share on other sites

There's no reason you can't do both; have logic in components that only operate on itself, and have systems that operate on more than 1 component.

Share on other sites

There's no reason you can't do both; have logic in components that only operate on itself, and have systems that operate on more than 1 component.

So much this.

Just making up component names for these examples, but it is something I've done hundreds of times over the years.

It is straightforward and easy to write a component that hooks up to various commands and then only manipulates itself.

But for interplay, you could write something that detects another component before working.  All the systems I've worked with have had a way for components to identify their containing parent in the hierarchy, and also provided functions to scan for contained components, either as direct children or as nested elements.  Perhaps you'll build a component scans it's parent for a PhysicsObject component as a direct child.

Or maybe you write a mesh deformation component that gets it's parent, then requests all Mesh components from the parent. You may want to require the parent object contains exactly one Mesh component, and logs errors every time it is called and the attached components aren't found.

Or maybe you want to write an AI component that searches the parent for both an AiController component that you wrote and a AiLocomotor component. You can then derive your own specialized AiControllers or AiLocomotor types from interfaces, check that there are exactly one component implementing those interfaces attached, then either log the error or run the code using the detected components.

This type of automatic connection can be an alternative to directly-specified values. That alternative is to have a system that injects the target. You might have public methods to get and set the target component which validate that the component meets the interface you're interested in.  Then the target can be injected by the game engine at load time, or be injected by your own code that replaces the component while running, or some other means. Automatically detecting makes it slightly easier for anyone manipulating the world and slightly less error prone in case someone forgets to specify the target.

Share on other sites

This topic is 481 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Create an account

Register a new account

• Forum Statistics

• Total Topics
628765
• Total Posts
2984582
• Similar Content

• By Dimitry
Hi. I have a game prototype written in C# that I've been working on for some time.
I've studied some network programming and Unity. I have a client-server application demo completed. But I realized that making all alone is quite troublesome.
Unity graphics, networking, GUI, game logic, so on. So I am looking for a skilled developer who is also a fan of a Space Rangers computer game and space adventure games in general.
We could discuss and share some ideas and perhaps even meet in person at some coworking space.

• I need a Unity Developer for a game I've been working on for the past months.
It's a 2D dungeonCrawler with a typing mechanic along with Item specific attacks and Procedule Generated levels.
The development is planned to be 4 months long(up to 8 months maximum).
Although this is a hobby project the person who apply to work on this project will be paid once we(the team) find investors for the game.
Anyone interested Send an Email to netinhocrisosto@gmail.com with your portifolio or just talk about your expereince with Unity.

• THE PROJECT

INT is a 3D Sci-fi RPG with a strong emphasis on story, role playing, and innovative RPG features such as randomized companions. The focus is on the journey through a war-torn world with fast-paced combat against hordes of enemies. The player must accomplish quests like a traditional RPG, complete objectives, and meet lively crew members who will aid in the player's survival. Throughout the game you can side and complete missions through criminal cartels, and the two major combatants, the UCE and ACP, of the Interstellar Civil War.
Please note that all of our current positions are remote work. You will not be required to travel.
Talent Needed

Unity Engine Programmer
3D Animator
We have made great strides in the year 2017! INT has received a comprehensive face-lift compared to the start of the year. We look forward to a productive, fruitful year 2018!
Revenue-Share
This is the perfect opportunity to get into the game development industry. Being an Indie team we do not have the creative restrictions often imposed by publishers or other third parties. We are extremely conscientious of our work and continuously uphold a high level of quality throughout our project.
We are unable to offer wages or per-item payments at this time. However revenue-sharing from crowd-funding is offered to team members who contribute 15-20 hours per week to company projects, as well as maintain constant communication and adhere to deadlines. Currently the crowd-funding campaign is scheduled for the year 2018. Your understanding is dearly appreciated.

Thank you for your time! We look forward to hearing from you!

John Shen