Jump to content
  • Advertisement
Sign in to follow this  
  • entries
    7
  • comments
    12
  • views
    1334

Introduction - Organ Tree

Lyfe

969 views

For our first dev blog entry we decided to introduce you to the organ-tree which we already described in our design document.

If you haven't read you can find it in the description of our project here.

 

So about that organ-tree:

Organ-Tree_1.thumb.png.f9706ea1c4f4fff7cacf9e9f5bff5e67.png

This is it: The tool you use during the creature stage to unlock or as it will be called ingame "evolve" your organs/skin types/body parts.

Now, this is still a very rough outline but I think the intention is clear.

One important design decision we made is to split it into three categories: Aquatic, Terrestrial and Both, with you starting off mostly in the aquatic branch, since your life (or lyfe if you will) as a complex creature will start off in the beautiful and mysterious depths of the ocean.

 

Parts from the aquatic part of the tree might be useless on land or even harm you and vice versa. For example you don't want to leave the water with gills on your creature because you will run out of oxygen very quickly. This doesn't apply to all parts, though. For aquatic hands for example it is more of a design choice (We might add gameplay functionalities later like aquatic hands help with swimming but aren't good for attacking while with some hands developed from the terrestrial branch you can claw at your rivals or prey).

 

You might have noticed that every set of organs has one base set and four versions deriving from it with numbers at the end. Each new version will be a new model/have a new design and slightly different stats. We are not 100% sure if we can keep the 4 stages of each organ but we will try. Because you know what they say: "Shoot for the moon. Even if you miss you will end in the vacuum of space and die alone."

 

What's next? The skin types. This is something where we really want to make use of the advanced technology we have compared to that from Spore almost ten years ago. Skin might not have an effect on the gameplay (yet, we're planning something for our nice-to-haves) but will make your creature look fantastic. The plan was keep it a small number of types but make them well differentiated.

 

Eyes: Withou eyes you won't be able to see anything, pretty straight forward, BUT: How good your eyes are determines how well you see objects at a distance/how far you can see. As a little bonus we also added a branch that grants you nightvision if you plan on making a nocturnal creature.

 

Finally: The brain. This is an indicator for your prograss in the creature stage. You start off with the first and most basic brain. You have to unlock all three upgrades to be able to enter the next stage which we will undoubtedly discuss at some point in this blog.



8 Comments


Recommended Comments

Sounds pretty cool, I've always thought someone should have another go at the Spore concept but try to do a bit better and apply some more advanced techniques! :)

Share this comment


Link to comment
1 minute ago, jbadams said:

Sounds pretty cool, I've always thought someone should have another go at the Spore concept but try to do a bit better and apply some more advanced techniques! :)

Thanks for the reply. We will definitly do our best and some more. :)

What do you mean with 'advanced techniques'? With regard to what Spore did? Just asking so we know what people whant from this.

Share this comment


Link to comment

Yeah, I didn't have anything particular in mind, just an improvement on Spore, which was interesting enough, but for me at least never quite lived up to its promise. :)

Share this comment


Link to comment
7 hours ago, jbadams said:

Yeah, I didn't have anything particular in mind, just an improvement on Spore, which was interesting enough, but for me at least never quite lived up to its promise. :)

We want to keep our development as transparent as possible to not generate unnecessary hype the game can't live up to. 

 

Although we are still a small team now we work on expanding to get the necessary resources to make this vision come true. And with the advancement in game engines since Spore we are fairly optimistic we will improve on a lot of its shortcomings. 

Share this comment


Link to comment

the concepts around the creatures eyes sounds cool.  So then will the eyes you use for your creature directly affect your field of view in some way?

Share this comment


Link to comment
1 hour ago, Awoken said:

the concepts around the creatures eyes sounds cool.  So then will the eyes you use for your creature directly affect your field of view in some way?

It will. 

Let's say you got your first set of eyes on your creature. With those it can see about 20m (or something, game play tests will tell). After you evolve (unlock)  the second set you also have to add them to your creature to benefit from their increased stats. 

Share this comment


Link to comment
23 hours ago, Lyfe said:

What do you mean with 'advanced techniques'? With regard to what Spore did?

One of the weird things about Spore is that they showed up to E3 a couple of years before release, and showed off a build with all sorts of emergent behaviour (creatures gait was derived from the shape of it's spine and position of joints, that sort of thing). By the time release rolled around, they'd stripped out almost all of that in favour of the final "plug and play" approach where you just attached pieces for "+1 speed".

Needless to say, that was pretty disappointing. Though not surprising - the original vision was very ambitious, and the most ambitious features usually get cut when ship time comes knocking.

Share this comment


Link to comment
1 minute ago, swiftcoder said:

One of the weird things about Spore is that they showed up to E3 a couple of years before release, and showed off a build with all sorts of emergent behaviour (creatures gait was derived from the shape of it's spine and position of joints, that sort of thing). By the time release rolled around, they'd stripped out almost all of that in favour of the final "plug and play" approach where you just attached pieces for "+1 speed".

Needless to say, that was pretty disappointing. Though not surprising - the original vision was very ambitious, and the most ambitious features usually get cut when ship time comes knocking.

Ok,ok. I get what you mean.

So far we plan on having the movement calculated from your creature's bodystructure BUT also add different types of legs that give you +1 speed (just to give an example; maybe we might also just restrict that to the 'campaign') because it makes sense from a gameplay point of view.  Just to answer that point because it's something important to me, too.

 

About removing amitious features:

We are not a company. We don't have deadlines. This has it's ups and downs. For one we are a small team doing this because we share a common vision of what could be which might slow down development. On the other hand we have all the time to publish it and can stay faithful to that vision.

We just want to make the best version of this game we can.

I want to promise a lot but know I can't.

Share this comment


Link to comment

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
  • Advertisement
  • Advertisement
  • Blog Entries

  • Similar Content

    • By EnderStaffExe
      Hello! I'm new to the scene of video game developing and was wondering if anyone here has any experience developing 2D fighters and are up for making a little test demo to see if the idea would catch on to the public? I have no way of paying but I want to put the demo onto Kickstarter and I will pay a good amount if I get a good amount. Please, if you want to contact me for more info, add me on my Discord or Twitter. Thank you, and see you later!
      (Twitter: @enderstaffexe
      Discord: EnderStaffExe#3193)
    • By Mapet
      Hi, I started implementing 2D board game. I have concept of how to write rules, controlls etc, but i dont want to write another all-in-app. So i decided to do it "right". I divided my code into reuseable modules - ResourceManager, Renderer, Core, Math (for now). All modules use SDL2.
      ResourceManager(RM) - loads textures, audio etc without duplicating them in memory. Resources are gathered in TextureResource, AudioResource (...) objects, handled by std::shared_ptr. For textures I have prepared Texture class that wraps SDL_Texture and I RM serves this Texture objs for Core module.
      Core - The main game module, contains game loop, gameobject / component implementation and event handling. Core requests for data from RM and sends them to right components.
      Renderer - Creates window and knows about render range (in core represented by camera). Takes info about texture, position, rotation and scale to render images (just this for now).
      Its time for my questions:
      is this architecture good? After I end this board game I want to extend renderer module for example for rendering 3D objects.  Loading resources while ingame is good idea? I mean single textures, models, sounds etc.  As I said, for handling resources I am using shared_ptr, is it good cleaning cache every (for example) 3 minutes? By cleaning i mean removing not used resources (counter =1). And the hardest thing for me right now - take a look at this flow: Core create a T1 token Component Renderer2D is connected to T1. Core requests a texture /textures/T1.png from RM. RM checks if /textures/T1.png is in map, if not, loads it. RM returns a std::shared_ptr<Texture> to Core. Core assign texture to T1 Renderer2D component.
      Now i want to pass this object to renderer. But I wont pass all gameObjects and checks which have renderer2D component (i also cant, because only Core know what is gameObject and component). So i had an idea: I can create Renderable interface (in Renderer module) and inherit from it in the renderer2D component. Renderable will contain only pointers to position data. Now i am able to pass renderer2D component pointer to Renderer and register it.

      Is this good way to handle this? Or im overcomplicating things? If point above is right I had last question - registering object in Renderer module. I dont want to iterate over all objects and check if I can render them (if they are in render range). I wanted to place them in "buckets" of - for example - screen size. Now calculating collisions should be faster - i would do this only for objects in adjacent buckets. But for 2D game i have to render objects in correct order using Z index. Objects have to be placed in correct bucket first, then sorted by Z in range of bucket. But now i have problem with unregistering objects from Renderer module.
      I think I got lost somewhere in this place... Maybe You can help me? Of course it this is correct way to handle this problem. I would love to read your comments and tips about what can I do better or how can i solve my problems.
      If i didnt mention something but You see something in my approach, write boldly, I will gladly read all Your tips :).
    • By ERASERHEAD STUDIO
      A new entry in the devlog for 13 Ronin, a retro 2d samurai fighting game, this time it's about implementing the logic for the computer player.
      Happy coding!
      https://www.eraserheadstudio.com
       
       
    • By Seer
      Currently if I was to program a game using C++ with SFML or Java with LibGDX I would render game objects by calling "object.render()" on the game object. Although this makes it easy to access the information necessary to render the game object, it also couples rendering to the game logic which is something I would like to move away from. How can rendering be implemented so that it is decoupled from the game objects?
      I wish to know how this can be done in the standard object oriented paradigm, so please don't suggest that I use an ECS. Thank you.
    • By sidbhati32
      Hey,
      So I have got this asteroid type game and today I encountered a new issue while testing this game.
      What happened was that two asteroids were close to each other and I shot a bullet at them. The asteroids were so close to each other that a single bullet could collide to both of them.
      It collided and my game crashed there itself. I figured out it happened because two asteroids and one bullet collided in the same frame.
      This is the code -
      ```void Collision::DoCollisions(Game *game) const
      {
          for (ColliderList::const_iterator colliderAIt = colliders_.begin(), end = colliders_.end();
              colliderAIt != end;
              ++colliderAIt)
          {
              ColliderList::const_iterator colliderBIt = colliderAIt;
              for (++colliderBIt; colliderBIt != end; ++colliderBIt)
              {
                  Collider *colliderA = *colliderAIt;
                  Collider *colliderB = *colliderBIt;
                  if (CollisionTest(colliderA, colliderB))
                  {
                      game->DoCollision(colliderA->entity, colliderB->entity);
                  }
              }
          }
      }```
       
      ```
      void Game::DoCollision(GameEntity *a, GameEntity *b)
      {
          Ship *player = static_cast<Ship *>(a == player_ ? a : (b == player_ ? b : 0));
          Bullet *bullet = static_cast<Bullet *>(IsBullet(a) ? a : (IsBullet(b) ? b : 0));
          Asteroid *asteroid = static_cast<Asteroid *>(IsAsteroid(a) ? a : (IsAsteroid(b) ? b : 0));
          Bullet *bulletMode = static_cast<Bullet *>(IsBulletMode(a) ? a : (IsBulletMode(b) ? b : 0));
          if (player && asteroid)
          {
              player->playerCollided = true;
              //AsteroidHit(asteroid);
              //DeletePlayer();
          }
          if (bullet && asteroid)
          {
              collidedBullets.push_back(bullet);
              collidedAsteroid.push_back(asteroid);
              //AsteroidHit(asteroid);
              //DeleteBullet();
          }
          if(bulletMode && asteroid)
          {
              collidedBulletMode.push_back(bulletMode);
              collidedAsteroid.push_back(asteroid);
          }
      }```
       
      ```
      void Game::CollisionResponse()
      {
          if(player_->playerCollided == true)
          {
              DeletePlayer();
          }
          else
          {
          if(!collidedAsteroid.empty())
          {
              for(AsteroidList::const_iterator collidedAsteroidIt = collidedAsteroid.begin(), end = collidedAsteroid.end(); collidedAsteroidIt != end ; ++collidedAsteroidIt )
              {
                  AsteroidHit(*collidedAsteroidIt);
              }
              collidedAsteroid.clear();
          }
          
          if(!collidedBullets.empty())
          {
          for (BulletList::const_iterator bulletIt = collidedBullets.begin(), end = collidedBullets.end() ; bulletIt!=end; ++bulletIt)
          {
              DeleteBullet(*bulletIt);
          }
          
              collidedBullets.clear();
          }
          if(!collidedBulletMode.empty())
          {
              for (BulletList::const_iterator bulletIt = collidedBulletMode.begin(), end = collidedBulletMode.end() ; bulletIt!=end; ++bulletIt)
              {
                  DeleteBulletMode(*bulletIt);
              }
              collidedBulletMode.clear();
          }
      }
          }```
       
       
      in my game->docollision() -
      whenever an asteroid and a bullet used to collide, the collided objects get collected in collidedasteroids and collidedbullets respectively. When two asteroids collided with the same bullet, the two asteroids got collected safely in collidedAsteroid but the single bullet got collected in collidedBullets twice, so when the deletion was happening, the second time iteration of the bullet couldn't find the respective bullet and it got crashed.
       
      How am I supposed to approach this problem now?
       
      Thanks
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!