• 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.
Sign in to follow this  
Followers 0
lxnyce

Multiple engines, good or bad?

6 posts in this topic

I am trying to make a scriptable building declaration. For example, lets say I have 3 building types. Small, Medium, Large stored in 3 different scripts in one directory. Each one would have something like a cost function, and a build function. I want to load all the scripts in that directory, and iterate through them so that I can build the best building for a given polygon based on the cost function returned by each building. The problem is, I want all the building descriptions to have the same function declarations. So at runtime, I can load all the scripts in a directory. When it comes time to build a building, I call the cost function on each script to find out the best choice and then call the build function on that one to actually build the structure. Should I use a separate script engine for each script? Seems wasteful, and I don't know what kind of overhead is involved with each new engine. Could be hundreds of scripts. Is there any way of isolating all scripts added, so that I can query by function name within a certain script filename? I guess this is kind of like namespaces, but not really. Is there any way outside of having to append the filename to the script cost and build functions to load them into one engine and have them run? Like "int small_cost()", and "int medium_cost()". I would really not like to use this method, but if its the only way then I guess I must.
0

Share this post


Link to post
Share on other sites
What you are asking for will be implemented in 1.8.0, the version I'm working on right now. With 1.8.0 you will be able to compile scripts into different modules, each with their own namespace.

For version 1.7.1, the two alternatives are to either prefix or suffix each function name to separate them into namespaces, or create multiple engines.

Most of the overhead with multiple engines comes from the engine configuration. If you have lots of system functions or objects registered the overhead will be larger. A rough guess is about 30-50 bytes per called registration function.

I'm hoping to be able to finish version 1.8.0 by mid July. Note: this is not a promise as I'm very short on time.

Regards,
Andreas
0

Share this post


Link to post
Share on other sites
We are already using Multiple engines in our game to get around that problem, everything seems fine but one issue i have had with these is the inability to use 'extern' style of variables. i would love to have different scripts running in the same engine with some variables which i can share throught these scripts.

Can we make a small compiler like interface within VS for each script to make sure each script is precompiled(during app compilation) to know if the script is syntax error free before starting the host app?
0

Share this post


Link to post
Share on other sites
Thanks WitchLord. I guess I will just play around with my other scripting ideas till then. Just for the record, I love AngelScript. I don't understand why everyone isn't pushing for this yet. Good work, especially for a freetime project.

Oh ye, I started learning it about a week ago, and there really is only 1 example to work with (2 if you count the bstr program). I think a group of simple examples rather than that one large one is probably the way to not turn beginners away from this. If I ever get time, i'll try wrapping some OpenGL functionality into a script, so that users can try their hand at GL programming through scripts.

EddHead, thats a pretty good idea.

Thanks for your help guys, later.
0

Share this post


Link to post
Share on other sites
EddHead:

Version 1.8.0 will also allow interaction with script declared global variables, which would allow you to connect them between engines. The script functions would be more difficult to export to another engine though. I will think about it, maybe it will be possible in a future version.

The way to make a test compilation of the scripts is to write a dummy application that registers all the functions and object types, and then compiles the scripts. An application like this could even be made completely generic if the function and object types were put in for example a xml file. It would be a completely separate project though.

lxnyce:

People are probably not pushing for AngelScript because it is relatively new. The first public version was made available just about 1 year ago. And people also tend to look at what other professional developers are using, which would be Lua or Python. But, I'm seeing more and more interest in AngelScript as time passes. Someday, perhaps some really famous game developer will pick it up and tell the world that he'll be using it for his next game ;)

I know the lack of examples and tutorials is a real blocker when it comes to newcomers, but I'm doing my best to improve that along with the new features. I think the new overview that I recently put up on the site will help alot to show what can be done.

I will welcome any tutorials or sample programs with source code written by others. I can even host them on AngelCode.com if the author wants.

0

Share this post


Link to post
Share on other sites
i dont think there would be any need to extern script functions(just variables would do) from one engine to another as of now, we could just send variables across. we could think about using a single engine instead with all the possibilities of multiple engines(to reuse functions), one thing i noticed was putting everything in the same engine would give line number changes during errors which would be hard to track, if that is fixed we can stick to one engine. but about multiple processes, i guess the load on one engine would be too much. one more workaround now is declare the global variables globally in the host application (kinda cumbersome).

your thoughts?
0

Share this post


Link to post
Share on other sites
Currently I highly recommend having separate engines for tasks of different types, ex. one engine for GUI rendering and another for AI managing. This is mostly for safety, and simplicity.

Having one engine that handles different tasks of the same type will be much easier with version 1.8.0, because of the modules.

I'll verify the problem with wrong line numbers.

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0