Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Hodgman

Member Since 14 Feb 2007
Offline Last Active Today, 09:25 AM

#5062263 Question about the Entity Component System architecture

Posted by Hodgman on 16 May 2013 - 06:38 AM

The short answer is - different people do it different ways, and they all work

^this. 
"ECS" is not as specific as other design patterns. It's a very vague description for hundreds of different designs, with the only common pattern being "components are some kind of structure, entities are groupings of components". That detail alone can be implemented in dozens of ways, and there's dozens of other details that may or may not even exist depending on the overall design, and whether the designer has come from a relational, OO, procedural or functional background, etc...
 
Different "ECS" systems are also designed around different requirements.
Sometimes the whole point is so that different components can automatically find each other, and send messages to each other without the programmer having to manually bind them (the "entity" is basically a message router and service provider).
Other times the whole point is just to allow entity "templates" to be defined in data (the component connections might be specified in the data files or magic like above), with the ECS basically being a fancy serialization and inversion-of-control library.
Other times the whole point is to decouple different parts of entities so that data can be rearranged into cache-friendly structures and processing can easily be multi-threaded (i.e. a design stemming from performance considerations, to avoid the pitfalls of OOP).
 
Given this huge range of designs falling under the "ECS" banner, you really have to be able to define what it is that you want your ECS library to achieve and what it's requirements are, before you can evaluate the merits of different design choices.
 
With that out of the way...

Where do the components "live"? Getting into implementation specifics, I'll be writing this in C++. So, for the sake of example, let's say I have a position component, a velocity/movement component, and a motion system which acts on both components.

Would it make sense for each entity to have a data member container consisting of pointers to components? If so, how would the motion system keep track of which entities have position and velocity/movement components? Or maybe a better way of phrasing the question is: How does the motion system keep track of which components it needs to iterate over when it runs?

I'm not a fan of the automatic binding (entity as message router and service provider) style of ECS, and I personally prefer a style where entity is a component, rather than some first class concept of the pattern. So, I'd KISS and just implement this in 7 lines of code, with the supporting library only being a compacting-pool class (a pool that moves items to always be contiguous, whenever a 'hole' is created through erasing an item) that supports handles (because pointers won't work due to the compaction):

struct Position { Vec3 pos; };
struct Movement { Handle<Position> who; Vec3 velocity; };
void MovementSystemUpdate( const Pool<Movement>& movements, Pool<Position>& positions, float dt )
{
  for( const Movement* m=movements.begin(), *end=movements.end(); m != end; ++m )
    positions[m->who].pos += m->velocity * dt;
}

Bam! "ECS" without the bloat cool.png




#5062204 Multi-lingual text?

Posted by Hodgman on 15 May 2013 - 11:10 PM

Unicode support: I don't know.

This is the first thing to figure out then.

Where does your input text come from? You need to know which encoding it is stored in, such as UTF8, UTF16, etc...

 

stb_truetype seems to operate on 32-bit unicode code-points, so I assume that if your text is UTF8, you need to convert each UTF8 multi-byte code-point into a single UTF32 code-point before passing it to std_truetype.




#5062184 My ever-evolving coding style

Posted by Hodgman on 15 May 2013 - 09:06 PM

Honestly I like returning pointers for most cases

I think the point is that his 'getters' are useless, because his code is equivalent to as if the variables were just public...

It's just a really bloated way of writing this:

struct Foobar
{
    int foo;
    RGB bar;
    double baz;
};
void frobnicate()
{
    Foobar foo;
    foo->foo = foo->foo+7;
    double thing = foo->baz;
}



#5061952 Sparks Effect

Posted by Hodgman on 14 May 2013 - 08:01 PM

The thing that frustrated me is that I can't use FFP light and that I'll be forced to create light using Shader.

Sparks are emissive (they are lights) so they don't need to be lit.

Can you show me a simple texture that could be used for sparks? I'm not sure how the texture should look like.

I would render them as lines, as mentioned above, and colour them with a gradient from the front to the back of the line.

You could either do this with a 1D texture, or by simply using vertex colours:

spark.png

What I know is that Volumetric lines can be used for laser beam, what that has to do with the particles engine?

There's many ways to draw particles.

Instead of drawing a quad where the particle currently is right now, you can draw a line between where it is now, where it was a moment ago, and where it was a moment before that. This gives you a curved line. If you colour that line with a gradient like above, and render it with additive blending, then you get the impression of a very fast moving bright object.




#5061663 Will this strategy get me into the gaming industry?

Posted by Hodgman on 13 May 2013 - 08:42 PM

So recently I've been working on building my own Game Engine ... after i finish my engine [I'm thinking] of developing a game off of it, it'll be a Breakout like game, that is a small game that will show what this engine can do.

In my experience, these "engines without games" projects do not go well. The list of things that an engine could do is endless, and the list of ways that you could solve any single one of those things is also endless. On the other hand, a particular game, like Breakout, has a very definite list of requirements.

IMHO, you should always build an engine alongside a game, so that you know exactly which things you should build, and you'll be able to concretely compare different approaches to any problem, by actually testing your engine's features in practice, by building a game that uses them at the same time.

 

I'm also a strong believer in YAGNI, and I've found that if you write some particular feature months in advance, without actually having a need for it yet, then you won't do as good a job of it. With these kinds of game engine projects, the entire project violates YAGNI! I've found that with these kinds of engines, when you finally decide to use them to make a game, you realise that many features don't quite work the way you'd like them to (or are buggy, because they've never been properly tested), and you end up doing a lot of re-work.

 

Also, a game like Breakout doesn't need a very complex engine. If you go and create a really complex engine and then use it to create Breakout, then both your game and your engine will be over-engineered.

It would be best to keep your engine as simple as possible while making Breakout, or to make a more complex game with an existing engine, or, make your own very complex engine but also make a very complex tech-demo to go with it.

 

The best course also depends on what kind of programming you want to do.

A breakout-from-scratch project is a decent project to show that you're a competent programmer in general.

A game with lots of particle systems or post-processing effects might show that you've an affinity for graphics programming.

A game with enemies that take cover and flank the player might show you've an affinity for AI programming.

A game with a GUI level editor might show you've an affinity for tools programming.

A game with a professional data-compilation pipeline might show you've an affinity for engine/tools/build-automation programming.

A game with 10000 enemies on screen at once might show you've an affinity for engine optimisation.

etc...

 

2 - Depends on your country. You likely need to register a business number and do your taxes correctly. Speaking to an accountant would be recommended.

3 - Your English is perfectly fine smile.png




#5061636 Best way to pass material parameters to shaders

Posted by Hodgman on 13 May 2013 - 06:14 PM

I've worked with more than one engine, where in normal usage, the engine spent 25-50% of the main thread's time on setting individual uniform values... So, I much prefer using the simplest possible method, which yes, is blobs of bytes.

I think about uniforms in two types - ones that are set by the game/engine with different values over time, and ones that are set by artists when they create their material but do not change after.
For the first group, yes you have to standardize the layout. The shaders can be replaced/modified as long as people are aware of the layouts that have to used to receive engine-generated data.
For the second group, any layout at all can be used. I precompile material files into blobs of bytes at data-build time. If either a material or a shader is modified, you've just got to run the data compiler again.


#5061412 What's the true worth of an initial game idea?

Posted by Hodgman on 12 May 2013 - 09:21 PM

Now, if art is a craft then video games are art
If art is entertainment then video games are also art
If art is a journey to self awareness then video games are not art

When using the last definition, there is a big difference between "no game that I've yet played is art" and "games cannot be art".

 

Just as how most popular music is not at all art when using this definition while there is a smaller amount of music that does fit the definition, games are the same. Most popular games may just be entertainment in this definition (just like pop music is), but there are also a small collection of games out there that are capable of and designed with the express intention imparting a large emotional impact impact on the viewer that changes their way of thinking about themselves.




#5061407 SQL login security?

Posted by Hodgman on 12 May 2013 - 08:50 PM

Yeah, that limits the damage that a hacker can do, e.g. they won't be able to delete your whole database or add new tables ;)

 

However, depending on what you're using the database for, this probably still leaves the door wide open for cheating.




#5061402 SQL login security?

Posted by Hodgman on 12 May 2013 - 08:39 PM

Yes, the DB password can easily be extracted by a hacker with the client, which is why it's recommended to have the client communicate with a trusted server, who in turn connects to the DB.




#5061398 Baking Occlusion Maps

Posted by Hodgman on 12 May 2013 - 08:22 PM

Another idea -- at the moment you're doing 'for each position, trace 16 rays', you could instead use the algorithm from this ray-tracer, which is 'for each ray direction, trace rays through a million positions', which maps better to GPU rasterization hardware and might result in less overall passes of the scene.

Hodgman - Yea can't do it that way because of the cavities/indoor. Plus that doesn't really work well in outdoor forests either. If you have a few close boxes, but they are under a ton of tall trees, then it will get no direct lighting at all because leaves will cover every one of those depth buffers, so I have to start at the object and go out just like SSAO.

My very cheap hack to deal with that is to mostly place lights in the upper hemisphere, but also place some in the lower hemisphere, and to not render the ground into the depth buffer, so it doesn't cast shadows upwards onto objects. This allows objects that are covered by a 'canopy' to still receive some level of "AO" gradients.

 

Stealing inspiration from the above link, you could also solve this issue completely by rendering the shadow maps with depth-peeling, which allows you to measure the length of the ray from the surface position to the nearest occluder, rather than the "most outside" occluder.




#5061379 Baking Occlusion Maps

Posted by Hodgman on 12 May 2013 - 06:42 PM

I bake AO "inside out" (sky visibility) by positioning hundreds of directional lights outside the object, pointing in. Each light renders the object to a 512 depth buffer, and uses that to apply a small amount of light to a 1024 AO texure (by rendering the object in lightmap-UV space). This produces blurry results, and doesn't work for indoor areas / cavities, but only takes a few seconds on a GeForce7, so I'm able to do it for a whole level during the loading screen (where the GPU was idle anyway).


#5061246 polymorphism and inheriting from a base template class

Posted by Hodgman on 12 May 2013 - 04:38 AM

This is equivalent to:
class base_component { int foo; };
class spatial_component : public base_component { int bar, baz; };
std::map<int, spatial_component> spatial_system;
std::map<int, base_component>* base_system = reinterpret_cast<std::map<int, base_component>*>( &spatial_system );
And no, this code is not valid. There's nothing in the specification of std::map that says that you should be able to cast a map of type T1 to a map of type T2 and still have it function.

Consider one reason why this might not work -- imagine inside a container class (like std::map) if you were trying to allocate a storage area for 1000 components. If T=base_component or T=spatial_component, you'd allocate different amounts of memory:
void* storage1 = malloc( sizeof(base_component)*1000 );
void* storage2 = malloc( sizeof(spatial_component)*1000 );
When you cast the container to a different type of T, it no longer has the appropriately sized storage area.
Also, it no longer computes the correct offsets to each of the items inside this storage area:
base_component*    item42_1 = ((char*)storage1) + sizeof(base_component)*42;
spatial_component* item42_2 = ((char*)storage2) + sizeof(spatial_component)*42;
assert( item42_1 != item42_2 );//!!!



#5061231 What's the true worth of an initial game idea?

Posted by Hodgman on 12 May 2013 - 02:07 AM

Say, for instance, this "idea guy" was making an RPG, and in his GDD he has descriptions of every combat mechanic, formulas for every kind of calculation, tables of every item in the game (along with stats, descriptions, etc.), drop tables, blueprints of every map, the storyline progression, detail of each quest, and so on...

At that point, even if you don't have it in a computerized form, you've got yourself a tabletop RPG. You'd actually be able to play the game.
So at that point, it's not just "an idea for a game", it actually is a game, just not yet computerized and depicted with fancy graphics.


#5061202 What's the true worth of an initial game idea?

Posted by Hodgman on 11 May 2013 - 08:52 PM

There's a few issues being mixed up here, relating to the process by which a design changes over the development lifecycle.
1) Involvement of "non-design" staff.
2) Deviation from the original design.
 
Neither of these have anything to do with the premise of the thread -- which is the value of an initial idea, these tangents are about the way in which ideas are evolved.
 
To address the second one first, let's pretend for a moment that none of the other staff ever speak to the designer, and only implement his wishes.
 
Let's also say that the game project has a 3 month pre-production period, where the initial draft of the GDD is created and the project schedule/budget is decided upon, followed by 18 months of production. We'll also say that everyone is on $80k per anumn, that there is 1 designer and 2 dozen implementers.
The game designer's wages during pre-prodcution, where he's writing the initial GDD come to $20,000.
The game designer's wages during production, where he is revising the GDD and guiding the implementation come to $120,000.
From this we can see that the initial idea is not that valuable, and that most of the expense is in refining the original idea and guiding it's implementation.
The first rule of capitalism is, expenses wouldn't exist unless they are necessary. If the initial game design was the most valuable part, and didn't need to be refined, then businesses would save $120,000 by not keeping the designer around for the production phase of the project. In reality, the most important work done by the designer occurs in the production phase, and his pre-production work is not actually that important in the grand scheme of things.
This part is off-topic, but to put things in perspective, the cost of implementation is $1.44 million... if a good implementation wasn't important, then businesses would hire inexperienced staff for half the price and cut that down to half a mil... but doing so would compromise the value of the game, so they generally don't.
 
 
Going back to the first part -- you seem to think that because staff from other disciplines have any input into the process at all, then this means that the designer's vision has been compromised, or that the designer does not have the final say on every little thing. This is not true.
You can still have a dictatorial designer, controlling every little aspect of the game and making constant demands of the implementers  but the implementers would still have to have creative input.
Again: if the designer's work contains a complete specification of exactly how the computational game state should change from frame-to-frame, then the designer is actually writing code! The designer is not writing code, so there will necessarily be small holes that must be filled by an implementer, which takes creativity on their part to come up with the computations, variables and algorithms that best fit with the designer's vision. The way that these gaps are filled can be reviewed (i.e. played) by the designer as they are implemented, allowing him to now see his own design with more clarity and make even more specific requests (such as changes to the way these holes were filled - the algorithms and code can be explained to him, so he can further tweak them).
 
 
Going all the way back to the original premise, about the value of an initial design --
Let's compare game design with architecture for a moment. In architecture, the designer (architect) draws up plans for a house, hoping to create something aesthetically pleasingfunctional, structurally sound, and inexpensive. All of these goals can be evaluated during pre-production (before building the house). The designer can create drawings of the house, or model it inside a computer, so see exactly what the final product will be like. Once the blueprints are perfect, then production (construction) can begin, with few or no changes to the initial design.
 
Video game design cannot work this way.
 
A game designer draws up plans for a game, hoping to create something interactive that is fun, or something that delivers a certain experience.
You cannot write the design for Super Mario Bros. in a word document and then evaluate how fun it is or what the experience is like. To evaluate the design, you need to be able to play it.
For some certain categories of games, a pure designer can prototype parts of the game by himself -- e.g. implementing turn based combat mechanics using cardboard, scissors, pens, etc... -- but for many kinds of games, there is no way that the design can be prototyped outside of a computer.
 
Due to the fact that the designer cannot evaluate the merit of his designs, this makes his job very different from that of an architect, etc. A game designer literally has no way to design a perfect game in isolation in his initial draft. Great games have to evolve over the course of their development. As the first implementations of the game come into existence, the designer is finally granted the ability to evaluate his initial design and make changes to his design as necessary.
It's the inability to evaluate the success of an initial design that makes them nearly worthless. Before you can tell if a design is fun, it has to be implemented in some form (whether that's a tabletop prototype or a computer prototype). An initial design is just a sketch, a draft, and the real hard work done by a real game designer happens during implementation, not during the first draft.
 

You need artists and nerds to make video games
unfortunately neither artists nor nerds have the right personality for making entertaining video games ...

The people I've worked with in the industry are ridiculously diverse. They've come from Australia, New Zealand, Papua New Guinea, Malaysia, Japan, Taiwan, Hong Kong, Korea, Ireland, England, France, Sweden, Germany, Italy, The Netherlands, Russia, Poland, Iraq, India, Pakistan, Canada, USA, Brazil, Chile, and so many more I've forgotten. They've been trained as classical oil painters or self educated coders, destitute and homeless in foreign lands or married to fine wine reviewers, sneaker enthusiasts or mechanics, electricians or psychologists, they've fought in middle eastern wars or acted as UN peacekeepers, spoken four languages or just one, been reality TV cooks or even meth-amphetamine cooks, been shot and stabbed in bad cities or worldwide surfer dudes, operated bars/pubs or built missile guidance systems, been stuntmen for TV shows or pilots or teachers, and so on... but yeah, I guess they're all just boring nerds with the same bland personality rolleyes.gif


#5061040 What's the true worth of an initial game idea?

Posted by Hodgman on 11 May 2013 - 05:28 AM

But the fact remains that they usually don't touch the heart of the game and merely provide the framework and tools the game designer can work with.

No... Sorry to be blunt, but it's obvious that you've never actually worked with a large team of professional game developers, because that's not how things work out in the real world.

Even the best game designer can't sit down and design exactly how every single mechanic in the game will function from button input to frame-by-frame changes in the game state. There's an initial idea with some guideance for how it should be implemented, this is produced, and then refined over time. It usually will not exactly match the idea that the designer had in mind, and/or it will demonstrate why the designer's original idea is lacking and needs refinement. These refinements will be created both independently and collaboratively by everyone involved in that particular area, which will involve the game designers (there may be general ones, and specialists -- e.g. combat designers, level designers, mechanic designers, etc) the artists (e.g. environment, character animation, concept, etc) and the programmers (e.g. general engine/technology, general game mechanics, and specialists like animation programmers, etc). If someone on the team is just a passive tool to be used to implement specifications to the letter, then they belong at a finance company, not a games studio.


The people who are actually taking the designers ideas and bringing them to life through code and art have a huge amount of influence as to how they turn out. They will inject their own creativity in to the process, just as the game designer does. Often, many different variations on a game mechanic will be developed and tested, to try and find the most fun incarnation of the game idea. The game designer will not have thought up every single one of these variations.
 
One of the best examples of this would be enemy AI. If the designer can specify exactly how the AI will move from frame-to-frame, then they're actually an "AI programmer"! The designer will likely not be an AI programmer, and they will be giving descriptions in high level english, not working code. As the AI systems are developed, the gameplay programmers, the AI programmers, the animators, the environment artists, the combat designers, the game designers, and the level designers all have to cooperate and work together in order to find the fun. When you're not sure how the AI is going to turn out exactly beforehand (which you can't), you can't design the fun first, you have to find it, and all of these people are part of that search, inserting their own unique skill set into the process.

 

The best designers are the ones who can implement their own ideas and thus keep the feedback loop very tight.

Often, a gameplay programmer with some specialty -- e.g. third person movement controllers, or weapon animation controllers, or AI navigation and planning systems, or multi-character interaction systems -- will have a lot more creative insight into their particular speciality than the game designer does. When trying to implement a designer's abstract ideas, these programmers will internally have to iterate on their implementations many times, and many of the small nuances that separate a good mechanic from a great mechanic will be injected by these programmer's own creativity independently from the game designer's overall vision. In this sense, the guy working on the "third person movement controller" may be a programmer and a "movement designer" at the same time -- and the same goes for the animators; their creativity and skills may inject new possibilities into the implementation which were unimagined by the original designer, and they may reshape the game for the better. A good designer will be receptive of the inputs of all the creative people on the team, and not just dictate that everyone stick to the original GDD to the letter. In the real world, GDD's are evolving documents that change as the game changes.

Often the high-level game designer will deliberately be vague in areas that are not his speciality to allow other designers on the team enough freedom to make their contributions great, because the high level designer is not necessarily experienced at creating the nuances in every single minute aspect of the game.

 

And if the game designer is REALLY good at his job, they shouldn't meddle with his process besides telling him what limitations he's working with.

I have seen several times where several variations on a game mechanic have been developed, including one which was a to-the-letter implementations of the designers words, but the latter one not shipped. In many cases, the designer has stuck to his opinion of the original idea, thinking it was superior, while everyone in play-testing felt that one of the other variations was more fun.

This designer, being a particularly good one, possessed humility (an important trait) so he compromised his own vision in order to produce a game that everyone else found to be more fun, rather that one he felt to be pure to his original imagination of the final game.

I've also seen the reverse, where a designer used his connections with management to work in a dictatorial style, where he would make changes to the game as he saw fit, regardless of the creative input of others... and the game suffered for it. Games are made by dozens of different specialists, you'd be stupid not to be receptive of their feedback.

 

Collaboration is not "meddling"... Collaboration is how you work with a team. A designer who can't collaborate, because they accuse people of "meddling" is not one that people will be able to work with.






PARTNERS