Share a draft: Data flow in a property centric game engine

[Fredrik Alströmer]

I had a miserable failure of a draft up for review earlier this year.
I decided throw that one away, and rewrite it with only the parts on
data exchange.

I abandoned all attempts to include arbitrary and weird code snippets,
and tried to keep the size down, so I'm hoping it might be a bit more
digestible.

http://www.altdev.co/?p=30894&shareadraft=baba30894_5363bf028ef2d

Any feedback would be appreciated, even if just to say it's still a
piece of ****. (it's funny how censoring a word can make sound a lot
worse to the reader than originally intended,
http://youtu.be/B-Wd-Q3F8KM for those who don't know The Count,
technically probably SFW)

So, thanks, and don't pull those punches :) oh, and I'm also on
twitter @falstro now. Yeah, I'm a late bloomer.
Fredrik

[Timo Heinäpurola]

Hi,

I'm also working on a custom engine with a similar design on my free time. What I was wondering (or if I missed it in the article) is how you go around issues concerning the order of updating the different properties? If you have one object referencing another object through a certain property, do you sort updating so that the dependee gets updated first? I would like you discussing that a bit.

All in all it's a pretty good post and easy to read. The first paragraph in "Semi-standardized memory blocks" and the second one in "Wiring it up" are a bit heavy though. I liked the analogy with the fruit salad :)

-Timo

[Adam Martin]

I tried to read it, but that version of the site is still blocking iPhones (it outputs a special webpage that prevents phones from reading it).

I suggest sending links from the old site, until the new one is fixed.

...or is the old site now gone?

--
You received this message because you are subscribed to the Google Groups "AltDevAuthors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to altdevauthor...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Fredrik Alströmer]

Hi Timo,

thanks for the feedback!

I have a solution to the ordering, which in theory should work pretty
well (it should also allow running concurrent updates of all property
types by stepping through the dependency 'layers', which is nice), but
I haven't gotten around to actually implementing it. Should I include
it anyway like a 'future work' kind of section? Right now I have
simply ordered the updates in the order they have dependencies and I
don't have any loops (which can't wait a frame) so that's sufficient,
but I can see it becoming a problem down the road.

Ill see if I can massage the two paragraphs you mentioned to be a
little lighter.

Regarding the fruit-salad, that's a separate question if anyone wants
to chime in; they're borrowed from this Swiss guy and his
"clean-up"-fetish. (http://www.kunstaufraeumen.ch CAUTION: incredibly
obnoxious website) I imagine it could be turn into a copyright issue.
Would you suggest I just recreate the images myself?

Thanks,
Fredrik.

[Fredrik Alströmer]

Hi Adam,

sorry about that, I've copied it over to the old site:

http://www.altdevblogaday.com/?p=30881&shareadraft=baba30881_5364bc2fb36ce

Thanks for taking the time!

[Adam Martin]

Thanks!

I understood the post, but it felt I was working very hard. Two reasons I think:

 1. You frequently write over-long sentences. I saw two examples that were more than FOUR LINES of text, in a single sentence. Works in some languages, but in English this is very difficult to parse.

 2. Core concepts and observations are often embedded in the middle of blocks of text. Since they're not "called out", it's easy to miss them, and hard to find them again afterwards when re-reading.

If you had lots of time, I'd suggest re-writing it a few times, iteratively improving on that. But that can take a long time (at least, it takes me a long time :)).

But ... I think 90% of the benefit could come from a small addition: bullet-point summaries of your key points. Preferably: mini summaries 20% through, 40% through, etc.

Either way, I'd break-up the most extreme of the mega-sentences. Mega sentences are too difficult to read :(.

A few examples of the sentences I struggled with:

"read or write directly the data directly" -- too direct ;)

"that the can be no" -- typo: that THERE can

"what it lacks in flexibility, it makes up for in a lack of complexity" -- too many lacks. Perhaps: "lacks in ... makes up for in simplicity" ?

"not entirely unlike" -- could say simply "like" ?

"We still need to know the ‘interface’ or data layout of the other component, but – if the data types are compatible – only during the wiring phase, which a higher level component is responsible for, and either manager of the two properties can remain completely oblivious." -- 4 lines for one sentence :(. Break it into multiple sentences and make it clearer which parts are separate concepts. If it's all one concept, you could start with a 1-sentence summary, and follow it with multiple sentences to flesh it out.

[Fredrik Alströmer]

Hi Adam,

thank you for your feedback! I've inlined some Q&A below :)

On Sat, May 3, 2014 at 12:36 PM, Adam Martin <adam.m....@gmail.com> wrote:
> I understood the post, but it felt I was working very hard. Two reasons I
> think:
>
> 1. You frequently write over-long sentences. I saw two examples that were
> more than FOUR LINES of text, in a single sentence. Works in some languages,
> but in English this is very difficult to parse.

I know, I tend to do that. :) Had a teacher in junior high who kept
telling me my sentences were to short and my paragraphs didn't have
enough sentences in them. I think it damaged me for all eternity. :)
I'll see if I can shorten things down a bit. To this day, single
sentence paragraphs stick out like sore thumb in everything I read. ;)

> 2. Core concepts and observations are often embedded in the middle of
> blocks of text. Since they're not "called out", it's easy to miss them, and
> hard to find them again afterwards when re-reading.

Hmm, you're right, I'll have a look.

> If you had lots of time, I'd suggest re-writing it a few times, iteratively
> improving on that. But that can take a long time (at least, it takes me a
> long time :)).

Yup. I write slowly. Writing this one took 1.5 days, and that's after
I had already organized a list of keywords. Can be very frustrating
when you put in all that time and you end up scrapping the entire
thing. But it's good, practice makes perfect.

> But ... I think 90% of the benefit could come from a small addition:
> bullet-point summaries of your key points. Preferably: mini summaries 20%
> through, 40% through, etc.

I'm not sure exactly how to make this work. I'll have to think about it.

> Either way, I'd break-up the most extreme of the mega-sentences. Mega
> sentences are too difficult to read :(.
>
> A few examples of the sentences I struggled with:
>
> "read or write directly the data directly" -- too direct ;)

Oops. Fixed. That's me rewriting sentences and leaving words where
they don't belong. :)

> "that the can be no" -- typo: that THERE can

Fixed. Thanks.

> "what it lacks in flexibility, it makes up for in a lack of complexity" --
> too many lacks. Perhaps: "lacks in ... makes up for in simplicity" ?

I had that originally, but I feel that "simplicity" sometimes has the
connotation that it's easy to use and I wanted to focus on systemic
complexity (or lack thereof). Is there any way I can convey this
properly?

> "not entirely unlike" -- could say simply "like" ?

Yeah, sorry. I tend to sneak in references to weird geeky stuff
sometimes. :) Replaced it with "quite similar to".

> "We still need to know the ‘interface’ or data layout of the other
> component, but – if the data types are compatible – only during the wiring
> phase, which a higher level component is responsible for, and either manager
> of the two properties can remain completely oblivious." -- 4 lines for one
> sentence :(. Break it into multiple sentences and make it clearer which
> parts are separate concepts. If it's all one concept, you could start with a
> 1-sentence summary, and follow it with multiple sentences to flesh it out.

I suppose that depends on the width of your screen, on mine it's three
lines. But yeah, if you notice, it's a single sentence paragraph, so
my initial urge was actually to tack it onto the end of the last one.
:) Breaking it into multiple sentences solves both problems.

Thanks again for the suggestions, I'll do my best to implement them.

[Joseph Simons]

For the use of the fruit salad images, I imagine it likely isn't a big deal in terms of copyright, since we not exactly making big money off this or anything (I think in the US, fair use laws allow using images for the purpose of teaching). However, it would probably be good to acknowledge where the images came from at least. In my first post, I took an image that a photographer posted online, and made it so that when you clicked on it you went to the website where I originally got it. Not sure if that is the best way to do it, but it is how I handled it.

-Joseph-

[Joseph Simons]

Some more specific corrections that I didn't see called out yet (this is from the altdev.co site draft):

- "wielding a broadswords" -> 'wielding a broadsword' or 'wielding broadswords'
- "Basically, what the player sees is this" -> Might want to put a ':' at the end of this, otherwise it just looks unfinished.
- "you're a adman with affinity" -> 'you're a madman with an affinity' or 'you're an adman with an affinity' or 'you're an ad-man with an affinity' (adman is technically a word, but for some reason it just looks wrong when it isn't hyphenated, but that might just be because I don't have any experience in advertising)
- "which of the properties its managing" -> 'which of the properties it's managing' (changes 'its' to 'it's' if it is hard to notice)

Have to agree with Adam. I am typically a fan of longer sentences and don't like the look of single-sentence paragraphs as well, but even I think some of the longer ones could use some breaking up.

I think it might be useful to have a diagram showing how things fit together in your section describing "Wiring it up." You mention that you have an image in your head, it would be good to try and convey that to the reader.

-Joseph-

[Fredrik Alströmer]

Hi Joseph,

thanks for the feedback! Yeah, I'm updating the altdev.co draft, as
that one has a lot shorter response time (at least for me)

I've fixed the typos. I had to lookup 'adman' too to make sure it was
a word, don't know where I've seen it before. I'll use the hyphenated
version instead.

I'll see if I can whip up a diagram to go along with that without
getting too technical about it.

Regarding the images, they're from someone's blog (not related to the
guy) which turned up during a Google image search. The official site
does not have those images, at least not in a usable size that I can
find, which is why I'm a bit uncomfortable with it.

Thanks again,
Fredrik.

[Yggy King]

Hi Fredrik,

Thanks for the article, to me it reads well, though I think you have already made changes based on earlier feedback, perhaps that's partly why.

You mention the word "component" once, but never talk about the similarities and differences between your property-based approach and a component-based approach. It sounds like the main difference is perhaps that you slice and dice things to an even finer level than a component system typically would. This leaves me with a couple of questions though -- if a certain property is just an f3 (three floats) then what does it mean to "manage" it? It doesn't seem to have enough semantic content to be processed in a meaningful way. Maybe what I'm really asking is "where did the game logic go? is it all in the managers?" With those questions in mind, I think an example would be very helpful -- perhaps you could expand on those broadsword-wielding monsters and explain how their data would be represented in your system, and how / when they would decide to swing those swords.

Towards the end, I would replace "So should I've built my own engine?" with "So should I have built my own engine?" -- the contraction reads awkwardly.

cheers,

Yggy