Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - naughty

Pages: 1 [2] 3 4
Programming / Re: Brilliant Observations by My Brother
« on: May 31, 2013, 11:56:04 AM »
Yeah I was thinking classic Zelda style. Top down. Breaking it up room by room could work, like in the original, but not necessary.

One of the issues with trying to create something approximating a hand made level is that we don't really have a robust language and analytical framework to talk about level design. A lot of hand-made levels are made in an interactive process where people know when the level is good but not necessarily why it's good. Without a theory of level design it's impossible to really expect any procedural algorithm to be meet the standards of hand made levels.

For example there's been mention of dead-ends and loops in roguelike levels design. Mainly that dead-ends without a reason are boring and cause tedious backtracking. Loops are good because they give options for escape and exploration (and reduce the chance of dead-ends) but if you have too many of them it can also be a problem. If we could measure 'loopiness' we could control for it.

There are some interesting articles that do analyse games level design though which could be a start. Here is one for Zelda and here is one for Super Metroid.

Programming / Re: Brilliant Observations by My Brother
« on: May 29, 2013, 06:43:43 PM »

The problem with procedurally generated Zelda is that the level design, powerup placement, side quests, and puzzles are the best parts of Zelda games.  Those are all things that human being do much better than machines.

The question is really can we get close enough to handmade Zelda levels to make it worth the while. With tech like this and this it might not be a far fetched as you'd think. I am assuming a 2D Zelda game though, doing it in 3D is far harder.

Programming / Re: Brilliant Observations by My Brother
« on: May 29, 2013, 02:28:31 PM »
Robotron style controls with WASD for movement and mouse for aiming works really well on desktops (Mutant Storm was a good example), not so great on laptops though.

I'm not quite sure what would be bad about a procedurally generated Zelda game. Surely the careful progression and dungeons as a large puzzle is what you'd be trying to generate. i can see why someone would say the combat isn't great though, compared to Demon's/Dark Souls say.

Programming / Re: Modeling the game world- Sensory Systems
« on: April 25, 2013, 08:01:57 AM »
 but I think being able to easily implement misinformation is some interesting value for enemy AI.

This is the huge advantage of separating perceptions from what is perceived. For example when playing as a herbivorous dinosaur we could make poisonous plants be perceived as nutritious or not depending on how good the dinosaur's sense of smell was. It's tricky to show this to the player though, we used crude vertex based rim lighting to indicate how 'good' food was, red meant poisonous and yellow was good food.

Once you get to things like hallucinations for the player (when you eat dodgy plants) it's a lot more complex and we got it working but it wasn't very tidy.

The one idea we never properly tried (because we thought it would be too expensive and cause lots of issues) was to actually use the perceptions directly to render things. For example if you had bad vision you want objects to slowly come into focus, rough silhouettes first then more detail getting filled in. Rendering that was not a priority at the time and considered a very steep challenge.

Consider something that can only perceive movement (like the T-Rex in the Jurassic Park films) rendering that seemed like both a cool concept but also very tricky.

 There are some tricky things about it all to figure out, but weights and voting systems looks like the best way to go.

The only caveat I would mention is that it can get very complicated if you have a lot of different modules. We  needed to put in quite a bit of debugging visualisation and logging to properly track down bugs. However the overall system just feels so intuitive, at least for the kind of game we were working on.


However, will it make your game better or even be noticeably different than random actions? These are the two things that often kill the interestingness of such complex systems, so it's worth paying special attention to.

It's hard to answer this is a pure player for the game I worked on because I knew the code. However when you're a Velociraptor hunting down a herd of pigs you could feel that they were panicking and making mistakes. Being able to think in terms of a set of potentially conflicting and concurrently running instincts just made it a lot easier to get interesting behaviours out.

You could do this with 'simpler' systems like HFSMs or Behaviour Trees but you'd end up creating a lot of mixed or complicated states to cover for the lack of concurrency.

Programming / Re: Modeling the game world- Sensory Systems
« on: April 24, 2013, 08:08:04 AM »
This reminds me of an AI model called the Subsumption Architecture that a colleague used many moons ago on a unreleased game called Dino Hunter (shame it got canned, it was the best playing game I've ever worked on mainly due to how good the AI was).

The idea was originally put forward by an MIT AI researcher called Rodney Brooks. "Cambrian intelligence: The Early History of the New AI" is a good book he wrote on the subject.

Anyway the central idea is that most AI models put cognition into a big box between perceptions and actuators. What he proposed is to break the big box into modules which could use any of the gathered perceptual data and also give outputs to the actuators. The modules are totally separate from each other and in theory could be run in parallel.

The modules end up sounding like instincts, in Dino Hunter we had FightOrFlight, ObstacleAvoidance, Hunting and Flocking modules for example. All the modules have access to any perceptions they want to but also all the actuators. The modules actually voted on the actuators so for example the FightOrFlight module might be voting to run away from the T-Rex that's behind it, but the ObstacleAvoidance module votes to go around the tree you're about to run into. Normally you can just lerp between the actuator votes.

There was a hierarchy to the modules as well. FightOrFlight and ObstacleAvoidance were very high priority modules and could 'veto' or even temporarily shut off other modules. They represent very base instincts so it makes sense that they can do it.

Is it important to distinguish Sensory Systems from Sensations? I think so, as we may want to utilize this abstraction layer for varying effects.

This is what we had to do. The main prey in the game were pigs and deer (not very accurate for a Dinosaur game but we were in pre-prod, and squealing pigs are just too funny). We had blind, deaf and 'unable to smell' actors so we had to abstract what was perceived away from how it was perceived. We also had big dinosaurs that could eat the player.

Perceptions ended up being quite simple it was something like:

Code: [Select]
struct Perception {
    enum {
        PREY,  // Depending on whether you were a herbivore or carnivore this could be grass or another dinosaur.
        ALLY,  // The prey animals could flock so needed to know where their friends are or were.
    } type;
    Vec3 direction;  // In local space to the actor perceiving.
    Vec3 velocity;
    float distance; // This could be negative to indicate unknown distance.
    float value;  // This was a bit hacky but was used to represent relative threat or the nutritional value of food.

We had systems that processed all the sounds, lines of sight and something like an influence map for smells that would create these perceptions for the actors depending on their senses, e.g. deaf actors didn't get any perceptions from sounds.

We also had the concept of perceptions that could linger for a while, e.g. when a herd of pigs were eating they couldn't see each-other (they are looking at the ground) but remembered where the other were for a while.

Now I'm all nostalgic for what could have been, that game was great.

Programming / Re: pedantic object oriented question
« on: April 18, 2013, 09:55:18 AM »
That should just be a part of the System that works with those components.

I can understand that standpoint for examples that require mutation of state (and you're following the rule that only the corresponding system can mutate a particular component's state) but for objects that have involved immutable queries (e.g. a graph with a some complex breadth first based algorithm) you may as well just put the method on it.

I'm a little confused about this. There is nothing inherent about DOP that makes AoS to SoA problematic. I mean, the whole idea of thinking of an application as a database is to optimally organize your data- in some minor cases AoS can perform better, but there is nothing preventing you from organizing everything in an SoA manner.

Sorry I was being a bit vague. If you do an AoS to SoA change all clients need to have their code changed. Use a few inlined getters and they don't. This has stung me in the past when micro-optimising a particle system update. The most memory efficient structure wasn't a pure SoA, e.g.

Code: [Select]
struct Particle {
    vec3 position;
    float turbulence;
    float timer;
    float saturation;


struct SoAParticles {
    vec3 positions[NUM_PARTICLES];
    float turbulences[NUM_PARTICLES];
    float timers[NUM_PARTICLES];
    float saturations[NUM_PARTICLES];

// Cache-miss Optimised version.
struct OptSoAParticles {
    vec3 positions[NUM_PARTICLES];
    struct {
        float turbulence;
        float timer;
        float saturation;

The actual code was more complicated but it caused issues because other systems were reading some particle data. It would have been easy to hide the changes for most (read-only) clients if it had been hidden a bit.

A System is a state-less procedure that evaluates and modifies the game-state/Model. However, each System only works with an explicit subset of Components- or more specifically values within subsets of components. This means that your data should be organized by components or the data within components, not by entities. You can further invert the relationship between keys and data so that everything is "perfectly" SoA if you want. Or only what would perform better that way.

Are you using the form of component system where entities are purely a unique id and you have no struct/object? Also do you follow the each component can only be written to by one system? There's quite a bit of variation in these kind of details.

Putting an Attack() method on a controller just leaks the abstraction. If there's user input involved in should be handled in the LocalPlayerController or some such. Then again it's been a while since I was using UE2.5 so I could have got my wires crossed.

Programming / Re: pedantic object oriented question
« on: April 18, 2013, 07:57:04 AM »
Mmm. I already programmed a program with a more "traditional" entity "hierarchy" with different subtypes of entities (though I'm just beginning on it, so there isn't too much code for the entity system) instead of components. Should I toss it out and go for components?

Without knowing your exact circumstances it's hard to say. If it's a short term project then I wouldn't bother unless you really want to try to implement a component system to see what the fuss is about.

Throwing code away is also something I wouldn't encourage at all. It would be best to convert over in stages unless you're very close to the beginning.

I suppose the pros and cons are:

  • You'll be trying something new which can be fun.
  • If you're making a large or complex game there will be a benefit.
  • If you're curious about how component systems work, the best way is to try it.

  • Until you get a feel for how a component system works you will be less productive and probably a bit confused. This can kill motivation especially for hobby projects.
  • It's still possible to go wrong with component systems. One of the more well known game companies I worked at made an absolute mess of it.
  • The benefits of component systems are most felt in very complex games or games that are pushing the hardware to the limits. So if you have a simple enough game it could all seem a bit useless.

Programming / Re: pedantic object oriented question
« on: April 17, 2013, 11:17:33 AM »
So what's a modern, 2013 way of doing it?

There's two ways to parse that:

What's popular or considered  'best practice' in the games industry at the moment?

Component systems are all the rage and with good reason. There's quite a bit of variety in how they're
being implemented but the basic idea of having one type of 'entity' that can have multiple components
which define how it behaves. A rough analogy is that the programmer makes lego blocks and the designer
builds entities from them.

At the high-performance and AAA end of the industry you have 'double buffered' entities (a read-only public
version and a writeable, private version) to help get the most out of multi-core and the graphics hardware.
These designs are heavily concerned with performance issues and Data-Oriented Programming is a major buzzword.

At the MMO end of the industry component systems have been influenced by the need to interface with
Relational Databases (which are quite naturally 'component' based in a lot of ways).

At the indie/mobile end, Unity is component based (but not super strict about it) and is making a very
big impact.

It's worth noting that this isn't new at all. The first devs that actually publicised they were using a
component based system were probably Gas Powered Games who used it on Dungeon Siege (released 2002).
The company I worked for at the time had been experimenting with them around 2000 and quite a few
other companies had done it for a few years before that.

It's also not a panacea, I worked at a well known game studio that decided to use a component system
and they made a total hash of it. They had 100s of different types of components and singleton
manager objects for everything.

I'm leaving out a lot of details for brevity but the web is full of component system articles,
libraries, talks and slides. Some of them are just as dogmatic as the OOP guys used to be though.

What does this grumpy 'get off my OO lawn' programmer called naughty think is the modern way?

Component systems done well are a lot better in many ways than the inheritance hierarchy of entities
that was common in the 90s. For a small game it could be overkill though.

However you can arrive at roughly the same ideas from several angles. More emphasis on being data-driven
leads you to something like components. Performance concerns on modern hardware lead you to components.
Wariness or fear of inheritance leads you to components. Understanding all those OOP slogans and applying
them leads you to components.

Programming / Re: pedantic object oriented question
« on: April 17, 2013, 09:15:39 AM »
The OOP that the component and 'Data Oriented Programing' guys are attacking is over two decades old, it's just a shame it's what is still being taught to undergrads.

Please elucidate. I need schooling >_<.  A game is really just a database with a UI. Any OOP we do just feels like fluff. You can, of course, program DOP-style in OOP paradigm, but is it not just extra work? If it's all you know- sure, go for it- but are there any strict advantages?

The 'database with a UI' concept is great way of looking at it and a very fruitful perspective to take.
It's also a more 'OO' perspective than a hierachy of classes with draw(), attack() and move() methods.
MVC is pretty much the same idea but it has unfortunately collected loads of crud of the years that
hide the simple idea underlying it.

The early component systems were written by OO programmers trying to fix the problems with code bases
that massively abused inheritance. Inheritance was still used in some places like for controllers or as
a way to have different rendering backends but far less than in previous designs.

If you take the database analogy, OO is useful in maintaining constraints and invariants on the database. For example
you don't want an entity's health to get higher than the max health stat so instead of manipulating
health directly you use methods or functions to ensure that doesn't happen.

From the DOP standpoint (which is really a component system with a focus on low-level performance) you
can encapsulate the details of an AoS to SoA transform in a class or module. Clients of your class don't
even need to know you made the change. Also the basic tutorials on DOP don't show the full picture on the
SoA situation. You really want to align the values in the arrays so that all cache misses happen at the same
time. This very fiddly work but causes far less issues if hidden behind an interface.

I'm not sure why Attack() should be a method on the Controller, do you have a link to who would have said that?

It's pretty standard nomenclature. Controller.Verb() queues a call to Actor.doVerb(). That's how Unreal does it anyway.

Unreal is a nice enough engine with great tools but it's full of 90s throwback ideas. The controller should be calling Attack(), not having Attack() called on it. This is all IMHO of course.

Programming / Re: pedantic object oriented question
« on: April 16, 2013, 08:23:48 AM »
requerent: to be honest the games companies (I'm looking at you Epic) that have the complicated hierarchies for their entities are stuck with mid-90s ideas of how to use OO and design game engines.

While I like component systems I wouldn't go as far as to make all components methodless structs. Then again I was first exposed to a design similar to modern day component systems many years ago by a Smalltalk coder who considered it a good OO design and I agree.

The OOP that the component and 'Data Oriented Programing' guys are attacking is over two decades old, it's just a shame it's what is still being taught to undergrads.

ekolis MVC is a minefield, there are so many subtle variants and architecture astronauts that have muddied the waters over the years. The irony is that is was created by Smalltalk coders to handle GUI apps but they hardly use it any more, they use libraries based on Morphic written for the Self language which is quite radically different.

The original idea was to separate rendering code (the View) from the application's 'database' (the Model or the game-state as requerent mentioned above). The Controller is the main point of contention that causes so many different variants of the pattern to exist (MVP, MVVM and so on).

From a game programming PoV the Controller is worth abstracting out because entities can be 'controlled' by multiple things, a player with an input device, an AI, a networked player or AI on another machine or even totally scripted in a cut-scene. If they all use the same interface to change the Model your life is a lot simpler. If they all have a similar interface themselves, they can be interchanged freely. Component systems achieve the same results by slightly different means.

The guideline (that has become dogma) that controllers should be the only place where new model objects are created is due to the intuition that the input to the system as a whole comes through the Controllers. For some MVC designs this is fine but for others it is pointless or counter-productive.

I'm not sure why Attack() should be a method on the Controller, do you have a link to who would have said that?

Programming / Re: pedantic object oriented question
« on: April 15, 2013, 09:50:55 PM »
Aye I've seen that in Quake3 (much cleaner in concept than implementation) and pretty much all games written in functional languages. Must admit it is a lot nicer to do the networking for that kind of structure.

Programming / Re: pedantic object oriented question
« on: April 15, 2013, 07:52:24 AM »
requerent: by game-state do you mean something roughly like the 'model' in something like MVC? For example:

Code: [Select]
struct GameState {
    Entity entities[...];
    Terrain cells[...][...];
    Gas gasLayer[...][...]; // For area of effect spells or gases like in Brogue.

Programming / Re: pedantic object oriented question
« on: April 14, 2013, 09:20:46 PM »

First off why do you need lots of different pre and post steps for movement? ...

Sorry I kind of stopped taking it seriously there, questions such as these raise major red flags for me. This is why I never ask python questions on stack overflow. The whole "why would anyone ever want to...?" thing is just anathema to making positive progress, imho. No offence dude, the rest of your post contained good engineering points.

Looking back over the post that sentence does seem more abrasive than I'd like in hindsight. It would be wrong to back and edit it but if I could I'd probably write something like "What kind of things are you doing in the pre and post operations?"

I am genuinely interested in the possible use-cases of lots of different pre and post operations to movement though. It's  possible that it could be something not covered by the text succeeding the offending sentence.

Programming / Re: pedantic object oriented question
« on: April 13, 2013, 10:23:07 PM »
A components system does the same work here as a virtual move method on the thing, the point is you specialize the behavior on the thing and not in the map's move function.

No one's saying you should specialise in the map move method based on critter type. The point is that there's either only one move method on the critter or it would most likely be abstracted out and therefore not be 'in' the critter.

You're going to need a move method on the map anyway (unless the critter is allowed to access private state of the map) and the critters (or one of it components or otherwise associated objects) will end up having to call it.

Programming / Re: pedantic object oriented question
« on: April 13, 2013, 09:25:55 PM »
I have entities with move as a member function, and it basically delegates to the map to do the physical moving, but then the entity can override the virtual move function to do something before or after the move, while if you have a monolithic move function for the map, handling pre-post ops on a type by type basis gets nuts.

I don't think having 'move' owned by the map is wrong per se but I think you can make a stronger argument for something like eclectocrat's design here.

The sky won't fall down whichever way you do it, unless the codebase or the game gets a lot more complicated.

First off why do you need lots of different pre and post steps for movement? I would be quite worried if that happened because it means you derive a new critter class just to get a new kind of movement. If your game does have a lot of very different forms of movement you should be abstracting that out of the critter anyway, e.g. into a hierarchy of movement objects. (I'm assuming that like in most games critters are not uniquely determined by their style of movement.)

If you don't factor it out and you have another method/behaviour on the critter that can vary, an attack() method say, then you could be for a right pain in arse. You only need 3 types of movement and 3 types of attack to lead to 9 different classes you could have to write. Of course you could make a faustian pact and use multiple inheritance but possibly reduce the amount of code you write at the cost of you sanity.

It would be easier to factor both movement and attacking out into their own objects or hierarchies (thereby turning a N*M problem into an N+M problem). This also has the nice side effect of being far easier to make data driven (so new critter types can be added without writing code).

The oft quoted slogan of 'favour composition over inheritance' essentially means that the ideal number of critter classes is one. It's also motivated by very similar arguments to those presented above.

So if you have a small numbers of methods/verbs you won't really feel the pain but I've worked on RTSs where the number of combinations got quite large and the 'critter move' solution writ large led to loads of issues. Once we changed to the compositional system (and put 'move in the map') for the subsequent game it all went a lot more smoothly.

Pages: 1 [2] 3 4