• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.


  • Content count

  • Joined

  • Last visited

Community Reputation

468 Neutral

About gjl

  • Rank
  1. Still working on it anyway :-)
  2. An update has been posted. Generators will now pass the exception to the parent execution context. https://github.com/bluecataudio/angelscript-addons/tree/master/cpp Also, if you are using the JIT by BlindMind studios, you will need the following fix to avoid crashes when destroying a generator while its execution is not finished: https://github.com/BlindMindStudios/AngelScript-JIT-Compiler/pull/24
  3. By the way here some more information about the javascript generators (no need to be a javascript guru): https://blog.ragnarson.com/2016/12/15/javascript-generators.html I am actually thinking about using the generators as is, and why not build specific coroutine class on top of is, in plain angelscript - the only difference would be naming, and the fact that you can launch a coroutine until the first yield, without having to call next() once. Also, with coroutines, you may actually want to include a scheduler (dispatcher) to manage them, whereas a generator is just a lower level building block for coroutines, managing pause/resume and basic communication (managing return value and argument). You could also imagine that the scheduler class would actually be used as a coroutine factory, and you may want to assign them a priority etc.
  4. I definitely agree about naming. But I hate reinventing the wheel, so I copied this one from Javascript. The main difference with javascript though is that the iterator interface has a special meaning in the language, so you can do foreach() etc. on generators, which is something that does not exist (yet) in Angelscript. On the other hand, generators are more generic than coroutines: it CAN be used as coroutines (especially this angelscript version, that does not have the limitations of javascript generators, such as calling yield in a subroutine). but it can also be used to create generic iterators that return a value for each step (see my example above). So I am still thinking about it - any input is welcome! Even if I don't like the generator keyword, the fact that it already exists in a widespread language tells me not to reinvent another one. Also, when used as an iterator, resume() does not mean much (whereas next() in the context of a coroutine actually means nextStep()).
  5. I have finally added support for values exchange between the caller and callee using any objects: https://github.com/bluecataudio/angelscript-addons/tree/master/cpp It was not as simple as I expected, because the VM is actually suspended AFTER the call to yield returns. But it now works. No change for the simple example (yield() and next() without arguments are still supported). But you can also write the following: void main() { int count = 10; generator@ genB = createGenerator(threadB, dictionary = { {"count", 3}, {"str", " B"} }); generator@ genC = createGenerator(threadC, dictionary = { {"count", 5}, {"str", " C"} }); while (count-- > 0) { print("A :" + count + "\n"); if (genB.next(count)) { int bValue = -1; if (genB.value.retrieve(bValue)) { print("A knows B is:" + bValue + "\n"); } } if (genC.next(count)) { int cValue = -1; if (genC.value.retrieve(cValue)) { print("A knows C is:" + cValue + "\n"); } } } } void threadB(dictionary @args) { int count = int(args["count"]); string str = string(args["str"]); any valueSent; while (count-- > 0) { int fromA = -1; if (valueSent.retrieve(fromA)!=false) print(str + ":" + count + " - knows A is:" + fromA + "\n"); else print(str + ":" + count + " - knows A is: ?\n"); valueSent = yield(count); } } void threadC(dictionary @args) { int count = int(args["count"]); string str = string(args["str"]); while (count-- > 0) { print(str + ":" + count + "\n"); yield(count); } } Which outputs: A :9 B:2 - knows A is: ? A knows B is:2 C:4 A knows C is:4 A :8 B:1 - knows A is:8 A knows B is:1 C:3 A knows C is:3 A :7 B:0 - knows A is:7 A knows B is:0 C:2 A knows C is:2 A :6 C:1 A knows C is:1 A :5 C:0 A knows C is:0 A :4 A :3 A :2 A :1 A :0
  6. It is actually extremely simple for the moment. I reused the basic ideas from the coroutines add-on (actually copy/pasted the code). You can find the current prototype here (generator.h and cpp): https://github.com/bluecataudio/angelscript-addons/tree/master/cpp I am however still wondering a couple of things, so it may change quite a bit in the future. Your opinion is of course welcome! ?- should I keep the javascript-like syntax with next(), or do something like LUA (resume() etc.)? Since coroutines already exist with the coroutines add-on, I have chosen the javascript style so far, and it is also a bit more modern. ?- Does it make sense to implement values passing (back and forth) with yield like in javascript? Like: // dummy example - incomplete syntax coroutineProc(dictionary@ args) { string x=""; while(count-->0) { print("Hello" + x); x=yield(count); } } main() { // create generator generator@ gen=... gen.next("A"); print(gen.value); gen.next("B"); print(gen.value); } To make the above example work nicely, the generator object should be a template with two arguments, so it makes the whole thing a bit heavier, since template functions are not supported in Angelcript. An alternative would be to use dictionaries or "any" for argument types, but it is not very elegant - I like Angelscript's type safety :-).
  7. Hi, I am working on adding coroutines support to an application framework that uses anglescript for GUI scripting. After giving a try to the coroutines sample, it appears that it won't work for me: you cannot manage the coroutines from the scripts, as it requires that the ExecuteScripts function to be called on a regular basis by the C++ side. Also, calling yield from a context that was not registered will just do nothing. So I have written a very simple Generator add-on that makes it easier to manage coroutines from scripts, using a very similar syntax as Javascript (not returning values for the moment). So the coroutines sample script becomes: void main() { int count = 10; generator@ genB=createGenerator(thread, dictionary = {{"count", 3}, {"str", " B"}}); while( count-- > 0 ) { print("A :" + count + "\n"); genB.next(); } } void thread(dictionary @args) { int count = int(args["count"]); string str = string(args["str"]); while( count-- > 0 ) { print(str + ":" + count + "\n"); yield(); } } The major difference is that "main()" can be called from any context (no need to add it to the context manager). And you can then write your own coroutines dispatcher in Angelscript, like this very simplistic one: class GenDispatcher { bool next() { if(nextIndex>=tasks.length) nextIndex=0; if (nextIndex<tasks.length) { bool hasNext=tasks[nextIndex].next(); if (!hasNext) { tasks.removeAt(nextIndex); } else nextIndex++; } return tasks.length!=0; } array<generator@> tasks; private int nextIndex=0; }; Would you be interested in incorporating this add-on into angelscript? It is already running and I'll share the code anyways, but if it has to become an official add-on, some extra work is required, such as implementing the generic calling convention (which I do not use for the moment).
  8. With the JIT enabled, Angelscript is really fast. I could even use it for real time audio processing. It is about 5 times slower than C++ in such a scenario, which is impressive for a scripting language! As for LUA, if you can cope with its syntax, just use it. But IMHO Angelscript is much easier to use - be it for its syntax, C++ integration or features.
  9. Thanks for taking the time to check it out. My initial idea was indeed to preprocess with the callback before actually processing the files, but I tried to stick to the same semantics as the include callback, that actually replaces the include logic. So it's the same here, it replaces the processing logic, so that you can do your preprocessing and then call the compiler from there (it can be interesting to proceed this way if pre-processing is rather complex and requires that you compile several sections for example).
  10. Hi,   I needed a way to preprocess the script files before they were compiled, but after all the preprocessor directives have been processed in the script builder addon, so I have added a new callback for this purpose. I also use it to produce a preprocessed version of a script that includes many files, so that it can be distributed as a single file.   Please find attached the patch for the add-on. It would be nice if the modification could be added to the main branch - if you find it useful. I have tried to keep the semantics of the include callback (that replaces the default behavior). 
  11. Woops, my bad: I forgot that native objects are not wrapped but used "as is" by the script engine... You can forget this feature request! :-)   Anyway, I ended up writing wrapper classes, which is not a big deal (not so many methods to wrap)
  12. Thanks, that's indeed what I figured out. The problem with keeping a list of objects is that it requires extra locks and adds overheads to parse the table, that's why I thought it could be beneficial to have the extra refcount data stored into the engine directly, just like with script objects. But now that I think about it, it might not be as easy as it seems :-). So I will keep writing wrappers. It's not so bad after all!
  13. Hi,   I am working on exposing an application interface that uses the factory pattern on a regular basis: //Existing C++ Factory class class ObjectFactory { public: Object* BuildObject(); } Exposed as: //Exposed Angelscript Factory class class ObjectFactory { public: Object@ BuildObject(); }  The issue is that the application does not implement reference counting, so all the "Object" instances do not have addref/release capabilities.   So far, it seems that the only way I can expose this to angelscript is to wrap both the factory and object classes into new classes that act as a proxy, just for reference counting, so that the built object can be properly destroyed when there is no more reference to it from the angelscript side. Is this correct, or have I missed an option to avoid this?   If it is not already available, what about implementing a specific option for type registration (something like asOBJ_AUTOREFCOUNT), so that the script engine does the reference counting for you and just calls a release function when refcount is 0? This would simplify wrapping a lot when the existing classes cannot be modified for reference counting.      
  14. That's a very nice library!!