psy (27Aug2006): Zola posted a rather large list of questions regarding Yake's design and code. I pasted it into the Wiki as it's easier for me to add answers. The forum thread is still useful for detailed discussion.

I will add answers to this page as I go.

psy (27Aug2006): Zola, it's a pleasure to know that you spend your energy not just going through Yake's code and design but that you compiled and published your thoughts and questions. This is very important to me and other Yake developers! And the first signs of changes due to your feedback are already in SVN HEAD (0.6.0-dev). :)

It's here: Questions and Thoughts

Hello,

I've been reading Yake's code, and I have a few questions. I may call into question some of Yake's design, but doing so helps me to understand how to use Yake and why things are the way they've come to be today. I refer to parts by their files as there's some naming confusion.

To start:

1) Since Yake has a relatively complex hierarchy of subdirectories and components, why the separation of /yake/yake and /yake/src? While working my way through the code and examining parts, this made it cumbersome to delve. I had at all times to keep two locations open and synchronously browsing corresponding parts of /yake/yake and /yake/src. This kind of split seems good for a simpler layout. But for yake, there's a big divide between the two sides– corresponding trees must be maintained.

• psy (27Aug2006): I know the pain of having to navigate two trees. OTOH, I want to clearly seperate headers and implementation. boost's organization seems to be similar (which in itself isn't a great reason but shows that it's clearly possible to manage). I'm all open for alternatives! Name them. :)

2) What conventions exactly, in plain terms, should the pch, prerequisites, and yakeComponentname.h adhere to? Which includes, defines, or otherwise should specifically be in which files? I've seen different parts of Yake doing very different things with these files.

• psy (27Aug2006): pch stands for pre-compiled header and is used with MSVC to speed up the compilation process in most cases. I agree that a unified naming scheme is beneficial for understanding and that it could be improved in Yake. Patches welcome. ;) In most cases it works like this:
  • pch in name: precompiled header related
  • yake/<component>/<component>.h or yake/<component>/yake<Component>.h is the main include for a component and mostly includes all other necessary header files of the component (e.g. include “graphics/yakeGraphics.h” for using all the features for the “graphics” component)

3) Overall, file naming needs cleanup. Taking example from point 2), Some are named pch.h, some yakePCH.h, some prerequisites.h, some yakePrerequisites.h, and some hand over to common.h.

• psy (27Aug2006): Agreed. A cleanup would be beneficial. Takers?

4) Why reimplement yake/base/math/yakeMersenneTwister, instead of relying on boost::random? Boost is already a dependency for yake, and provides mersenne twister based random numbers.

• psy (27Aug2006): Historic reasons. Changed to boost in SVN (0.6.0-dev).

5) Why is yake/base/math/yakeAsmMath needed, and when would this be beneficial? When can't we trust our compiler's implementation?

• psy (27Aug2006): Of course, we trust in our compiler. Mostly. Most of the functions are provided for convenience only. A few are actually used. It may be a good idea to remove the unused ones in order to make Yake leaner and reduce the code base that has to be maintained.

6) What was yake/base/yakeCommandInterface intended for? It's used nowhere.

• psy (27Aug2006): It was intended to be a generic interface for querying and posting commands through certain abstract interfaces (besides other use cases).

7) yake/base/yakeString: why not boost::string_algo?

• psy (27Aug2006): Feel free to use it. I want a common interface for certain non-time-critical simple tasks where I can swap out implementations if necessary.

8) yake/base/templates/yakeNiftyContainer is used nowhere in the sourcetree; yake/base/templates/yakeFunctor is commented out and replaced by boost::function. When will the gunk be cleaned?

• psy (27Aug2006): I wasn't aware of the gunk. Cleaned it up.

9) What is the purpose of the STL wrappers in yake/base/templates? Ie, yakeDeque and yakeVector. There's so many things like this which make Yake larger and less simple, but don't seem to add much. It seems to be suffering from kitchen-sink syndrome. Something like yakeFastMap is understandable, but something like yakePointer's abstraction on top of boost::shared_ptr is not. Why make Yake even more complex with all this?

• psy (27Aug2006): I should provide a bit of historic information:
  • In the beginning of Yake, boost wasn't an essential dependency. It was just one of two optional providers for functors, signals and variants. That was mainly due to my wish for a balance between using as few dependencies as possible to get away with and at the same avoiding reinventing too many wheels. Now boost is a required dependency and I would do quite a few things differently.
  • yakeDeque and yakeVector exist to be able to swap out implementations if necessary. Nowadays I would do this on a case-by-case basis, anyway, and just directly use the STL containers. Mainly because there are probably a few guarantees that yakeDeque and yakeVector do not deliver when compared to the underlying STL containers.

10) yake/base/yakeSignal's signal abstraction does not appear to be used in a number of places throughout Yake. yake/ent/object for instance, explicitly does typedef boost::signal<…

• psy (27Aug2006): Some of the code has been created outside of Yake and was later incorporated into the code base. Cleaned them up.

11) Why has the registry been created, as opposed to using a more traditional OO approach of ie, ISomethingInterface* = new ISpecificSomethingInterface?

• psy (11Sep2006): Please elaborate. The interface specific registries are used to register one or more implementations which can be selected and/or swapped out at runtime. Other approaches are used in Yake, too (e.g. OdeWorld).

12) Why not use the reflection system's createInstance instead of the registry? It can instantiate types by name.

• psy (27Aug2006): The reflection system is ready to be used yet.

13) What does yake/base/templates/yakeManager do? Is this a refinement of some pattern?

14) yakeManager seems to be some of the worst code in Yake. I think I read this code three times and couldn't figure out what the author was even intending to do. So what's it do? The policies are jumbled up. Why would a vector policy even be there if there's no getObject or getIdentifiers for it?

• psy (11Sep2006): 'Cause it hasn't been completed yet.

15) yake/base's components are spread out over various namespaces. Some are in namespace yake (ie, yake/base/yakeTaggedListenerManager), while others are in yake::base. Also, what is the distinction between yake::base::templates and yake::templates, as used in ie, yake::templates::create<>? This all needs to get standardized.

• psy (27Aug2006): Agreed. yake::base::templates will be replaced with yake::templates.

16) How are the ListenerManagers supposed to interact with the rest of the system, and how to best make use of them?

• psy (27Aug2006): It's a simple way to provide listener management to classes. They are not necessarily intended to be interconnected with other systems.

17) Regarding yake/base/yakeCriticalSection, yake/base/yakeLock, and the accompanying files in yake/base/native, boost::thread already abstracts this by implementing Mutexes with Critical Sections when on Windows. I can't really tell if Yake is using boost::thread or not, but if it so, all the CriticalSection stuff is unneeded.

• psy (27Aug2006): I recapitulate what I said before: In the beginning, boost wasn't a dependency. There'll be a different type of thread abstraction. I have it working in a prototype.

18) How does one decide whether to use yake/base/yakeLog or yake/base/templates/yakeSmartAssert's debug messages? They both do much of the same thing. The distinction between these two is a bit blurry.

• psy (27Aug2006): They are not doing the same thing.
  • Smart assertions are used to assert conditions and react in certain ways when the assertions are not met. One of the possible reactions (and the default one) is to log details about the failed assertion.
  • YAKE_LOG etc is used to log any information, warning or error you like. It is used by the smart assertion's default handler. That's all.
• Zola (08Sept2006): I did check the default handler in src/base/templates/yakeSmartAssert.cpp, but it doesn't seem to use YAKE_LOG at all.

19) yake/base/prerequisites needs STLport support fixed up. Various of the platform includes have stlport checks commented out, and HashMap explicitly #defined to use libstdc++'s __gnu_cxx::hash_map.

• psy (27Aug2006): That's right. Recently, since more and more people are using MSVC8 there's less and less need for support for STLport, IMHO. At least, that's what experience shows as you're the first to complain about STLport support for quite some time. :) As long as not more people shout for STLport support, I rely on developers to supply patches if they really need it.
• Zola (08Sept2006): The reason I queried about STLport is that Ogre's Dagon and upwards now require STLport for mingw32 compiles, and can't work with libstdc++ anymore. It's covered here: http://www.ogre3d.org/wiki/index.php/CodeBlocks_MingW_STLPort

20) There seems to be a bit of overlap and duplication in the yake/base/mpl section. For example, why define yakeSelect instead of using mpl::if_c? And half the files are duplicated, ie both yakeInheritLinear.h and inheritlinear.h exist.

21) Why is yake/base/mpl/yakeCast in the MPL section? This goes hand-in-hand with safe_delete, which is in yake/base/templates.

22) What is this very strange split/join stuff in yake/base/mpl/yakeCast? What is it doing?

• psy(28Aug2006): Remnants from an earlier time. Removed. It was used to split and join strings using delimiters.

23) What is yake/base/mpl/yakeCast's getBasePointer for? It has a funky implementation.

• psy(28Aug2006): As 22) it has been removed.

24) yake/base/mpl/yakeAbstractFactory: An abstract factory may require MPL, but it is not MPL. MPL is for the most part compile-time metafunctions and containers; an abstract factory is higher-level, and seems it should simply be a part of base.

• psy(28Aug2006): I agree and it should be moved for clarity's sake. OTOH, I'll see when I find the time. ;)

25) The decision to keep Ogre loosely coupled seems dubious. I can clearly understand writing a layer which “tells Yake how to use make use of Ogre,” but see trouble in asking the user to “Do certain Ogre things through Yake's interface, but other Ogre things directly with Ogre.” Invariably we'll be juggling between using the Yake interface and using Ogre's interface. We immediately run into the problem of converting Yake Vector3s to Ogre Vector3s. Ogre is huge and trying to come up with an intersection for commonality between Ogre and potential future renderers seems impossible or at best heroic but hopeless. It makes sense of course to use Yake's API for composite abstraction of Ogre parts, ie the Model or loader systems which can in turn use Yake's Ogre layer. But there's a lot of potential here for future features in Yake which would rely on Ogre. Worrying over Ogre's coupling might keep a lot of these features from ever materializing. At the surface, Yake's application framework could provide nice ways of accessing Ogre's base objects.

• psy (27Aug2006): What features would that be?
  • Abstraction is essential. In what way we achieve that can be discussed.
  • There are alternative ways of implementing abstraction. I decided against using one of those when starting Yake. Today I tend to compile-time approaches but are not yet decided. We've discussed this (and the possible approaches) more than once on the forum.
  • I implemented at least one prototype using compile-time specialization for a renderer. This makes it easy to implement and use certain algorithms but has one major drawback: It makes OGRE a direct compile-time dependency for any code using the graphics interface.
  • Furthermore, it makes dependent libraries and the binding code more complex as that has to be templated, too! (model, modelLua, ent, entLua, vehicle etc)
  • Ideas?

• psy (11Sep2006): yake/reflection is incomplete and not yet ready for public consumption. It is not used by any other released yake components.

26) At the library-user level, what kinds of things might we use reflection for besides as a unified means to serialization, script binding, network replication, and GUI construction?

27) Why are hardly any parts of Yake itself using the reflection system's basic provisions such as the CLASS macro?

28) What's the difference in roles between reflection's 'Class' and 'Object'?

29) What is a reflection “event”?

30) In yake/reflection/class, why did you choose to use std::list's for storing members?

31) Why does each Class object have both a PropertyList and a _PropertyMap? Why not just iterate over the map?

32) How about templated conversion operators in things like Field, so that we don't need to use get<>?

33) Having to explicitly provide the type at compile time when get<>ing a value out of a Field is a problem. It should have a memberfunction which can construct and return a boost::any.

34) Why were the register structs needed, such as 'struct register_field' instead of static functions?

35) Why do the getType's, ie in yake/reflection/field's 'const char *getType() const' return strings instead of type_info? I'm guessing that it's because type_info elides reference types. If this is the concern, a getTypeInfo() should be provided as well.

36) yake/base/yakePrerequisites has a #define YAKE_DECLARE_CLASS(name) static const char* yake_private_currentClass() { return #name; }. This is used throughout Yake, but yake_private_currentClass() is never actually accessed by anything. It overlaps with reflection's Class::getName(). Why not unify here on the reflection system?

37) Why does yake/reflection/bind_serialization use boost::serialization at all? A big part of boost's serialization library is the setting up of a way to define the members which need to be serialized, without the presence of reflection in C++. It seems that custom serialization should be trivial when reflection is present, and shouldn't require boost's serialization library. Serialization is a different beast when reflection is present, and boost::serialization mostly solves a problem which Yake circumvents entirely.

38) The reflection examples are using obsolete versions of reflection; RXO_DECLARE, etc. Even the main.cpp in yake/src/reflection really doesn't show you how to simply use the reflection. It starts off with properties but gives you no base understanding of how to query the members in a class. What is needed is a single file which builds upon each prior example, showing each base feature of reflection.

39) What is the relationship between yake/prop and yake/reflection/property?

• psy (11Sep2006): There is no relationship. Both libraries have been implemented at different times with slightly different intentions. The reflection library isn't ready for wide-spread use at the moment.

40) I see that reflection properties are compile time, while yake/prop properties are purely runtime. Perhaps 'prop' should be renamed.

• psy (11Sep2006): Into what? Besides, it would be possible to provide a hybrid approach . This may be implemented if we run into performance problems or need more compile-time logic.

41) yake/base/templates/yakeProperties: If this has been completely deprecated, nuke it out.

• psy (11Sep2006): Not in the stable release. Deprecated code will usually be removed for the next release.

42) yake/prop is using RttiClass so that it can keep a class registry for property inheritance. Why not use the reflection system's Class hierarchy? yake/prop/class_rtti's DECL_CLASS_RTTI seems to directly overlap with yake's reflection.

• psy (11Sep2006): See answers regarding reflection above.

43) Why is only yake/prop using RttiClass, and only yake/ent using yake/prop?

• psy (11Sep2006): Please elaborate.

44) yake/prop/prop_holder's PropHolder is template-parametized by the class which contains it; 'template<typename T> struct PropHolder' .. but T is unneeded– Why is it this way?

45) PropHolder overlaps with yake/base/yakeParamHolder. Why not a central implementation of this concept that's both lightweight and generic enough to work for both?

• psy (11Sep2006): Agreed. This would be the correct way to do it. To give an explanation: Some components (like prop, objectid, ent and others) are the result of externally created prototypes. Sometimes this creates a certain amount of overlap which has to be removed when (or after) integrating it into Yake.

46) Properties in the sense of yake/prop seem to be the idea of runtime variable groups. The property_tree library was recently accepted into boost. It provides a generic tree of properties with modular serialization support. The property_tree can be read/written from XML or any number of formats, and you can subclass to provide your own. This does everything that tinyXML does, but without being tied down to a specific fileformat. yake/prop/prop_holder does not seem general enough. I see the need for a single standardized container which can store trees of property objects or other kinds of data, and is serializable for network transmission or file loading & saving. Such a property tree system can do the job of yake/prop, replace yake::ParamHolder, represent the hierarchies for yake/loader, and is also useful to library-users for storing game data.

• psy (11Sep2006): I was thinking about introducing a similar thing to Yake. Up to now it existed only on paper, though. If property_tree is a viable alternative we definitely want to go with it as it reduces the amount of code we have to maintain, and using a peer reviewed library like boost is an advantage. I have a look at it. Thanks for pointing it out, I didn't stumble over it even though I regularly read the boost mailing lists…

47) What is the relationship between yake/msg, yapp/msg, and yapp/base/event? What's what?

• psy (11Sep2006): yapp/msg and yapp/base/event will be removed for 0.6.0. yake/msg is the preferred messaging library to be used within Yake.

48) I'm guessing that Yake presently has three different messaging systems in its sourcetree, two of which are obsolete and deprecated. For this reason I'll make no attempt at understanding yapp/msg or yapp/base/event. I can only guess that yake/msg is the one which is not obsoleted at this time, considering it supports both the concepts of target and source, while the message system in yapp/msg does not. Is this right? Interestingly enough, yapp/msg's implementation is huge and yake/msg's is tiny.

• psy (11Sep2006): You're right. Is there a problem with yake/msg being tiny compared to yapp/msg? :) After all, the latter has been written long ago…

49) In what ways should the messaging system be used in the context of a game or higher-level project?

• psy (11Sep2006): This will become clearer with the 0.6 release. First, there is not necessarily a single messaging system for your application. This depends on the developer! Yake will make use of the messaging system to tie entities, networking and certain components together.

50) How does yake/msg coexist with signals? In what situations are we to pick a signal instead of a message? Why not replace signal altogether with the messaging system, such that both queued and unqueued messages are possible?

• psy (11Sep2006): Actually, I plan to replace a few of the signals with messages.

51) yake/msg uses an odd #define for YAKE_MESSAGE_NAMESPACE. Is this convention now intended to be used throughout Yake?

• psy(28Aug2006): No. It's a leftover of the prototype. It doesn't hurt, though.

52) In yake/msg/message, why have you chosen to use void*'s as message source/target identifiers? I'm guessing it's so that the identifiers can function as both integral object numberings, or to directly hold the addresses of objects so that no numberings are needed.

• psy(28Aug2006): Yes. msg::Target and msg::Source are both void* so that both integrals and addresses can be used. It better approach may be to make these types template parameters. This means additional complexity of the library, though.
• Ideas?
• psy (11Sep2006): In SVN HEAD (0.6.0-dev) the source and target types are now template parameters for increased flexibility and type safety.

53) In yake/msg/listener, why are you casting 'fn_( static_cast<const MsgType&>(boost::any_cast<MsgType>( msgbase.value())) );' to a reference?

54) What about messaging between threads, and the necessary locking? How does yake/msg fit in here?

• psy(28Aug2006): yake::msg does no threading specific locking as you probably noticed. As messages are usually routed through 'processors' it may be useful to provide threading policies for them.

55) What sources, research, books, links influenced Yake's messaging system? I'd like to read more about messaging systems, but links are difficult to find on google because searching for “messaging”, “message posting”, or “event systems” returns a bunch of bogus results.

• psy (11Sep2006): I've implemented and used various kind of messaging systems. yake/msg is just the last one I came up with and which I found useful in the context of Yake. There are many different approaches, all of them having advantages and disadvantages depending on the problem at hand. As always, there's no ideal one-size-fits-all solution. Nevertheless, I hope yake/msg is useful for a lot of common needs. But of course, it has its own set of restrictions.
• To answer your question regarding background information: Event handling, message routing etc pp pull up quite a bit of results on Google. Many ideas and concepts are discussed in forums and mailing lists. Other than that, I have some experience with various commercial event handling systems. That may have influenced me, too.

56) boost::asio (the recently accepted Asynchronous IO library) provides an implementation of the 'proactor' pattern via an io_service which can have functors .post()'ed into it. io_service has three methods of posting: .post(), which pushes the functor into the queue, .dispatch(), which executes the functor immediately and then returns, and .wrap(), which returns a function object wrapping the passed-in function object that will dispatch to the io_service when invoked. boost::bind is used for passing specialized messages. The cool thing about boost::asio is that a pool of threads can simply poll the io_service, and when a thread is free it will handle the next available functor in the queue. Could this apply to Yake, for a messaging system? yake/msg/router is synonymous with boost::asio's io_service. yake/msg appears like a combination of the io_service and signals. Yake's router is parametized by type-being-sent; the type itself determines what to send to. But io_service doesn't support such things. As they're shooting to get ASIO into C++'s tr2, it should be getting a bit of code love in the future.

• psy (11Sep2006): I know about asio for quite some time. The recent modifications after the review definitely make it easier to understand, IMHO. How do you think, asio can be used in conjunction with Yake? (Besides, the obvious: for networking! But even then, how so?)

57) What is the difference between yake/object and yake/ent? Where do we use an Object, and where do we use an Entity? I've read the brief description in the recent announcement on the news section, but still do not understand their roles.

• psy (11Sep2006): I publish a draft of the manual soon. In short: yake/object is slightly misnamed. As you suggested, objectid would be a more fitting name. yake/object provides quite generic ClassId and ObjectId management (and even some object management which I'm not sure is an ideal solution). yake/ent makes use of yake/object. These are not competing components.

58) The organization of yake/ent and yake/object is a confusion. 'Entity' isn't in the expected yake/ent/entity.h– it's in yake/ent/object.h.. and 'Object' isn't in yake/object– it's in yake/ent. It seems that yake/object should be renamed to yake/objectid, yake/objectid's files renamed to denote that they're ObjectId related, and the definitions in yake/ent be separated into appropriate .h's. Ie, ObjectContainer → ObjectIdContainer.

• psy (11Sep2006): Cleaning up is in progress. Wanna join? Patches appreciated. :)

59) Yake has two different concepts of Object. One in yake/ent/object and the other in yake/reflection/yakeObject. They're totally different classes but with the same name. As Yake uses namespaces throughout, it's simple enough to think “one's a reflection object” and “one's an object object.” But the idea of an object is a fundamental enough building block that we need to be able to think of it in terms of only one definition. There's no problem with common class and function names existing in multiple namespaces, but Object is an exception. This also makes human communication easier.

• psy (11Sep2006): The reflection system isn't ready for wide-spread use.

60) What is the differentiation of roles between yake/ent Objects and yake/reflection Objects?

• psy (11Sep2006): See 59)

61) yake/ent/component, component_holder: What are components?

• psy (11Sep2006): Entities' behaviour can be specialized by deriving from it, or supplying different components which provide varying behaviour. This concept hasn't been completely implemented.

62) yake/ent/prerequisites.h has a strange ClsEntry struct and a 'typedef object::ClassAndObjectIdManager<ClsEntry> ClassAndObjectIdManager' but it is not used. What's this for?

• psy (11Sep2006): You really find every piece of deprecated code, do you? ;) Removed in 0.6.0-dev.

63) What are some examples of things we'd create ObjectListeners for?

• psy (11Sep2006): Scripting bindings. Per-object initialization outside of the core.

64) The concept of yake/object/ObjectId's ClassId conflicts with the idea of a ClassId as defined in yake/base/yakeUniqueId.

• psy (11Sep2006): The ClassId concept in yake/base/yakeUniqueId is not used and should be removed.

65) What is the relationship between yake/ent/object_mgr and yake/object/ClassAndObjectIdManager? Or the difference between an ObjectManager and an ClassAndObjectIdManager?

• psy (11Sep2006): The ClassAndObjectIdManager manages ClassIds and ObjectIds (registration, generation and use), the ObjectManager additionally also manages object instances of registered classes. This comes in handy when networking comes into play as in this case Id management is very important (for example, client-only classes vs global classes etc).

66) yake/ent/object_mgr and yake/object/ObjectManager conflict. Which one to use?

• psy (11Sep2006): They don't conflict. ent/ObjectManager manages concrete ent/Objects. yake/object provides generic means to do so.

67) Why are the implementation files for yake/object/ObjectId, yake/object/ObjectManager, and yake/object/ClassAndObjectIdManager all commented out? What's been deprecated?

• psy (11Sep2006): yake/object is a template-only library. In 0.6.0-dev there are only header files.

68) How about the idea of a connection between the messaging system and the Entity/Object system, so that we can send messages to ObjectId's and ObjectId groups?

• psy (11Sep2006): That's one use the messaging system has been written for. See SVN HEAD (0.6.0-dev) as it does exactly that now. :) That's also why the source and target types for the messaging system are now template parameters as it enables type safe message routing using ObjectIds in yake/ent.

69) What's with yake/plugins/scriptingLuaBindings– Is it just an example?

• psy (11Sep2006): It did more before… The intention for it is to provide Lua bindings for core types. Patches appreciated. Otherwise wait until we get around to flesh it out. :)

70) Is yake/reflection/bind_lua's complex implementation there to do anything besides handle luabind's inability to understand the type of data that Yake's reflection is able to provide?

• psy (11Sep2006): yake/reflection is not to be used as it's not complete.

71) Scripting events: What is an lua/scripting event, and how does this connect with reflection events? It seems to provide a way for callbacks to a script, but I don't see why it needs the reflection system.

• psy (11Sep2006): see 70). Or do I miss something?

72) Is yake/model done being refactored/rewritten? If not, how will it need to change?

• psy (27Aug2006): It is mostly done, though there are points that need to be addressed in the future. No extreme changes are planned.

73) Can Models hold Models?

• psy (27Aug2006): Nope. Do you need this? If yes, what for?

74) yake/model seems to have no connection with Yake's Object/Entity system. How do these come together?

• psy (27Aug2006): see 75). It is used by the entity system when needed but it's not essential and can be used on its own. And why not? :)

75) Is the idea here that we create a Model which IS-A Entity? Ie, a Model that contains an IEntity, and inherits from Entity.

• psy (27Aug2006): The other way around. An Entity may contain one or more Models.

76) yake/yapp/vehicle makes no use of the Entity/Object system. How does this work? It only uses Model and Movable. I've noticed that throughout Yake's code, 'Movable' is acting as a baseclass where other engines would have something named “Entity.”

• psy(27Aug2006): Movable is simply the OO form to say 'this object can be moved' (translation + orientation, actually). It has nothing to do with entities in the context of yake::entity. Why should 'vehicle' use 'entity' or 'object' components? The other way around, though, vehicle provides a 'ModelComponent' which can be plugged into 'Models' which itself can be contained in 'Entities'.

77) Why is an IAvatar a ListenerManager<>? Can you explain how this works?

• psy (27Aug2006): It provides an alternative to signals based callbacks. It could be removed (and has now been declared deprecated).

78) The physics abstractions are built for signal slots, but not message listeners. Isn't this a good place to support messages, as we might decide our physics' router should processMessages() at a fixed rate?

• psy (27Aug2006): What stops you from subscribing methods that feed the results from the physics system into a messaging system? OTOH, I understand your wish and it could be a performance critical piece of code (though that would have to be profiled, of course). Let's talk more about the messaging systems before we tackle this.

79) I've only had a cursory look at Yake's Net component so far. Please read this thread I've posted on the Enet forums at http://lists.cubik.org/pipermail/enet-discuss/2006-July/000618.html and tell me your thoughts.

• psy (27Aug2006): Very interesting points. What exactly do you think about when asking me for my opinion? The replies say quite a bit. ENet isn't perfect. Which library is? ;) Anyway, there are other libraries which provide more and/or advanced features. The reason I didn't use them I write about on the forum before: licensing, mainly. I want to provide an out-of-the-box solution which may not fit everyone's needs but is usable for many (at least for rather rapid prototyping).

80) Has Yake any plans for 'interest list' support in the Network component: replication only of entities which meet some criteria for range or visibility?

• psy (27Aug2006): Plain and simple: Of course, yes!

81) What is the present status of Yake's GUI abstractions? I've read some posts to the effect that there's multiple Yake GUI components, or that the Yake GUI isn't being maintained at this time.

• psy(27Aug2006): Meta wrote an excellent Lua-CEGUI library (making heavy use of templates, Lua code generation etc). Unfortunately, he left before it was mature enough for mainstream use.
  • So, use CEGUI directly. The sampleGuiConsole demo shows how to do this in the context of YAKE. And the RAF framework provides CEGUI initialization by setting a single value to 'true'. :)

82) It's important to choose descriptive names for plugins so that we can understand what they do. In yake/yapp/plugins, there's ceguiOgreRendererAdapter/ renderer_adapter_cegui_ogre/ and gui_cegui/. I think that more descriptive names are needed which clearly define their roles in english.

• psy(27Aug2006): Agreed. To clarify, gui_cegui and renderer_adapter_cegui_ogre are part of Meta's GUI library as mentioned in the previous point. The latter does the same as ceguiOgreRendererAdapter which is currently used to provide Yake-OGRE-CEGUI interoperability.

83) What is the meaning of the letters “Rt” as in yapp/raf/yakeRtApplicationState?

84) Yake's samples are not only “not so good”, but they're an exercise in confusion. They're downright misleading. Their existence is worse than not having anything at all. Take a look, for instance, at src/yapp/samples/base/objects/yakeDemo.cpp. It implements some reflection attempt that has no bearing on anything in Yake. The majority of other examples are using deprecated code, nonexistent code, do not compile, or will send the user on a wild goose chase. These need to go.

• psy(27Aug2006): I can extract some sense of frustration out of your text. ;)
  • Anyway, I don't really agree. It's true that several samples are outdated and some of them shouldn't just be updated but simply removed. OTOH, there are samples like 'vehicle' which is quite useful and clear, IMHO. (Not that it couldn't be improved…)
  • Providing better demos is a big point on my personal TODO. I'm all ears for suggestions (though I have quite a few ideas myself).

85) Sourcetree layout is confusing for all the Samples. Ie, src/yapp/samples/base. Why is vehicle there..

• psy(27Aug2006): This will be changed: Samples will be moved out of the library tree to root/yake/samples. Thanks for the suggestion.

=Bold Text

86) What system in Yake is used for registering subsystems to process each frame?

• psy (11Sep2006): First of all, there's no central frame processing unit in Yake. But Yake provides a framework for applications (yake/raf) which has such a thing. At least, in 0.6.0-dev it is possible to subscribe to frames via states and/or signals (even on a lower level by subscribing just to graphics and/or physics updates).
• The yapp/task library was designed to handle such things and in some way or another it will be revamped to support this later in a cleaner fashion. Until then please specify your exact needs.

87) Does Yake have plans to handle the spawning of threads for scripts which go into a loop? Say that a script processes infinitely, spitting out position updates. I cannot rely on on_tick; a single script can stop the whole server process.

• psy (11Sep2006): There are many ways of handling this issue. For Lua we will implement this in Yake. It isn't as hard as I thought, and we won't have to rely on threads per scripts (major performance drawback).

88) What about Tasks, a-la yapp/base/yakeTask, but for tasks which should spawn threads? Does Yake have some way of handling this and the necessary task dependencies / thread synchronization required for posting back results? If not, what can be done here?

• psy (11Sep2006): We need a solution for a similar problem when making it possible to yield scripting VMs without having to rely on threads. ⇒ Together with yake/msg I imagine, it will be possible to create a usable component for this.

89) Someone writing an app needs to store, well, central settings for that app. There is a need for a “configuration system” or “settings registry” which is loosely coupled, has hierarchical storage, can emit signals when a setting has changed, and can serialize. The loose coupling is needed so that our whole sourcetree does not need to recompile when we add a new config option, as many parts of the code connect to such a settings registry. This could use the same system as outlined in point 46).

• psy (11Sep2006): Sounds good.

90) Does Yake have plans for a higher-level system that is aware of Entity locations and can load/unload objects automatically as the player moves around a world?

• psy (11Sep2006): Definitely. This will be introduced when networking is implemented.

91) The amalgam of base's ClassId, ent's ClassId, ent's ObjectId, ent's Object, reflection's Object, reflection's Class, and prop's RttiClass particularly troubles me. Can you explain, in one place, the rationale for how they all come together?

• psy (11Sep2006): They will be unified.

92) Has Yake any plans or present way to do background resource loading?

• psy (11Sep2006): Only via OGRE. ;) Other than that, the resource manager is in the works but not yet ready.

93) Yake has some excellent ideas, and in isolation the individual components are good. The present incarnation of yake/msg comes to mind for its clean and clear implementation; it does a lot in a few lines of code. But as a whole Yake exhibits no coherent design vision. Yake, at this time, appears more like a sandbox for testing out engine ideas than an engine; a loose collection of contributions rather than a tight composition which works in a specific way. An engine is something which is tightly engineered in order to drive a vehicle forward optimally. The codebase is an elephant-graveyard of deprecations, overlaps, and vagaries. There's no reason to let TRUNK rot with decaying code; CVS/Subversion's time-machine-like abilities allow us to freely look back on prior versions of components. Yake needs consistency. The gestalt of all of these factors is that a developer who would like to use Yake is facing a steep starting curve to even figure out what parts he's supposed to really use. It appears that the codebase is being maintained by multiple people with no central arbiter to assimilate everything into a coherent form. People commit new parts, but those parts aren't tooled and standardized for the overall design. That's not to say that things can't get better. Yake is in a great position to be cleaned up, due to its modularity throughout. I grant that sometimes it's better to try out a bunch of different ways, to “just do something” instead of doing nothing, to not fret forever over the-exact-perfect-way-to-do-it. This can get some motion going, and the ensuing chaos can later be wrangled– it's a valid development technique. But a decision should be made upfront for how the side effects of this development strategy will manifest. One can let it produce a rotty-sourcetree, or instead it can be shifted/transformed into we're-quite-often-breaking-the-interface-and-systems-that-were-there-previously-just-up-and-disappeared. The latter is superior because it allows a single release at each stage of the game to be coherent.

• psy (11Sep2006): The latter approach is what we do favor. In general, I agree with a lot of what you're saying.
  • There is one thing I want to comment on, though: You say that Yake is a like a sandbox for testing engine ideas that there's no coherent design. I can imagine why you think so. Nevertheless, I disagree. Yake is designed to be quite open and usable in a variety of ways. This has the disadvantage that new developers/users have a hard time finding their way through it or even a starting point. I realise that this is not just a minor problem. Therefore, we have yake/raf which ties different components of Yake together into a coherent base for applications. This effort is nowhere near being complete but, of course, it can't be. It will be an ongoing effort.
  • I'm impressed that you, Zola, went through all of Yake in such detail. Your dedication in finding the red thread is impressive.
  • I hope that I could help clear things up. I'm also very thankful for your critique. It is very important!
  • At the end of the day, Yake is not a commercial undertaking, though. No people are getting paid to work on it. No contributions are accepted. It is a hobbyist, open source development effort and this comes with two sides of the medal, of course. There would be no support for GCC on Linux at all, without mj and others contributing to the project. Similarly, a few of your very valid points can only be changed in time, and these changes and improvements can only be finished faster by constant feedback (for motivation) and maybe a patch from time to time (for motivation and work distribution). So while I'm aware that it would be nice to improve everything at once, we all know that we have to prioritize. Feel free to influence this process. :)