• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
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='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]
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 IamMediaGames
      Do you like numbers?
      Actually I do.
      When I was child, I enjoyed to make multiples of 10 using license plate.
      It was not a big deal, but quite interesting to me.
      Decades later I planned to make a game and remembered that time.
      So I decided to develop game based on that memory.
      At the first time , it was just game to make 10, but I started to put various game like elements: 
      items, obstacles, store, trophies, leader board, etc...
      And finally it becomes a game.
      Some people tells me it's too difficult, but some people tells me it's enjoyable.
      How does it looks like to you?
      "Puzzle Ten Final"
      Android Exclusive.
       
       
       
       
    • By Kajamaz
       
      Summary: EverEmber Reborn is a multiplayer online hardcore open-world action RPG. 



      Description:
      The game takes place in the world of EverEmber, a fantasy world where you have no direction, only your skill and other players to either aid or hinder you on your journey. The game is a first person open world pvp game, with progression aspects taken from agar and slither. The world is not too huge, and because of that players will constantly fight and die, dropping their obtained gear and forcing to restart. The combat is skill based, with many places to explore. The best aspects from Runescape, Ultima, Mortal online, and the Elder Scrolls games are taken and incorporated. Everyone has their own adventure, it’s your choice how it starts and ends.

      EverEmber Reborn is a sequel to the game EverEmber Online (check it out at http://www.everember.com/). They are very different in their concept and execution, but the fantasy elements and ideas are brought over from its predecessor. We have been developing EverEmber online for over 4 years, but it’s time we move on. We have also worked on various private server projects, so the developmental process is nothing new for us.

      Team:
      We currently have a fairly large development team already, 10 main developers, myself, Ozfer (server host, developer, IT tech), Juicyz (Lead Programmer), EMPHyperdrive (Programmer) Amit (Game Developer and Modeler), HugeJackedman (Game Developer), Gw1p (Game developer), Naitsirik (Modeler), Symbolizemusic (Musician), Aytimothy (Programmer). We also have a musician assisting us (Davide Severi) with our soundtrack and a concept and concept artist (Akram). SeeEnvy is a writer for us.

      What we're looking for:

      What we need are programmers as of this moment. We need someone who is determined on helping us program the game itsself. We have much of the networking done and we are using Photon. The language we're using is C#, so knowledge of C# is a MUST HAVE!

      Requirements:

      -Experience with Unity and its technology

      -Interest in the games concept

      -Ability to do one of the things listed in our needs, either C# unity programming, or networking assistance.

      -Time to dedicate to the game, we don’t have a constraint but a few hours every couple of days will suffice.

      -Be able to communicate in English, as all of our team speaks English either fluently or well.

      -Have a method through which we could pay you eventually.

      Eye Candy (In-game screenshots):







      More Eye Candy/Concept Art:
       



       
       
       
      If you are interested, please do contact us via Everemberonline@gmail.com or message me here on unity forums with what you can do for us, why we interest you, and whatever questions or comments you have. Feel free to join our website if you cannot help us in development, but instead can assist us by playing the game upon release or testing it!

      http://www.everember.com/

      See you in the land of EverEmber.
    • By tatar1nro
      Hi, we are small game develop studio called Drunken Monday. We are only two people and during the last year we developed a cross-platform multiplayer game: Slash Arena. And we're almost done. We are glad to present you our game:

      Massively multiplayer online battles with swords and axes.
      Simple arcade action! Dodge the attack and choose a perfect time to strike.
      Upgrade your weapon, slash enemies, collect resources and reach the top!

      Battle Modes:
      ★ Deathmatch — Player vs All mode for 30 players. Score the highest damage and survive to win.
      ★ Arena 1vs1 — ranking duel for hardcore players. Your skills mean more than your high-level weapon.
      Features:
      ★ Rapid battles. Play 5 minutes or 5 hours. It’s all up to you!
      ★ Swing your hammer and make 'em fly! Damage is calculated according to physical laws. Timing and distance matter!
      ★ Two types of attack — enough to make your enemy suffer from a painful combo! Master your skills.
      ★ Separate ratings for each Battle Mode. Monitor your progress.
      ★ Monthly rewards for the best players. Earn a pile of resources and unique character portraits.
      ★ Daily tasks. See if you can cope with them! >:]
      ★ Three characters with unique weapons and fighting styles. More characters are coming soon!
      ★ More than 30 upgrade levels for each character’s weapon and armor. Start with a simple leather jacket and get to the legendary royal armor!
      ★ Character’s appearance changes each 3 levels. Everyone will see how cool you are!

       
      Game available on: Facebook, it passed greenlight and coming on Steam, soft-launched on GooglePlay and AppStore in Russia ( If you contact us we will send you .apk or testflight invitation ). Also take a look at Slash Arena: Online and Drunken Monday web sites. 
      We will be glad to hear your opinion!
    • By NA-45
      EDIT: We've found a designer/composer and an artist.  I'm looking for one more artist!
       
      I'm currently working on Metroidvania style game that I was inspired to start by Hollow Knight and Beksiński's art.

       It's built in Unity using C# and has quite a bit done already.  I'm handling the programming myself and have a working model (besides combat which is a WIP) that can be expanded greatly depending on where we decide to take the project.  You can see the current test area here: https://streamable.com/mp5o8  Since I'm not artistically gifted, its all rectangles but can easily be skinned once we've desired on designs.
      I have professional experience using Unity and C# working on both a released game and a prototype as well as having extensive Java knowledge.  I also dabble in Python with a little bit of C++.
      I have worked on and completed many projects before, the most recent being a 2D stick fighting game written ground up in Java Swing (don't ask why): https://www.youtube.com/watch?v=V4Bkoyp_f0o
      I'm looking for a 2D artist (potentially more than one) to create concept and game art and a designer/writer who can help flesh out the story as well as map out and create challenging and eye catching areas.  I can handle most if not all of the programming side of things though if there is anyone who is extremely passionate about this sort of thing, I'd consider splitting the load.
      The end goal is a completed game that can be sold however profit isn't really a concern to me as it's mostly a labor of love from my part.  Any profits would be split between team members however that's pretty far off so don't make that a reason to join.
      ______________________________
      The story I have in mind is something like this:
      A man wakes up in a chasm that stretches seemingly endlessly in both directions lined with enormous statues.

       He discovers a temple with text above a closed gate that tells of the failed kingdom that lies below.  After finding a way around this, he drops down into the subterranean kingdom.  Adventuring through the labrynth below, he comes across different cities in which the residents succumbed to different sins such as Greed, Wrath, etc.  Each city tells a story of how its fixation on something lead to their demise leading up to a fight with the personification of their mistake.
      ______________________________
      An very rough idea for Waterways, a potential area:
       - To enter you must be wearing a pair of glasses that you find somewhere earlier in the ruins.  There are similar glasses found in every home.  Everything appears incredibly beautiful however something seems wrong.  After triggering some event, the glasses break and it's revealed that the glasses are made of some sort of stone that makes everything appear differently.  The city is in ruins and absolutely disgusting as everything was neglected.  
       - The only thing that remains intact is in the center of the city, an incredible statue of a goddess holding up a large sphere of the same material that was used for the glass.  You slowly learn the story behind the statue: the goddess came from the sea that the city lies on and brought prosperity to them.  
       - After opening up the the temple of the goddess that lies right on the edge of the waters, a giant sheet of the glass covers an opening in the back of the temple that reveals the goddess behind it.  You shatter the glass and it becomes apparent that the goddess is actually a disgusting creature half beached and mostly immobile that appears to secrete the material that makes up the glass. Fight ensues.
      ______________________________
      The combat is pretty up in the air and part of the reason I need a designer to bounce ideas off of but I think it will be something like this:
       - 4 orbs equipped at a time
       - 2 orbs selected at a time
       - Pressing the cast button will cast a spell determined by the 2 orbs that are selected
       - Spells cost mana however you can use spells with 0 mana and it will cost health instead
       - These spells in addition to being useful for combat, are the Metroidvania "gating" metchanic.  For instance, one of the conceptualized spells is a water orb + water orb to create a ice pillar that can be either used to block projectiles/enemy paths or to jump on to reach high areas
      ______________________________
      If you're interested or have any questions, contact me through discord.  My id is NA-45#3692. 
    • By sZokka
      Radio Rabbit
      DOWNLOAD:
      https://gamejolt.com/games/RadioRabbit/269209

      About The game
      Radio Rabbit is a local coop shoot ‘em up where two players control one more or less combined character. The character exists out of a rabbit’s body and a floating, still to the body connected, giant eye.
      Each player controls one of them.

      The rabbit’s goal is to fly safely through the level and to avoid enemies to reach the goal.  The Eye on the other hand can shoot. He is the one who clears the way. One character can move the other can shoot. So both player need to work together to fight of evil creatures and to complete the level.

      •    explore the level to find the key which activates the portal gate
      •    escape through the portal before the timer runs out
      •    if you are to slow, the nuke will explode
      •    use your character abilities, the rabbit can boost while the eye got the vision
      •    you’ll get more powerful abilities from items such as a supershot
      •    shoot as many enemies as possible to gain score
      •    remaining time at the end of each level gets added to the score
       

      Features
      •    2 Player couch coop
      •    4 level + tutorial
      •    an epic boss fight
      •    fully gamepad supported (XBox or equivalent)
      •    local high score
       
      Grab a friend and check it out!
      Please feel free to leave comments and feedback!
      DOWNLOAD:
      https://gamejolt.com/games/RadioRabbit/269209
      and ENJOY!
  • Popular Now