Scratch base game logic source code of UnigineScript


Recommended Posts

I am hesitant to switch to Unigine from Darkplaces, due to the fact that I am an artist, not a coder.


QuakeC is what Darkplaces engine uses. I can pretty much look into the neatly written code and figure out how it's done, what it's doing and why (not even being a coder). There is also a full source code of the QuakeC game logic for Quake. There is nothing better and easier to learn by example. Huge archive of the QuakeC tutorials also helps a lot.


I have a license for Unigine I won earlier, but I am having hard time using it because I am no programmer. I have no idea where to start. While I can pretty much make scratch base code using QuakeC (and there are bunch of scratch code available out there from which I can base my game off), I have no idea how to do it with Unigine.


Also, from what I heard, Unigine is no UDK, so an artist can't just jump in and make an indie game without sufficient knowledge in programming.


That being said, I would like to ask if there is such scratch code base in Unigine Script available? (basically something that I can compile, start the game, have a basic menu of New Game and Quit, start new game and spawn in the box level).


Thank you.

Link to post

The best starting places are Passage, Heaven and Tropics demos (also the Oilrush game - if that is available to you). Take one of these and start modifying it.

Ask specific questions here once the pop up.... At least a few of us have been doing this for some years.


You won't need to compile -> Uniginescript is an interpreted language. A typical workflow is...

Your code open in a C++ IDE and Unigine open at the same time.

make changes in the IDE.

save changes

press backspace in the unigine editor to reload your world (running on the new code).


You can prototype some of your logic in a World Expression Object (which will update on the fly - but currently there are some limitations on what that code will be able to do).


To begin with it is much easier to not try and make your game in Editor mode.

With regards to your specific things....


The current easiest way to design User interfaces is using an Xml file (by convention they have the extension .ui) Most of the demos have at least one example of these. If you want to skin the ui elements you will find a bunch of .png files in data/core/gui/. For the box level. You will either want to make the parts in a 3d editor or use the models in one of the demos to get started.


for a spawn point. I would use a PlayerDummy Node take note of the id number... (this will be written in the node editor when you select the node

and use something like.


#define SPAWN_POINT_ID 188 //this is the node id

#include <core/unigine.h> //basic defines etc. you want to make sure this is included somewhere in your game.
#include <core/scripts/utils.h> // getPlayer comes from here
void spawn() {
Player player = Unigine::getPlayer(); // get the current player (engine.editor.getPlayer() in editor mode, otherwise
Node node =; // get the spawn point node
Player spawnpoint = node_cast(node); // we know that this node is a PlayerDummy in a more general case we should check this.
if(engine.editor.isLoaded()) {
   // you don't strictly need this code if you only want stuff to work in game mode
  // here our artists do appreciate being able to test functionality without switching modes.
  // manipulating the editor camera is a little more difficult but can be done by making some indirect calls to the editor script."controlsSetPosition",spawnpoint.getWorldPosition());"controlsSetDirection",spawnpoint.getDirection());
} else {
  // much more direct in game mode.

Link to post

Thanks for the reply. This is a killer line: "At least a few of us have been doing this for some years." It sound depressing.. Seriously :( I feel like I will never be able to make a game on my own using Unigine.


As far as spawning code, how come it doesn't set model and collision box for the player, player's physics, etc. ?

Link to post

example ui file

<?xml version="1.0" encoding="utf-8"?>
<ui version="1.0">
<vbox name="Interface::main_menu" export="1">
 <button name="Interface::start_button" export="1" align="expand">
 <button name="Interface::quit_button" export="1" align="expand">


example world.cpp script.

#include <core/unigine.h>
int init() {
return 1;

int shutdown() {
return 1;

int update() {
return 1;

namespace Interface { //namespaces are primarily used for grouping and organising code
// they are accessed via namespace::object_or_method_name as you have probably already
// seen in the code
 WidgetVBox main_menu;
 WidgetButton start_button, quit_button;
 // these are automatically initialised when the .ui file is loaded.
 // if there is an object with the same name with the arg export="1" included in it
 void quit_button_pressed() {
   // this will close unigine completely. probably not quite what you want eventually.
  // I will leave you to sub in the commands you want here."quit");
 void spawn() {/*code from previous example*/}
 void start_button_pressed() {
   engine.gui.removeChild(main_menu); //call engine.gui.addChild(main_menu,GUI_ALIGN_CENTER)
   // when the character dies etc to show the menu again.

Link to post

Thanks for the reply. This is a killer line: "At least a few of us have been doing this for some years." It sound depressing.. Seriously :( I feel like I will never be able to make a game on my own using Unigine.

In my case I work in an Architectural Visualisation company. We have done a few dozen one-off projects in Unigine in the last few years.


As far as spawning code, how come it doesn't set model and collision box for the player, player's physics, etc. ?

I was giving you the simplest starting code I could. (also I don't need to use player character models that often).

For that use try using either the Corridor demo as your starting point or take a look at the character demo.

I will break down the components of a player character (3rd Person). you can steel most of these from the character demo.

2 files to specify the players controls. one defines the actions the other defines what inputs connect to which actions.

(check out the tutorial for using the input system in the manual).

a character definition file - this defines the players attributes and the animation tree.

a skinned mesh file, and bunch of exported animations - (steel the character demo files for now).

A PlayerActor and A PlayerPersecutor (these will be created for you using the character scripts).

The Player actor is the object that has the physics set on it the animated mesh follows the actor.

The PlayerPersecutor is the one that the screen is drawn from it has the Actor as it's target (I think).


I hope that is not too much information. I have such a class that does a lot of this in a way that is accessible to the artist but I need to finish bugfixing it. It should be done sometime in the next few weeks if you are interested.

Also note that there are new tools currently being built to make this process easier.

Link to post

Hmm.. I can't find Corridor demo neither in the SDK nor on the website. Where can I get it? Also I don't see a Unigine engine's binary in the SDK (and I assume the Editor is embedded into the engine).


Also, what is the very basic folder structure for the Unigine powered game for Linux, Mac and Windows ? (with all the necessary libs, so I could launch the game's dummy on any of those OS and get no error for missing components)


Thank you.

Link to post

Still unable to figure out how to run the Editor. Tried main_x64 in the bin/ folder and got the error:


./main_x64: error while loading shared libraries: cannot open shared object file: No such file or directory

Link to post

Don't run the binary directly (it requires some CLI options to be passed), use SDK browser or standalone .bat/.sh launchers (can be found in "demos" directory).


PS: we'll add the scratch project in the next SDK updates.

Link to post

Adding scratch project sounds awesome! Do you think you could add FPS, side scroller and top-down/iso cam scratch projects?

Link to post
  • 3 weeks later...

Yes, we plan to work in this direction but it will take time.

Link to post

Will be looking forward to see that happen rather sooner :)

Link to post