• 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
samgj

LLVM Library for Scripting

7 posts in this topic

For my engine I would like to be able to have scripting in an any arbitrary language. I have heard that LLVM is very efficient and also supports JIT compiling and can be used as a virtual machine. It can be called as a library but, from all the documentation I've read for it, it seems like the library can only be used for compilers and not for scripting features. My question is, does that the library only supports compilers?

0

Share this post


Link to post
Share on other sites

Ravyne is spot on, but you can use other languages for scripting depending on target platform.

 

For example if you are running on windows you can actually compile C# on the fly and use it as a scripting language.

 

You could use LLVM, but it would be a hell of an effort. We have our own LLVM compiler based on gcc and getting that to work was a major effort. Getting the LLVM to then execute on a target platform is another major effort. Doing all that just for a scripting langauge, ..... priceless smile.png

0

Share this post


Link to post
Share on other sites

I tried to embed SpiderMonkey and V8 at first, but my attempts to build them for msvc weren't fruitifull so far, same for Mono.

Squirrel is quite handy, and has a really cool syntax.

Edited by Eliad Moshe
0

Share this post


Link to post
Share on other sites

I tried to embed SpiderMonkey and V8 at first, but my attempts to build them for msvc weren't fruitifull so far, same for Mono.

Squirrel is quite handy, and has a really cool syntax.

 

my thoughts:

looked at LLVM before, but it looked a bit much like using a sledgehammer for a job better suited to a clawhammer (ex: typically stuff involved in running script code). what it provides isn't exactly a great fit for what makes sense for a typical script-language backend.

 

 

there is kind of a common mindset though of people using the biggest / most powerful / most "industrial strength" tool, regardless of whether or not it is most appropriate for the task. using something overly big and heavyweight though may actually make things worse in terms of development/maintenance work and sometimes also performance (say, if the workload of the task does not match the workload the tool was developed for).

 

 

SpiderMonkey and V8: dunno. usually GCC -> MSVC porting is doable, if sometimes annoying, though it requires a bit of a willingness to "dig in" and sometimes partly rewrite things, ... wouldn't think it would be as much of an issue for SpiderMonkey as IIRC Mozilla uses MSVC for their Windows builds, so the code should be reasonably free of GCC-isms. what little I had looked at them, things seemed "fairly reasonable" at least.

 

Mono: ... I have looked at the code for this before. at the time I found it almost absurdly questionable/bad even for performance-oriented VM back-end code (clear abstractions were largely absent, pretty much everything was tangled up in everything, ...). now, I am less certiain, as dealing some with performance-oriented code may have increased my tolerance for "general nastiness" to some extent (though even as such, I still prefer to try to maintain things like consistent internal API abstractions and uphold naming conventions and similar...).

 

not really looked too much into Squirrel personally.

 

 

in my case, I am using my own VM technology, and my efforts are pretty well invested in this. major/core pieces of codebase architecture and infrastructure are not something that can be easily swapped out without a lot of pain. more so when one considers that "little things" done by one things may not be done, or may be done a fair bit differently, with something else.

 

also partly because it has been developed incrementally in an on-off manner over the past 15 years or so, and 15 years ago, there weren't as many good options available for scripting, and at the time it seemed like such a simple task to throw together a naive interpreter.

 

maybe funny, or sad, or just some sort of personal fault, that things often start out so small/easy/simple, but often over a period of time seem to mutate into something a bit far from being nearly so small or simple anymore.

1

Share this post


Link to post
Share on other sites

For me, I don't like scripting in the traditional sense. I know, I know, I'm the weird one. I've come to accept that.

 

For me loading in text files in whatever format in a release build has too many issues. Hackers can alter the text files and change the game behaviour, you have the overhead of parsing them, etc. etc. etc.

 

I like the ability to script while developing the game though. When I was doing XNA coding I would use C# for scripting while I'm developing the game. Then compile the scripts into the game for the release. That worked well for me.

 

What do people do these days? 

0

Share this post


Link to post
Share on other sites

For me loading in text files in whatever format in a release build has too many issues. Hackers can alter the text files and change the game behaviour, you have the overhead of parsing them, etc. etc. etc.


Well, for starters you don't load text files in release; you compile the script to whatever byte code format the language uses and then use that - this is why Lua is a popular choice as it's a light scripting system, flexible, bindable AND the frontend can accept both text and byte code as source data.
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