Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Boreal Games

Member Since 24 Oct 2011
Offline Last Active Today, 02:38 AM

Posts I've Made

In Topic: is there a better way top refer to assets in a game?

17 November 2014 - 04:10 PM

In my system I've been developing I do as Zipster says.  There is no reason for the native code to deal with specific resources - it's all routed through script.  Since I'm implementing a sort of Scheme dialect, I have hashed keywords out of the box, which work just fine.  I limit the use of strings strictly to user interfaces.

 

My reinterpretation of Zipster's example would be:

(entity gigantopithicus
  (attack-sound :gigantopithicus-attack.wav))

In Topic: inheritage with classes

29 September 2014 - 10:49 PM

I do not need inheritage. It would be nice if I did since it would fulfill another  personal quota for the project but I do not need it.

 

Never ever ever ever ever ever use a programming pattern just to use it.  Most of the time you will be making the wrong decision.  Code should evolve from your needs, not the other way around.


In Topic: New trends in gaming: voxels are the key to real-time raytracing in near-term...

25 September 2014 - 12:27 AM

Plus, you have to deal with the issue of animating those suckers.

 

If you need procedural/destructible terrain or something it's much easier to polygonize voxel data using an algorithm like dual contouring (which I advocate over Marching Cubes as it has no corner cases and can handle sharp edges!)


In Topic: Entity component system: efficient component retrieval?

07 January 2014 - 02:31 PM

 

Check out the articles in my signature for how I do my components.  They're basically just arrays of components (one per type) and another array of component masks.  An entity is the aggregation of all the elements at a given index in the arrays, where the component mask describes which components "exist" (are turned on). It's cache friendly and requires no memory allocation past the initial allocation of the arrays.


I'm not sure I agree that components must be data-only and you also specified that systems operate only on groups of components when they all exist. Not sure what you meant by that but doesn't that negate the plug-and-play nature of ECS?

 

 

Nope, my system is perfectly plug-and-play.  The systems read the component mask to determine if they should act upon the component data for that entity.  If you're "adding" or "removing" a component, you're just modifying the component mask to change the visibility of the component to the systems.


In Topic: Entity component system: efficient component retrieval?

05 January 2014 - 09:45 AM

Check out the articles in my signature for how I do my components.  They're basically just arrays of components (one per type) and another array of component masks.  An entity is the aggregation of all the elements at a given index in the arrays, where the component mask describes which components "exist" (are turned on).

 

It's cache friendly and requires no memory allocation past the initial allocation of the arrays.


PARTNERS