Related
Basically, I'm unable to find any good articles for developing your own GUI, that deal with good practices, the basic structure, event bubbling, tips and avoiding all the usual pitfalls. I'm specifically not interested on how to build some proof-of-concept GUI in 5 minutes that just barely works... nor am I interested in building the next future GUI.
The purpose is to build a reasonably capable GUI to be used for tools for a game, however they will exist within the game itself so I don't want to use existing large scale GUIs, and I find most game GUIs to be rather bloated for what I need. And I enjoy the experience of doing it myself.
I have done a GUI in the past which worked very well to a point, however, due to some bad design decisions and inexperience it could only do so much (and was built in Flash so it got a lot of stuff for free). So I would like to really understand the basics this time.
A few tips -
1) Pick your style the UI will work - will it be stateless? If yes, how are you going to handle the events appropriately? In case it'll be stateless, you'll maybe have to re-evaluate your UI user code twice in order to get up to date event changes from user side. If your UIs store state, then you won't have to care about handling events, but it'll limit your UIs when it comes to rapid mutations and rebuilds.
2) Do not rely on the OO too much, virtual methods are not the fastest thing in the world so use them with care; having some sort of inheritance based structure might help though. Beware of dynamic_cast and RTTI if you use objects; they will slow you down. Instead, set up an enum, get_type() method for every widget class, and do manual checks for castability.
3) Try to separate the looks and the UI logic/layout.
4) If you want dynamic windows, layouts etc. then you'll have to handle aligning, clamping, positions etc. and their updates. If you want just statically positioned widgets, it'll make it much easier.
5) Do not overdesign, you won't benefit from that.
There is not really anything too specific I tell you; having some concrete question would help, maybe?
Take a look at the docs for existing GUI libraries. That should give you details on proven designs to handle the issues you've run into.
You might want to start with one you're familiar with, but one that I think is designed quite well is AppKit. Its API is Obj-C so it would require some adjustment if you wanted to copy it, but the docs give all kinds of details about how objects interact to, e.g. handle events, and how layout constraints work, which should be directly applicable to designing an OO GUI in most any language.
Okay, so I've been getting into 2D game developing/programming , and many games I've seen use some sort of scripting language too. So I'm wondering - What's the purpose of using scripts in games? I know there's not simple one reason answer, and I've been trying to consider all the possibilities. Here's what I 'think' I know so far:
1) Scripts allow for changing the game without having to re-compile.
2) Scripts are easier for non-programmers to use.
3) Scripts allow me to separate the engine from the game itself allowing me to make other games with the same components quicker?
That's about all I'm aware of. My next question is, if I'm going to be Dev/programming a game alone - do I really need to use scripts? Or could I prototype the game using something like python or ruby, to allow for rapid testing, then rewrite the code in C++ saving time and compiler bugs, etc?
Another thing I'm wondering, Am I better off using Ruby or Python since I'm most experienced with those? Or should I use Lua, Perl or something else if it better fits what I aim to achieve? Speaking on that matter, what really should I use scripts for? should I use them to position and model game menu UI's, write/read save-files, load map levels, hold arrays or structures of game terminology such as "New Game" or "Quit," all of the above, none of the above?
If I make use of scripts, won't that allow game mechanics to be edited by the end user? Or is there a way to package the scripts into one compressed file that the engine can read?
Most basically, I'm wondering:
What should I use scripting in my game for? And why?
Do I need use scripting languages if I'm working alone or with programmers as opposed to Devs?
What scripting language 'should' I use if I were to be making platformers, RPGs, or what-have-you?
your top 3 reasons are all 100% correct and are the main reasons for using scripting languages along with your game engine.
Personally I've only really had experience with Lua through Luabind. It's a little tricky to setup but it was worth it. What you can do with scripting languages is expose the data structures and/or functionality that you want the 'user' in this case yourself, to be able to use. Generally speaking the only game mechanics etc that can be editted would be the ones you allowed them to.
What should I use scripting in my game for? And why?
Asset loading, exposing features/types, ie, for our game engine (written in c++), we had a base level, and then many different types of level inherriting from it, such as wave level, death match, etc. The user simply states in the script what type of level they need, and then chucks in the assets here too. In my demo we had;
Level="wavelevel"
--Level Initial number of enemies
EnemyNumbers="3"
--Level Total number of waves
WaveNumbers="4"
--Wave coefficient
WaveCoeff="1.1"
--Size of terrain
TerrainSize="256"
--Terrain file
TerrainFile="resource/Models/mountainous.raw"
Don't worry too much about the numbers and all of that.
As you can see that does some asset loading as well as determining the level type
We also gave a lot of control for the AI to scripts, in fact, the data structures were almost completely exposed to Lua.
Do I need use scripting languages if I'm working alone or with programmers as opposed to Devs?
Yes no maybe? We all prefer 'real' coding of course. If you can make your game engine abstract enough to build completely different games just with Lua, then it means you've done a great job and have designed it very well.
The other thing you have to think about, especially if you're game engine is quite huge, and lets face it, there isn't really going to be a small one, each time you compile, it can take minutes! It's the linker that's taking time here.
What scripting language 'should' I use if I were to be making platformers, RPGs, or what-have-you?
I've only ever used Lua, so that's the only advice I can give here.
Hope this is helpful info for you.
Honestly, as this sounds like your first attempt at a game ever, you shouldn't even be worrying about this sort of thing. Instead, I'd be more worried about keeping the scope of your project down to a level where you have a snow ball's chance of actually completing something. If you haven't done something at the level of Tic-Tac-Toe or Pong yet, do that first. What you learn there will be more valuable than worrying about a scripting language.
Oh and if you are doing an RPG as your first attempt at a game. Don't. They are by far the hardest type of game to do even for professional developers with many, many times the resources available to them. Keep it simple and and use this as a learning experience.
Back to your questions:
If you are the only one who will ever see your game, your choice on using a scripting language or not. If it will save you time overall or you want to learn how to do integration of scripting with code, go for it, but beware it will be a bit of a time sink.
Yes/no/depends on your second. If the scope of your game is small, scripting isn't as important. If you doing this alone, scripting isn't as important.
Your choice on what you know or what your engine will support (or what engine tools you cna buy to support). Lua is popular, but even hand rolled scripts will work as well. It's more about decoupling data from code and design type work from engineer type work.
Your initial points above apply. Scripts keep non coders out of code and allow anyone on a team to easily change data related stuff that should be in code anyways. Scripts also act as a very high level language allowing lots of game level changes in controlled ways that would/will look ugly if placed in code. I've personally worked on games that were done both ways. Scripted games were a bit easier to maintain at the end of the game cycle - IF IF IF the script support code was mature and had been run through some debug cycles. New script support code is harder to debug than coding things straight because there are more possible points of failure. Games that were coded without scripts tended to get done a touch faster, but required a lot more programmer/engineer time which means the overall scope of things had to be limited to stay on budget.
I will say that well designed scripting and overall gaming system will always beat straight coding. Look at Unity for an example of how scripting and code and everything else can be coupled into a slick interface that allows very quick game development.
What should I use scripting in my game for? And why?
The reasons you cited are good ones. One thing that you might need to understand is that most professionnal games are still built with C++ and it's far from being flexible to change if the code base is big. So if you use C++ you'll need scripting languages to make quick changes where it's imporant to be allowed to do so accordingly to the reasons you listed.
If you don't use C++, maybe you use a language that can absorb changes quickly, making the main purpose of scripting not so obvious. I wouldn't use scripting language in a Flash or Python game for example.
Do I need use scripting languages if I'm working alone or with
programmers as opposed to Devs?
As my previous answer : it depends on the timing of changes. Think that the core rules of games rarely change but everything relative to level design will, and should be testable ASAP. If you can do it in the game's programming language, why bother? If you can't, then any way to speed-up change integration will pay.
What scripting language 'should' I use if I were to be making
platformers, RPGs, or what-have-you?
Frankly, there is no one solution to any problem. I personally use Falcon and ChaiScript, Lua is well known but any scripting language that can be used with your game programming will do. That's a question already asked around and if you have doubt, just choose Lua as it's the most common in gaming.
I'll give you a quick and short answer. Scripts are mostly for changing things while the game is still running which you can edit things faster. This is much better then recompile, reloading the assets, going to the specific point in game, activate certain conditionals (items, talking to people in specific order, etc) and etc.
Things done in script are character speech, NPC interaction with triggers (for example walking somewhere stopping to talk to another NPC, then run somewhere, scripting is used for timing), triggers or events in general and enemy stats (health, speed, accuracy, sometimes logic for said character).
The reasons you list are all valid reasons for using scripting languages in games. I'd also add another reason though: different languages are better suited to different kinds of programming tasks and a high level scripting language allows you to write parts of your game in a language that might be a better fit than C++.
The main reasons C++ is widely used in games are performance, easy access to low level native APIs or hardware (on consoles) and inertia - most games are written in C++ so most third party libraries and middleware for games are written in C++ and most easily interfaced with from C++. For many tasks however higher level languages like Python, C# or Ruby have programmer productivity benefits over C++ that can outweigh the advantages of C++ for code that is not performance critical or does not have to interface with native APIs.
A well designed C++ game engine with a high level scripting language can give you the best of both worlds - the performance and low level access of C++ where it's most needed and the productivity benefits of a high level language where they are most needed.
As a matter of fact, almost all MMORPG game servers are programmed in script.
All the C++ engin will embed a script language for logic handling, lua is a suitable script language for it.
In bigworld, python is the default embed language.
And node.js is also a good candidate for game server programming. Because its network io ability is superior. There is an open source framework in node.js:
https://github.com/NetEase/pomelo/
I've found it unhelpful to use scripts, both when I was employed in a large game studio and in my work as an indie developer. On the other hand I have friends who've used professional-grade, modern engines with scripting technology successfully. As you're doing indie game development on your own (or in a small team), I think you should avoid it. The main reasons are:
It adds overhead pretty much everywhere: one more language to master (per developer in the team), performance is slower than native, and the API the weakest link which means you often need to rebuild the binary anyway.
The only real gain with a higher-level language is less development hours up front (if you're using a mature engine), but in my experience that time is eaten up by time-consuming bug-smashing in the end.
Many game scripting languages uses dynamic typing (Lua, Stackless Python, Pawn), which I find error-prone compared to statically typed languages. If you too feel it's only good for simple things, you might as well do it natively instead.
As a side-note I do find game scripting languages exceptionally useful, but only for quick-hack/prototype apps, not for huge components within games. See my answer here.
I'm not convinced scripting interfaces for games you write yourself are so useful. I did some work on Freeciv once, and immense effort went into enabling "modding" using the scripting interface. A feature that seemed little used. I think there is a danger of the inner platform effect. You don't need a scripting language to customize your game: you already have a perfectly good programming language (C++, in your case) for doing that. It's a WTF.
What should I use scripting in my game for? And why?
As everyone (including you) has said, scripts make your game easier to edit. On a larger team scripting also has a very good productivity effect: the tech-savy folks can continue to polish the engine, while the creative people can work on the actual game, and the two teams don't have to get in each other's way.
Do I need use scripting languages if I'm working alone or with programmers as opposed to Devs?
You don't need it and depending on what you're final goal is, it might actually be a waste of time to implement scripting. I also develop a 2D scriptable game atm; I'm alone but I'm making it scriptable also as a personal challenge and also because I want the game to be easily modifiable.
What scripting language 'should' I use if I were to be making platformers, RPGs, or what-have-you?
The top two most popular options are Lua and Python. Most people recommend Lua because it's slightly faster. I went with Python because it has (native) support for classes — which works well with my existing C++ architecture — and also because I find it to be a much more enjoyable language to work with.
Okay, I know this is a bit dead, but I have to say this. There is literally no such thing as programming without scripts. It honestly doesn't matter if you write them in yourself or not, fact is, somebody wrote those scripts. Like ruby, in order to use it, you need a program like say notepad+ in order to set it up, or any computer based RPG Maker from enterbrain uses a form of ruby to operate. like it or not, when using computers to design a game, learn to script. Now as for the language, look some up and try different ones out. Don't cheap out with using a pre compiled engine, just work from scratch. trust me, you will be better off. I am still trying to decide which I like better, Lua(C++) or Ruby. I may just use pure C++
I've tried to develop a 2D game with C++ in the past using mere objects, however, in the design process I don't know how and what parts of the engine I should split into smaller objects, what exactly they should do and how to make them interact with each other properly. I'm looking for books, tutorials, papers, anything that explains the game engine design in detail. Thanks.
Mandatory reading: http://scientificninja.com/advice/write-games-not-engines
Why do you think you need a game engine? Write the code you need in order to implement your game. Modify it along the way as requirements change. And when you have a complete game, take a step back and look at what the result looks like.
You can't, and shouldn't, lay out a complete class diagram at the start. Sketch out a rough idea of what general components you want, and what their responsibilities should be, and then try to code it. Start out with the classes you're sure of. Sooner or later, some of them will get big and unwieldy, so you split it into multiple smaller ones. Sometimes, you may find that several classes are basically doing the same thing, so you merge them back together. Hopefully, sooner or later, you'll end up with a design that works, which is more than you'd get if you tried to design a game engine up front.
If you haven't made a game before, how can you make an engine? There's tons of free engines out there or you will be spending 20 years trying to get something done because you will be rewriting over and over again.
There are two important types of objects in a game. There are objects that contain processes, and there are objects that interact with the environment and the user.
For those objects that run a process like changing the opacity of objects you'll want them to be independant of any class level variables. They should simply take in value(s) and return value(s). If you have a process to calculate gravity, the process should take in the object that it gravity is being calculated on, and return the the amount of gravity that the object is experiencing, and the direction of gravity if the game takes place in space.
The second more important types of objects are those that interact with the user and the environment. These objects should all inheret of the same base class. The base class will require an image, and the x and y position, and can have variables that perform specific processes like changing the speed or direction of the variable.
With this base class in place you can then perform proccesses like the gravity proccess mentioned earlier using every objects "built-in" variables like speed, direction, and x and y position.
You will also want to set up your objects to run peices of code under certain conditions. It may be a good idea to have your base class provide functions that get run when one of these conditions are met. Some useful conditional functions are a conditional function to go of when an object is first created and when it is destroyed. A conditional function to go of after a timer is set. A conditional functional to go of continually where you can place code to draw images on the screen. A conditional function to go off When a keyboard or mouse button is pushed. A conditional function to go off a set amount of times per second to calculate things like gravity on an object.
This framework has worked very well for me when creating games. It works for any type of game, and works horribly for other types of programs. Sorry if my writin is unclear, I'm typing on my iPod and It would be hard for me to go back and edit things on here.
Eberly's 3D Game Engine Architecture and 3D Game Engine Design are rather heavy on the theory, but cover all of the bases quite well.
http://fivedots.coe.psu.ac.th/~ad/jg/
This guy lays out a good oop style and through the book helps you build an engine frame. It's spot on good stuff.
If you want to code a simple 2d game, a good way to get an idea of what you#re actually trying to do is to:
write a simple game loop, that simply displays a frame buffer in the resolution you want
render a simple sprite with a a given direction and velocity bouncing off the screen edges
ensuring that your logic and display code are decoupled
If this sounds like a a lot of work, or if it contains ideas/ terms you're not 100% sure what they mean: Take a look at one or two of the existing game engines.
If you just want to get an idea of how it's done, coding something is a great way to learn.
If you're more interested in developing a game, I strongly recommend something like Unity as a base, so you can actually work on the game. And since it is an engine, you'll learn over time how many different parts there are, and how they interconnect.
Call main.lua script at each game loop iteration - is it good or bad design? How does it affect on the performance (relatively)?
Maintain game state from a. C++ host-program or b. from Lua scripts or c. from both and synchronise them?
(Previous question on the topic: Lua and C++: separation of duties)
(I vote for every answer. The best answer will be accepted.)
My basic rule for lua is - or any script language in a game -
Anything that happens on every frame: c++
asynchronous events - user input - lua
synchronous game engine events - lua
Basically, any code thats called at >33-100Hz (depending on frame rate) is C++
I try to invoke the script engine <10Hz.
Based on any kind of actual metric? not really. but it does put a dividing line in the design, with c++ and lua tasks clearly delineated - without the up front delineation the per frame lua tasks will grow until they are bogging processing per frame - and then theres no clear guideline on what to prune.
The best thing about lua is that it has a lightweight VM, and after the chunks get precompiled running them in the VM is actually quite fast, but still not as fast as a C++ code would be, and I don't think calling lua every rendered frame would be a good idea.
I'd put the game state in C++, and add functions in lua that can reach, and modify the state. An event based approach is almost better, where event registering should be done in lua (preferably only at the start of the game or at specific game events, but no more than a few times per minute), but the actual events should be fired by C++ code. User inputs are events too, and they don't usually happen every frame (except for maybe MouseMove but which should be used carefully because of this). The way you handle user input events (whether you handle everything (like which key was pressed, etc) in lua, or whether there are for example separate events for each keys on the keyboard (in an extreme case) depends on the game you're trying to make (a turn based game might have only one event handler for all events, an RTS should have more events, and an FPS should be dealt with care (mainly because moving the mouse will happen every frame)). Generally the more separate kinds of events you have, the less you have to code in lua (which will increase performance), but the more difficult it gets if a "real event" you need to handle is actually triggered by more separate "programming level events" (which might actually decrease performance, because the lua code needs to be more complex).
Alternatively if performance is really important you can actually improve the lua VM by adding new opcodes to it (I've seen some of the companies to do this, but mainly to make decompilation of the compiled lua chunks more harder), which is actually not a hard thing to do. If you have something that the lua code needs to do a lot of times (like event registering, event running, or changing the state of the game) you might want to implement them in the lua VM, so instead of multiple getglobal and setglobal opcodes they would only take one or two (for example you could make a SETSTATE opcode with a 0-255 and a 0-65535 parameter, where the first parameter descibes which state to modify, and the second desribes the new value of the state. Of course this only works if you have a maximum of 255 events, with a maximum of 2^16 values, but it might be enough in some cases. And the fact that this only takes one opcode means that the code will run faster). This would also make decompilation more harder if you intend to obscure your lua code (although not much to someone who knows the inner workings of lua). Running a few opcodes per frame (around 30-40 tops) won't hit your performance that badly. But 30-40 opcodes in the lua VM won't get you far if you need to do really complex things (a simple if-then-else can take up to 10-20 or more opcodes depending on the expression).
I don't like C++. But I do like games.
My approach might be a bit atypical: I do everything I can in Lua, and only the absolute minimum in C++. The game loop, the entities, etc are all done in Lua. I even have a QuadTree implementation done in Lua. C++ handles graphical and filesystem stuff, as well as interfacing with external libraries.
This is not a machine-based decision, but a programmer-based one; I output code much faster in Lua than In C++. So I spend my programmer cycles on new features rather than on saving computer cycles. My target machines (any laptop from the last 3 years) are able to cope with this amount of Lua very easily.
Lua is surprisingly low-footprint (take a look to luaJIT if you don't know it).
This said, if I ever find a bottleneck (I haven't yet) I'll profile the game in order to find the slow part, and I'll translate that part to C++ ... only if I can't find a way around it using Lua.
I am using Lua for the first time in a game I've been working on. The C++ side of my application actually holds pointers to instances of each game state. Some of the game states are implemented in C++ and some are implemented in Lua (such as the "game play" state).
The update and main application loop live on the C++ side of things. I have exposed functions that allow the Lua VM to add new game states to the application at runtime.
I have not yet had any problems with slowness, even running on hardware with limited resources (Atom processor with integrated video). Lua functions are called every frame. The most expensive (in terms of time) operation in my application is rendering.
The ability to create new states completely in Lua was one of the best decisions I made on the project, since it allows me to freely add portions of the game without recompiling the whole thing.
Edit: I'm using Luabind, which I have read performs slower in general than other binding frameworks and of course the Lua C API.
You probably don't want to execute the entire Lua script on every frame iteration, because any sufficiently complex game will have multiple game objects with their own behaviors. In other words, the advantages of Lua are lost unless you have multiple tiny scripts that handle a specific part of the behavior of a larger game. You can use the lua_call function to call any appropriate lua routine in your script, not just the entire file.
There's no ideal answer here, but the vast majority of your game state is traditionally stored in the game engine (i.e. C++). You reveal to Lua just enough for Lua to do the decision making that you've assigned to Lua.
You need to consider which language is appropriate for which behaviors. Lua is useful for high level controls and decisions, and C++ is useful for performance oriented code. Lua is particularly useful for the parts of your game that you need to tweak without recompiling. All magic constants and variables could go into Lua, for example. Don't try to shoehorn Lua where it does not belong, i.e. graphics or audio rendering.
IMHO Lua scripts are for specific behaviours, it's definitely going to hurt performance if you are calling a Lua script 60 times per second.
Lua scripts are often to separate stuff like Behaviour, and specific events from your Game Engine logic (GUI, Items, Dialogs, game engine events, etc...). A good usage of Lua for example would be when triggering an explosion (particle FX), if the Game Character walks somewhere, hard-coding the output of that event in your engine would be a very ugly choice. Though, making the engine trigger the correct script would be a better choice, decoupling that specific behavior off your engine.
I would recommend, to try to keep your Game State in one part, instead of upscaling the level of complexity of keeping states synchronized in two places (Lua and Engine), add threading to that, and you will end up having a very ugly mess. Keep it simple. (In my Designs I mostly keep Game State in C++)
Good luck with your Game!
I'd like to throw in my two cents since I strongly believe that there's some incorrect advice being given here. For context, I am using Lua in a large game that involves both intensive 3D rendering as well as intensive game logic simulation. I've become more familiar than I'd have liked to with Lua and performance...
Note that I'm going to talk specifically about LuaJIT, because you're going to want to use LuaJIT. It's plug-and-play, really, so if you can embed Lua you can embed LuaJIT. You'll want it, if not for the extra speed, then for the automagic foreign function interface module (require 'ffi') that will allow you to call your native code directly from Lua without ever having to touch the Lua C API (95%+ of cases).
It's perfectly fine to call Lua at 60hz (I call it at 90hz in VR..). The catch is that you are going to have to be careful to do it correctly. As someone else mentioned, it's critical that you load the script only once. You can then use the C API to get access to functions you defined in that script, or to run the script itself as a function. I recommend the former: for a relatively simple game, you can get by with defining functions like onUpdate (dt), onRender (), onKeyPressed (key), onMouseMoved (dx, dy), etc. You can call these at the appropriate time from your main loop in C++. Alternatively, you can actually have your entire main loop be in Lua, and instead invoke your C++ code for performance-critical routines (I do that). This is especially easy to do with the LuaJIT FFI.
This is the really hard question. It will depend on your needs. Can you quite easily hammer down the game state? Great, put it C++-side and access from LuaJIT FFI. Not sure what all will be in the game state / like to be able to prototype quickly? Nothing wrong with keeping it in Lua. That is, until you start talking about a complex game with 1000s of objects, each containing non-trivial state. In this case, hybrid is the way to go, but figuring out exactly how to split state between C++ and Lua, and how to martial said state between the two (especially in perf-critical routines) is something of an art. Let me know if you come up with a bulletproof technique :) As with everything else, the general rule of thumb is: data that goes through performance-critical pathways needs to be on the native side. For example, if your entities have positions and velocities that you update each frame, and you have thousands of said entities, you need to do this in C++. However, you can get away with layering an 'inventory' on top of these entities using Lua (an inventory doesn't need a per-frame update).
Now, a couple more notes I'd like to throw out both as general FYIs and in response to some of the other answers.
Event-based approaches are, in general, critical to the performance of any game, but that goes doubly for systems written in Lua. I said it's perfectly fine to call Lua # 60hz. But it's not perfectly fine to be running tight loops over lots of game objects each frame in said Lua. You might get away with wastefully calling update() on everything in the universe in C++ (though you shouldn't), but doing so in Lua will start eating up those precious milliseconds far too quickly. Instead, as others have mentioned, you need to be thinking of Lua logic as 'reactive' -- usually, this means handling an event. For example, don't check that one entity is in range of another each frame in Lua (I mean, this is fine for one entity, but in general when you're scaling up your game you need to not think like this). Instead, tell your C++ engine to notify you when the two entities get within a certain distance of one another. In this way, Lua becomes the high-level controller of game logic, dispatching high-level commands and responding to high-level events, not carrying out the low-level math grind of trivial game logic.
Be wary of the advice that 'mixed code' is slow. The Lua C API is lightweight and fast. Wrapping functions for use with Lua is, at worst, quite easy (and if you take a while to understand how Lua interfaces with C w.r.t. the virtual stack, etc, you will notice that it has been designed specifically to minimize call overhead), and at best, trivial (no wrapping required) and 100% as performant as native calls (thanks, LuaJIT FFI!) In most cases I find that a careful mixture of Lua and C (via the LJ FFI) is superior to pure Lua. Even vector operations, which I believe the LuaJIT manuals mention somewhere as an example where code should be kept to Lua, I have found to be faster when I execute via Lua->C calls. Ultimately, don't trust anyone or anything but your own (careful) performance measurements when it comes to pieces of code that are performance-sensitive.
Most small-ish games could get away just fine with game state, the core loop, input handling, etc. done entirely in Lua and running under LuaJIT. If you're building a small-ish game, consider the "move to C++ as needed" approach (lazy compilation!) Write in Lua, when you identify a clear bottleneck (and have measured it to make sure it's the culprit), move that bit to C++ and be on your way. If you're writing a big game with 1000s of complex objects with complex logic, advanced rendering, etc. then you'll benefit from more up-front designing.
Best of luck :)
About the performance of 1: if main.lua does not change, load it once with lua_loadfile or loadfile, save a reference to the returned function, and then call it when needed.
Most of the performance will be lost through the binding between Lua and C++. A function call will actually need to be wrapped, and re-wrapped, and like that a couple of time usually. Pure Lua or pure C++ code is usually faster than mixed code (for small operations).
Having said that, I personally didn't see any strong performance hit running a Lua script every frame.
Usually scripting is good at high level. Lua has been used in famous games for the Bots (Quake 3) and for the User Interface (World of Warcraft). Used at high level Lua micro-threads come handy: The coroutines can save a lot (compared to real threads). For example to run some Lua code only once in a while.
I have been thinking about starting a side project at home to exercise my brain a bit. Reversi looks like a simply game, where mobility has a profound effect on game play.
It is at least a step up from tic tac toe. This would be a single player against an AI of some sort.
I am thinking to try this in C++ on a PC.
What issues am I likely to run into?
What graphics library would you recommend?
What questions am I not smart enough to ask myself?
Issues...
Well, just be sure when writing the strategy part of the game, not to simply do the move that gives you the most pieces. You must also give weight to board position. For example, given the opportunity to place a piece in a board corner should take priority over any other move (besides winning the game) as that piece can never be turned back over. And, placing a piece adjacent to a corner spot is just about the worst move you can ever make (if the corner space is open).
Hope this helps!
In overall, issues you will end up running onto will depend on you and your approaches. Friend tends to say that complex is simple from different perspective.
Choice of graphics library depends about what kind of game you are going to write? OpenGL is common choice in this kind of projects, but you could also use some GUI-library or directly just use windows' or xorg's own libraries. If you are going to do fancy, just use OpenGL.
Questions you ought ask:
Is C++ sensible choice for this project? Consider C and/or python as well. My answer to this would be that if you just want to write reversi, go python. But if you want to learn a low level language, do C first. C++ is an extension to C, therefore there's more to learn in there than there's in C. And to my judge, the more you have to learn onto C++ is not worth the effort.
How do you use the graphics library? If you are going to do fancy effects, go to the scene graph. Instead you can just render the reversi grid with buttons on it.
How ought you implement the UI, should you use the common UI concepts? Usual UI concepts (windowing, frames, buttons, menubars, dialogs) aren't so good as people think they are, there's lot of work in implementing them properly. Apply the scene graph for interpreting input and try different clever ways onto controlling the game. Avoid intro menus(they are dumb and useless work), use command line arguments for most configuration.
I yet give you some ideas to get you started:
Othello board is 8x8, 64 cells in overall. You can assign a byte per each cell, that makes it 64 bytes per each board state. It's 8 long ints, not very much at all! You can store the whole progress of the game and the player can't even notice it. Therefore it's advised to implement the othello board as an immutable structure which you copy always when you change a state. It will also help you later with your AI and implementing an 'undo' -feature.
Because one byte can store more information than just three states (EMPTY, BLACK, WHITE), I advice you will also provide two additional states (BLACK_ALLOWED, WHITE_ALLOWED, BOTH_ALLOWED). You can calculate these values while you copy the new state.
Algorithm for checking out where you can put a block, could go the board through one by one, then trace from empty cells to every direction for regex-patterns: B+W => W^, W+B => B^ This way you can encapsulate the game rules inside a simple interface that takes care of it all.
As the guys were suggesting my idea of telling you for thinking first for algorithms and the game logic. next answer for me was the graphics library, it depends on your target platform, programming language, framework etc. But as I suggest is using C# with Cairo 2D graphics library which you can achieve this using Mono framework (which then you can target all three major operating systems for your game to work) -> www.mono-project.org. Meanwhile I found this I think that and this kind of resource will help you: http://home.datacomm.ch/t_wolf/tw/misc/reversi/html/index.html. But if you finish this, you can try implementing Sudoku.
As mentioned by others, I would begin by getting a deep understanding of the gameplay and strategies, and the algorithms involved. This link may be useful to you, it describes basic Othello strategy and algorithms:
http://www.site-constructor.com/othello/Present/Basic_Strategy.html
You will want to look into minimax with alpha-beta pruning if you write an AI to play against. Your favorite search engine will have much to say on the topic.
After you've taken a whack at the game logic yourself, go read chapter 18 of Peter Norvig's outstanding book Paradigms of AI Programming. (Source code here.) It has a rather short and extremely readable program that can kick just about any human's butt; you ought to learn a lot by comparing your solution to it.
There are tons of libraries out there but as far as I can think your game is going to need event and graphics libraries....and a sound library for more fun!
Allegro 5 is a best choice...Its an All in one library.
http://liballeg.org/
though It is written in C language you can create Object Oriented programs.
and A tutorial for this...
http://fixbyproximity.com/2d-game-development-course/
or you can use low level APIs like.. OpenGL for graphics.
OpenAL for sound.
glfw for events.
but OpenGL is a big deal because you have to create your own sprite sheet handler and all that 2d stuff.
Go with allegro...Complete your game and then go for OpenGL!
Reversi should be a very simple game to implement. It is perfect to learn some basic algorithms of games theory (specifically min-max) during the implementation of the AI.
One thing to note on the AI is that it is perfectly possible to make a perfect AI for Reversi (one that always wins no matter the moves of its opponent). So on the strategy side, if your AI loses, you still have work to do :)
I wrote a reversi game many years ago, when I was still at school. Its strategy was very simple, it just went for the maximum number of pieces, but weighted so it preferred the edges and particularly the corners and didn't like squares that risked giving away the corners.
This worked fairly well against people who hadn't yet worked out what it was doing, but once you had it was very easy to use its strategy against it. I'm not proud to say, however, that it beat me the first few times even though I'd written it!
A proper AI with a few moves of lookahead is far more complicated. Should be an interesting problem, but at the time I was more interested in the user interface.