Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 18 Mar 2013
Offline Last Active Today, 05:55 PM

Posts I've Made

In Topic: Low level serialisation strategies

Today, 04:02 PM

I just finished writing an article on this exact topic - its currently pending approval - hopefully some of the members interested in this topic will participate in the peer review!

In Topic: Name this causal game

21 August 2016 - 04:25 PM

Dotty McDotface

In Topic: Modal GUI and ongoing events

21 August 2016 - 04:07 PM

It seems to me that the cursor icon system should be reacting to the event that triggers the modal popup as well - placing the correct icon and making sure the state is set correctly before the modal pops up

In Topic: Lua Scripting w/ generics

20 August 2016 - 08:39 PM

In c++ I use a register_component_type<T>(string guid) function which will hash the string id using a stanard/fast hash function and then store the string and type in fast access hash maps with the hashed string id as the key, although I keep another hashmap for the Type to hash id storage also.


Then - you can either have


GetComponent(int type) - the direct access one




     return GetComponent( type_to_hashid_map.find(typeof(T)) );



GetComponent(string guid)


    return GetComponent( fast_hash_func(guid) );



Where you use the hashed string id instead of the type within the dictionary. Given the type you can look up the hashed id (because you stored it using the register function) or given the string you can use the quick hash function you used to first hash the GUID.


Its also easy enough to write out the hashed string GUIDs to file so you can use them directly in your lua script - the hash function you use should always produce the same exact ID for any given string.


This is what I do in c++ - but seems like it would work fine.

In Topic: Handling multiple "levels" or "scenes" within a world

20 August 2016 - 08:03 PM

You've put out a few options for ways you might save them, and they each have their own pros and cons. They might work well with the engine and tools you are using, or they might not. Your description of the scene being little more than a list of entity ids is essentially how many games do it. When it is stored to disk there is often one set of data that contains the scene hierarchy as a collection of iDs, and another set of data that contains whatever was inside the ID. Such a system lets all the items get persisted and replaced with their IDs as they are being written out; it ensures that if an item is a clone with multiple instances in the hierarchy then the contents are only written out once.


There recently was another thread talking about "spaces" and I think this is where I was getting somewhat confused. I don't really use a specific engine - I have conglomerated a bunch of usage code for different libraries that I have used - OpenGL, OpenAL, libsndfile, assimp, glfw, glew, and stb_image - and recently I have been trying to gather it all together in to a sort of engine (oh and recently I've been working with getting the bullet lib working). I made some different systems for ui, sound, selection, rendering, animation, and applying hierarchy transforms - much of it written during this last game jam, but I'm really struggling with how to organize the world - because all though only a small subset of things are on screen at once, sometimes I need logic to be done on game objects elsewhere.


It seems that I have been using "scenes" as what was referred to as "spaces". I'm not really sure how to relate them to each-other, or what the difference is. I'm also confused about whether I should allow game objects to share components to have an instancing effect, or create some prefab object - this is more of an editor concern though - as I'd like to be able to have some behavior similar to Unity as it gets annoying to change each object.