Writer needs Coder

[Brigand]

  double post removal

[Brigand]

op:

Date Registered: September 14, 2014, 05:05:16 am
Last Active: September 14, 2014, 08:58:22 am

I think he long since fled. We may just be pissing in the wind.

[Krice]

The only cross pointers you get are actors targeting other actors. The first thing I do in the destructor is pass the 2 lists a single time, and set the pointers that refer to the dying object to null before the object goes out of scope - it takes literally 1 line of code in a do/while loop, and eliminates the need for a manager class as well as null pointer references.

I'm using a system where all 'actors' or game objects know which monsters are targetting them. When let's say an item is destroyed or picked up it's sending the message to all targetters that are in its list. That way monsters know something has happened. Maybe it's not a good idea to automagically remove the item from monster's target, rather change it to "last known location" or if the monster notices who picked up the item, then it's possibly going to attack the thief.

[koiwai]

It's Interesting and odd to read the comments about GM and compare them to the framework I've evolved for my own use. 
(...)

Interesting read. Yeah, it's great when a program can be nicely stratified, and all data stored in simple arrays and trees. The problem with games is that they just don't want to be nice and stratified. They are messy blobs of various interconnected things, and that is our task to put them together

Yes, different entites need to know about each other and refer to each other in some way. For example, I have regions and units. There can be a number of units at the same region. On the one hand, I want to be able to access all the units from the given region. On the other hand, each unit may need to know its current region to find where are the possible exits to the neighboring regions. Such interconnectedness arises very often. And if you avoid it, the code may degrade to a gigantic god-class or a god-function. So, we really need to connect them somehow.

What I do, is almost identical to what you describe. The game entities that need to know about each other are labeled with an ID, a simple integer. The IDs of the units are generated uniquely, so there is no possible collision. The regions have the IDs defined at the map generation stage. The units and the regions simply know each others' IDs, this is enough to link them. The objects themselves are stored in corresponding data structure, in arrays, hash tables, or maps (an O(log n) access binary tree). With a few intermediate abstraction layers, the game data is quite manageable this way. I thought about generalizing this approach somehow with a generic module, but I'm not there yet.

Actually I do have several semi-god modules that combine different things together, but I was always able to refactor and break such semi-gods apart when they were becoming too unwieldy.

[Bear]

I think that the data manager is a design pattern;  If you're doing complex crosslinked stuff with very diverse semantics, data managers make it easier to keep track.

OTOH, it's not clear that I'd need them if I were using Common Lisp for this project; CL's weak pointers provide most of what I want from them for memory management.

[koiwai]

I have never really tried CL or Scheme, but macros and quotations are what I would really like to have in my language. Though, Lisp is kind of bad for distributing the game. There are probably more options for Scheme, for exmaple Chicken Scheme that compiles to C. I don't know about weak pointer in CL, can you save a data structure with weak pointers to file, and load it back without breaking the pointers?

Btw, such data manager is not only an alternative to pointers or references. What it does, it names game objects, so it provides additional benefits.

A somewhat artificial example. A unit has the list of previous targets: [monster1, moster2, monster3]. If the elements of the list are names, you can compare, whether they were the same moster or not by comparing their names. Monster's name can be passed to another function that gives some meta information about the monster that might not be available directly from the moster itself, for example it can return the set of monster's neighbors or something like that.

[Bear]

Yeah... I didn't want to use something that would require people to install libraries and runtime crap on their machines, (and, inevitably, require me to answer their questions about installation and help them) or spend my effort on maintaining compatibility with moving targets.  Or figure out a least-common-denominator that works with runtimes and libraries that exist in many different versions on different machines. 

And when you've done that, you're really left with just compiled languages and system libraries, and that compiled with options that get pedantic about a particular standard of that language.