next »

[Zorg]

The outline around the mouth is disturbing.



Cloudface Pixel Dailies? Optional restriction, height: 11 px.

[happymonster]

Looks like SpermMan to me.. 

[sidbarnhoorn]

This looks super-awesome! Definitely on my list to-buy/play. :-)

Thanks mate, I'm listening to some of your music, it's really great!

Thanks man! Glad you like my music. If we can collab at some point, I'm in!

[barneycumming]

those water splashes are really lovely- so many great details!

[eigenbom]

@Barney -- Thanks Barneyboi!
@Siddhartha -- Yeah dude, totally!

[happymonster]

Hi Ben,

Near the start of your devlog you talked about the design for the objects in the game:

Ideally I'd like it to be very easy for someone to add a new animal, enemy, item, or effect to the game. To that end I've worked a bit today on the entity system, trying to design a nice entity-based system with lua scripting, networking, and simple storage. Once finished, a user should be able to add e.g., a chicken to the game by writing a little lua script:

Code:
local cluck_pid, chicken_eid
function onLoad()
  cluck_pid = register_property("chicken_clucker", clucker())
  chicken_eid = register_entity("chicken", chicken())
end

function chicken()
  local ch = create_entity("actor")
  ch.sprite = sprite_sheet("chicken.png", ...)
  ch.speed = .1
  ch.add_attribute_bool("clucking", false)
  ch.add_property(cluck_pid)
  return ch
end

function clucker()
  local p = create_property()
  p.on_receive_message = function(e,msg)
    if (msg.type == APPLY_DAMAGE)
      e.clucking = true
    end
  end
  return p
end

The design's a mashup of the ideas from some of the following articles, and I'll write some more about it as it is fleshed out some more.

A Data-Driven Game Object System - Scott Bilas

Entity Systems are the future of MMOG development - Adam Martin

The Nebula3 Application Layer

Evolve Your Hierachy - Mick West

What are your thoughts on this now the game has advanced so far?

[eigenbom]

..
What are your thoughts on this now the game has advanced so far?

Heya Well as you know I abandoned the scriptable modding system quite early, but some of the other ideas in that early design have survived. Internally I make use of an Entity-Component system and I have factory functions for constructing entities from the components. The hypothetical chicken example in Moonman engine would look something like this:

Code:

ID makeChicken(){
  ID id = gCore->entitySystem->add();
  auto& e = ENTITY(id);
  e.add(Info("a chicken named fred"));
  e.add(Transform(x, y));
  
  Health health(8);
  e.add(health);
 
  SpriteDriver sd;
  sd.sprite = RES("sprite/chicken"); // hashed resource
  e.add(sd);
  
  Renderable renderable;
  renderable.z = FOREGROUND_Z + 20;
  // renderable.effects = ...
  e.add(renderable);

  Physics physics;
  physics.isMob = true;
  physics.collisionHeight = 1;
  physics.collisionWidth = 1;
  // ... 
  e.add(physics);

  // General mob properties
  Mob mob;
  mob.type = MT_CHICKEN;
  mob.properties = ...;
  e.add(mob);

  Animal animal;
  animal.friendliness = 1;
  e.add(animal);

  return id;
}

Each of those components: Physics, Animal, etc., all have a related system, PhysicsSystem, AnimalSystem, ... that processes all the components they are interested in. So Physics::update() will iterate over all physics components (which are stored sequentially in memory) and perform one physics step. Animal::update() controls some of the animal-like mobs with simple state machines. Access to components looks like:

Code:

auto& e = ENTITY(3); // get entity with id 3
auto& info = e.get<Info>(); // get info component
print(info.description);
if (e.has<Animal>()){
  // has an animal component ..
  // disable its render component
  e.disable<Renderable>();
}

The one major change to the system from back then is that Entities used to have a big pool of attributes in them, which could be added/removed and adjusted. Like a big bucket of variables. Entities now have a set of Components instead, and each Component has a bunch of variables. So Animal might be:

Code:

enum AnimalState {
  AS_IDLE,
  AS_FLEEING,
};
struct Animal : public Component<Animal>{
  AnimalState state;	
  double annoyedFactor; // e.g.,
};

The engine also makes heavy use of events. Each system generates events in its update loop, they are then processed by the top-level system, and then passed back down into the systems. So AnimalSystem could emit ChickenCluckEvent, the top-level could then pass it to the HumanSystem, and cause a nearby human to react to it. Events are simple structs, the code of which is generated from an excel spreadsheet. The main idea of events is 1) to avoid having lots of cross-system calls (ie. to centralise the logic), and 2) to defer all the game logic until after all systems have updated. Each system has its own event queue.

A simple event struct:

Code:

struct EvSetBlock {
  uint16 type;
  uint32 data;
  uint32 x;
  uint32 y;
  bool wall;
};

[eigenbom]

Update: Updates! NB: "arc1" refers to the basic first forest level we're currently working towards.

Salt deposits now appear (rarely) in stone cove
Camera tracks MM much quicker, so he doesn't disappear out the bottom of the screen when falling
Added minipick, a basic ORE mining tool
Added toolbox, a crafter for the first few items
Updated recipes for arc1 (see image, e.g., "wb 2 lumber iron" = workbench + 2 lumber + 1 iron (ingot), "mini" is the crafting box in your inventory)
Updated block properties for arc 1 (see image. The number of hits to mine a resource incorporates the mining type and level of the item used, as well as block multiplier and health. E.g., 3 chops to get some lumber from a tree with a hatchet.)
Mining web with FIN tool gives thread. Killing stone_slug gives sharpstone. etc
Added meteors in background (see image), minor bg updates
MAJOR: Created new resource format for all world objects (furniture, crafters, skull piles, torches, etc.) This took about 3 days to convert everything, but will dramatically reduce the time it takes to add extra objects in the future.
World objects now have better hitboxes and now how big they are, which will result in significantly less overlaps in the world (see image, a test area where i've dropped random items and they more-or-less are spaced out properly).
GP is back to work after a small hiatus and has been working on some creatures (see image)

Some item recipes


Some block properties.


Meteor


World objects overlap less often


Creature feature: Rock Lobster sits in pools, rocking away.


That's it!

[eliasdaler]

Why did you drop the scripting system?

And the meteor looks great

[happymonster]

Thanks Ben! Very interesting

[eigenbom]

Why did you drop the scripting system?

There was never really anything there to begin with, just the start of an idea.

HM - No worries!

[eliasdaler]

Why did you drop the scripting system?

There was never really anything there to begin with, just the start of an idea.

Any particular reason why you didn't implement it?

[eigenbom]

Why did you drop the scripting system?

There was never really anything there to begin with, just the start of an idea.

Any particular reason why you didn't implement it?

I made the decision a long time ago and I can't remember exactly why -- I'm sure its in the devlog somewhere. I always teetered between wanting it and not wanting it, and have enjoyed building scriptable software in the past. Generally I have shifted towards coding in a simpler and more straightforward way, the less moving parts the better.

[Rusk]

Some juicy code is a nice change from all the heavy pics lately!

edit: it's not that I don't like pictures, it's just... it's Friday!

edit2: May I ask, what's the benefit of the templated get<ComponentClass>() compared to using an enumeration like get(componentEnum)?

[oahda]

An enum is constant and needs to be modified with the addition of every new type, whereas actually directly using the type as a template type you don't have to update anything when the initial system is in place. It Just Works™.

I guess?

I use something very similar in my engine, as does Unity.

---

As for scriptable stuff, you should probably just do what everyone else does and bind a language that's already out there instead of implementing your own. So much easier. But I guess you dropped the idea entirely?

[eigenbom]

Prinsessa is right about the extra enum, but also, using a get<Foo> returns a Foo&, and so u don't need to dynamic_cast on the caller side. It's all based on static polymorphism (if I remember the term properly).

[siskavard]

am i the only one that sings Soundgardern's Spoonman but instead say Moonman?

[eigenbom]

am i the only one that sings Soundgardern's Spoonman but instead say Moonman?

i think its been mentioned about 10 times in the devlog over the years. would make a great theme song. please record it!

[Rusk]

Prinsessa is right about the extra enum, but also, using a get<Foo> returns a Foo&, and so u don't need to dynamic_cast on the caller side. It's all based on static polymorphism (if I remember the term properly).

Thanks, I'll check that out.

[oahda]

Prinsessa is right about the extra enum, but also, using a get<Foo> returns a Foo&, and so u don't need to dynamic_cast on the caller side. It's all based on static polymorphism (if I remember the term properly).

And that, of course. Unfortunately I haven't managed to bind identical functionality to AngelScript, so you still have to do some sort of bulky cast<Emitter @>(get(type("Emitter")) in scripts ATM.