I have looked this question up so many times that I am convinced I am missing a huge piece of the puzzle when it comes to integrating LUA into my C++ Game Engine. What I want to do is run my game engine, then while its running I would like to click on my ui and click "add script" and then run the script. That part is easy enough to do but what I DON'T get is how a script that seemingly gets ran in place with lua_dofile could have code that gets mouse input or moves the character based on input. I don't see anyway to do this effectively. Am I supposed to allow the LUA state to be created and destroyed every frame or do I make the script fire every frame? In an application like this:
void init();
void update();
void render();
void end();
How would I use LUA to control the movement of an entity.
Lets say I set up the lua state so that you can write lua code like this:
entity1 = Entity.new()
entity1:setPosition(4,5)
How would I give the script some input from mouse to move the entity to the mouse position?
My overarching question is what is the best way to have a script control my entities in a way that if I supply the Lua State the ability to move my entities, then a scripter could write a "game" (i.e. a interactive runtime application)
To give a concrete example, suppose you wanted to teleport a ball to the player whenever they click the mouse. Here's what you could write to do that in Lua:
local function clickHandler(event)
local x, y, z = event.player:getCoords()
local ball = event.world:getBall()
ball:teleportTo(x, y, z)
end
game.registerEventHandler('click', clickHandler)
To make that example actually work in your engine, here's what you'd need to do:
Create a registerEventHandler function that saves the given callback somewhere C can access it
Create a getCoords function that returns the coordinates of a given player
Create a getBall function that gets a ball in your gameworld
Create a teleportTo method that teleports an entity to a given location
Whenever a player clicks the mouse, run all click event handlers that you saved, with an event object containing the player and the gameworld
And as for this question in particular:
Am I supposed to allow the LUA state to be created and destroyed every frame or do I make the script fire every frame?
No. You create a lua_State when your game starts, load the scripts in it, and then just keep using that state to call the event handlers.
Essentially the Lua scripts define functions to be called at each event. So the host C++ loads the scripts and then enters its main loop and calling back Lua.
See how LÖVE does it.
Related
Im trying to make a game and used a bit of c++ for a grabber and open door function where I bind in both of them the e key called Interaction to theyr respective usage, now im trying to make a dialog box and had to use some blueprint and linked the e button, the same as before to the show ui function but whenever I bind it and start the game my other two c++ bind don't won't work and when the dialog one is deactivated my two c++ one will work. So yeah I was wondering how could I use blueprint and c++ at the same time on the same keybind. I tried for the moment to create a new input on the same key and the [roblem persist and I cannot find any usefull information on the net.
In nutshell, APlayerController::PushInputComponent(UInputComponent InputComponent), this method will help register your Actor, Widget or anything you want to bind input event.
So it is OK that bind same key to multiple Actors' behavior, but you need concern that this KEY will be consumed in default, in your case, after construction of UInputComponent, while bind action, you may set InputComponent->BindAction(…).bConsumeInput = false.
This flag indicates that if delegate calling will consume this key, so lower priority input component is still eligible to trigger.
So I've been learning how to program so I can make games, and, therefor, I've been reading and watching many tutorials. Every once in a while, I'll come across code (c++) that uses a class to handle game events, but nobody has explained why they do this.
It also seems like some programming languages, like C#, automatically use a class for the program's "main."
So what I want to know is if I should be using a class for my game. Why and/or why not?
Here's an example of what this might look like:
class GAME
{
public:
void load_resources();
bool input();
void update();
void draw();
};
int main ()
{
GAME game;
while (!quit)
{
quit = game.input();
game.update();
game.draw();
}
return 0;
}
Thanks for reading.
In terms of game engine design we have something called a Scene system.
A scene normally hold all the GameObjects.
When you send the scene an event it should iterate on the gameObjects and update them all with events (update start end render postrender keyboard mouse scroll resize etch).
But in a much much simpler form of the system we at least want a game class so we can reload the level.
For example when the user enters the game it may take us a min to load all the models and textures and scripts from memory so we dont want it on our main loop we may want to load async and show a loading screen in this case we'll construct the game on another thread.
Or when the user wins and go to the next level we can unload the last level so we simply destroy the Game/Scene and create a new one of the new level.
In short: this kind of approach is used to define states of our application and manage them easily
I've been going in circles for a day now trying to get this going and I'm just getting nowhere. I'm trying to have multiple objects in the scene with individual animations and when I fire a raycast from my player and it hits one, have the UFunction(blueprintimplementableevent) go off on the object that it hits. Please help me this is absolutely stumping me.
What I would do is use a BlueprintNativeEvent. This will allow you to create an Implementation function of the stuff you want to happen in C++, as well as a blueprint implementation, which can be different for each blueprint of that object type.
It is quite simple to use as well, for example, in your character's header file:
/** Called when the player presses the fire key */
UFUNCTION(BlueprintNativeEvent, Category = "Shooting")
void OnHit();
virtual void OnHit_Implementation();
And now your Cpp:
void AMyGameCharacter::OnHit_Implementation()
{
UE_LOG(LogTemp, Warning, TEXT("OnHit_Implementation!"));
// Do whatever stuff you want to do in C++ here
}
Now over in your character / actor blueprint, just go to the event graph, right click, and add the event of type OnHit. Make sure that you make a callback to the parent OnHit event though (right click on the event and hit "Add Call to Parent Function")
If you want an example of this you can look at the C++ Battery Collector series or the docs.
I'm writing simple application for WP 8.1 using C++/cx. My problem starts when I'm trying to do something in some event. For example if I create simple button event "tapped" and I want to do something inside for example change the color of the button background, it doesn't execute in the correct time. I mean that for the code below it will first execute Somefunction() and then change the color of the button.Same happens for example when I try to show message box using message dialog and ShowAsync function.
but->Background = ref new SolidColorBrush(Windows::UI::Colors::Red);
Somefunciton();
You have the background change and the function call in the same function and that function gets executed on one thread blocking it. This thread happens to be the UI thread which gets blocked for the time of your function execution. So you set the button background but the actual change will be applied only when the UI thread could run the render function and it will be able to do it only after your function call ends.
So in terms of program execution the button background gets updated before the call to Somefunciton();. But visual changes are delayed until after the function call is completed so you might think that Somefunciton(); gets called before the background is set which is not the case.
Background:
I'm implementing a COM interface to an existing legacy C++ MFC application. The application is multi-threaded using one thread (main thread) for COM / GUI and one for incoming events from a C-library. The COM interface reflects the possible interactions the user can do using the GUI.
Edit: The COM server is "out-of-process" i.e. COM is implemented by the MFC application.
Problem description:
The COM interface has a function to select an object in a tree-view controller. When an object is selected the user can call COM functions that will use the object to execute different functionality.
Example 1 - What the user see / feel:
Object X is selected in the tree-view using function Y from the COM interface.
X is highlighted in the GUI and function Y returns.
User calls Function Z that will delete object X.
The MFC application is written such that the model many times is tightly coupled with the GUI callback functions for various reasons. For the SelectObject function this means that the object isn't truly selected in the tree-view until a callback function has been fully executed. This means that Example 1 in reality look more like:
Example 2 - What really happens:
Object X is selected in the tree-view using function Y from the COM interface.
Function Y set object X to be selected and Y returns.
A callback function (could be OnSelChanged()) for the tree-view item is called and update all the GUI elements and application model to select X.
User calls Function Z that will delete object X.
This isn't a problem for the user if when normal GUI interaction is used; the callback function is called in a very short amount of time after the user select object X in the tree-view so function Z will remove object X.
When using the COM interface this becomes a problem. When function Y returns the user can chose to immediately call function Z. If the callback function has been called object X will be deleted, otherwise an unexpected behavior will occur.
This is unwanted behavior. A function like SelectObject indicates to the user that when the function has finished executing, an object should be selected without any extra wait.
Solution ideas
I have been trying to figure out solutions to this problem and came up with some possible ideas:
Send event when the callback has finished
This is unwanted because I still think that when function SelectObject is done executing the user should expect object X to be selected, the user shouldn't have to wait.
Rewrite and separate the GUI and model.
Very much something I would like, but there's not time for that. The way the GUI is updated is very much coupled with everything else in the application and would require huge changes.
Have COM and GUI running on a separate thread.
This one is interesting. I don't know if it's possible; I haven't found any information that such a separation is possible. It seems COM is locked to work on the main thread only.
Number 3 is interesting but I lack the knowledge. Has anyone had any similar problem that they solved? I would really like some help with this problem :)