Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

122 Neutral

About Caliel

  • Rank

Personal Information

  • Interests
  1. Caliel

    Yet another C++ object instantiation question

    Thanks for the kind words. Please feel free to let me know if you encounter any performance issues, or hit any other restrictions in the library. If you happen to have a profiler of any kind it would be very useful too what bottlenecks it identifies in your application. Your use-case is quite different from anything I imagined when designing AngelScript, so it wouldn't surprise me if you would encounter some issues due to the high number of different modules. But I'm always on the lookout for improvements that can be made, so I let me know and I'll see what I can do to fix the problems you may encounter. Regards, Andreas What is ironic is that I thought Angelscript was tailored to text games, particularly so because of the game example provided in the source.  But even without a conscious effort on your part to make it mud-friendly it appears to have everything needed.  Scale will certainly be an issue, and I'll keep you informed as to any bottlenecks that I encounter.  
  2. Caliel

    Yet another C++ object instantiation question

      I need to ask you a follow-up to your suggestion.  On my mud I want creators/wizards to have the ability to make new rooms and 'compile' them into the driver to then test them out.  To this end, each room is it's own .as file.  This ensures that everything to do with a given room is encapsulated into a single script.  But this will also result in the presence of many, many rooms being loaded as separate modules over time.. which is something you suggest I avoid. So my question is how do I have 1 module load N number of rooms when each room is essentially its own program.  What I mean by that is that each room has its own periodic events, state machines, I suppose as I sit here and consider the problem I could have 1 module that instantiates N number of room objects (using AddScriptSection()) and can call an interface method like 'DoWork' or 'Think' for each of the room objects to allow them to update their state/perform timed events etc.  This would allow me to load each room script into that one module while maintaining each room as a separate script file. But then the issue with that approach is that within each room script a class would need to be defined with a unique name relative to the other room scripts.. which would be cumbersome for creators to remember/implement.  I suppose the way around that is via pre-processing of the room script files to append a unique portion on to each room class name so CRoom would become CRoomXxx with Xxx being perhaps the filename of the room script or something like that.  Another issue is how to perform hot reload  of rooms selectively when a creator makes a change and wants to test it out (or remove a room entirely).   I can't quite wrap my brain on how to avoid loading each room as a separate module.  Any advice here?
  3. Caliel

    Yet another C++ object instantiation question

    I had not seen the 'Further resources & support' section.  But I will be visiting it soon.  Re: inclusion of AngelscriptUtils in the angelscript source, I completely understand your desire to focus on the core.  At the end of the day these peripheral projects should be maintained outside of the mainline trunk as you shouldn't be responsible for keeping everything compatible.. which is to say you should just be concerned with changes to the core without worrying about whether AngelscriptUtils will build/play nice.  On a completely different note, angelscript is exactly what I was looking for when I set out to write a mudlib from the ground up.  It gives me the closest 'feel' to an LPmud driver-esque scripting engine while going further with object oriented support.  I am extremely impressed.  Also, I ran some ad-hoc performance tests last night with 10k modules loaded (using AngelscriptUtils as a test wrapper), and performance is very reasonable even with a debugger attached.
  4. [EDIT: March 14, 2017 I am very impressed with SamVanheer's (known as SoloKiller on this forum) AngelscriptUtils.  I think it should be part of the Angelscript source.  Using AngelscriptUtils I was able to easily implement C++ inheritance and event subscription, among other things.   AngelscriptUtils came from this thread: https://www.gamedev.net/topic/680409-inheritance-from-internal-c-classes/   And on github: https://github.com/SamVanheer/AngelscriptUtils] So I am presently determining how to best implement angelscript into a project.  I've examined and torn apart the game example and fully understand how the script objects get a "self" object that refers back to a C++ instantiated object.  Based on other posts from this forum I also understand you can hide the 'self' object by having a script proxy class that provides interfaces to 'self' without a script writer needing to understand the underlying mechanics.   However, I find myself not particularly excited with the game example approach as I'd like to enforce method constraints at the C++ level.  What I mean to say is I want to have base C++ classes which are inherited by the script objects, with the C++ classes defining the various required member functions.  I found documentation to this end within the help file, but, it has me wondering the following:   What is the draw backs to having script objects inherit the C++ objects?  Particularly when it comes to performance and memory with thousands of script modules loaded.  On the C++ side i will need to perform a lot of lookups on 30k+ objects and it seems rather inefficient to perform a getmodule() call every time I need to find a particular object.  The Game Example approach does a better job of this by providing a C++ pointer to each object that I could store and lookup efficiently. So with that said..What are the best practices for ensuring that I can have 30k modules loaded and easily traversed? Thanks!
  5. In the SDK/Samples folder there is a concurrent context example.  In the same two scripts are executed, script1/script2, with each script having a for loop that sleeps for 1 second.  Within the main.cpp, the following function then causes the scripts to execute:     I understand the contextManager.ExecuteScripts() causes the "main" in each of the scripts to be executed, and more particularly, given time to perform their loop before yielding back and sleeping.     However, what I do not understand (nor can find in the documentation) is the answer to the following questions:   Does the ExecuteScripts() method only call the main function in each thread?  I assume this is true, but I can't find the answer within the contextmanager addon sourcecode.  It would be good to know why ExecuteScripts is calling 'main' and if its limited to only operating on that interface method.  It would be nice to be able to write a class with a method that is intended to be long-running and called by the ContextManager.  I know I can get there by having an object instantiated in main and calling its methods.. but I'd like to avoid that if possible. This leads to my second question, what if I want to call a script function from the C++ side.  For instance, what if I want to call Obj::SomeLongRunningMethod() that sleeps every 500 ms and performs some type of long-running state control. Thanks very much  
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!