Best Practices

[Canardia]

Often when you develop games, you have many ways to do certain things, and then you find the optimal way, but often forget it again, until you remember it again. So to have somekind of reference of those best found ways to do things, and also a short description why it is indeed the best way, I want to collect in this thread all kinds of ideas what people have found to be the optimal way of doing certain things.

 

Let's start with how models should be done, especially models with submodels and attached models, like wheels, weapons, doors, and such things.

 

Suggestions:

 

 

1.) Models

 

1.1.) All moving, rotating and removable parts of a model, should be separate models (=separate gmf file).

 

It is easier to access each part separately, and to manipulate them via entity or physics commands. When you have multiple same parts, like wheels, then it also consumes less memory, since the part will be instanced. This also allows customization of instanced complete models, since its parts can be different.

 

1.2.) Components of a model should be always assembled via its Lua script.

 

The Lua script is just as easy to update as a config file, so you don't need a seperate config file for each model. You should use named bones in the main model to mark the positions of the parts, and when you don't have bones available you can still do it from the Lua script using part1:Movef(x,y,z), and finally of course part1:SetParent(mainmodel) or part1:SetMatrix(mainmodel) in the UpdateMatrix() method if it can't be parented (for example transparent objects). Also emitters, lights and other components of a model should be assembled in the Lua script.

 

 

2.) Scenes

 

2.1.) Scenes should have a GravityCenter model.

 

Often in games you need to know where the "Up" direction is, for example to make smoke emitters point to the correct direction even when the model where the smoke is attached to is rotating. For this purpose you should first insert a GravityCenter.gmf model into the scene, which will then create a global pivot which is located somewhere at Vec3(0,-50000,0), so each PointEntity(gravitycenter) would be aligned to the "Up" axis (just facing the opposite direction of course, but you can then turn it around using TurnEntity(Vec3(0,180,0)) if you need to).

Since now every scene has this GravityCenter model, you could also store other common settings for all scenes into its Lua script, for example settings which Editor doesn't save in the Scene.sbx file.

 

 

3.) Main Game Programming

 

3.1.) OOP should be used as much as possible.

 

OOP allows to write much cleaner code, reusable code, and less code. So it brings a clear benefit over procedural code. All major languages like BlitzMax, C++, Pascal, Lua, JavaScript, Java, C# support OOP (although in Lua it's a bit "fake", but still for the user and the needs where you use Lua (for models), it's sufficient).

 

 

4.) Version Control

 

4.1.) Always use version control software, even if you don't work with a team.

 

Even if you work alone, you should always use a version control software to make a quick backup of each minor achievement in the game development. You don't even need a server when you work alone, since it just creates a hidden directory in your project folder. Products like Git, Hg, Svn are free and the most popular version control softwares. If you work with a team, it's good for sharing files over the internet, and even collaborating on working on the same files. You can also restore each file from each saved step seperately, so it's not only good for a complete backup of your project, but also to restore some older version which had something you lost in the development process. You can have a project folder on your desktop where you create a icon to push the changes to the repository, so it's only one mouseclick away to create a backup, and it takes (at least with Git) usually less than a second.

 

 

 

 

 

What other suggestion could we add? Also programming practices would be good to have, although I put this into the "Leadwerks Editor" forum since it's more whole game development related, not only game programming related.

[Davaris]

What other suggestion could we add?

 

I don't know if this comes under best practices, but I had quite a bit of trouble getting shaders to work, when I was first learning to use them.

 

So I'd suggest a list of what frag and vert files work together, as well as a link to the wiki with a few more shader samples. I assume this is going to be a sticky topic right?

[L B]

Agreed on all, although I still think Lua for prefabs is an overkill.

[Masterxilo]

or part1:SetMatrix(mainmodel) in the UpdateMatrix() method if it can't be parented (for example transparent objects).

 

You can parent objects that are not in the same world to each other.

 

I don't agree on the gravity center entity, this sounds like a very hack way to do things. What if your objects are below y = -50000?

 

The rest of it really lists good means to achieve things in my eyes.

[Canardia]

You can parent objects that are not in the same world to each other.

Last time I tried it with LE 2.32, the transparency stopped working correctly after parenting cross-world objects.

 

I don't agree on the gravity center entity, this sounds like a very hack way to do things. What if your objects are below y = -50000?

If objects are below the gravitycenter, they would be in Australia, so it works correctly. Without gravity center, people in Australia would fly into space.

[Josh]

I disagree with 1.1, 2.1, 3.1, and 4.1.

[Canardia]

I disagree with 1.1, 2.1, 3.1, and 4.1.

Can you elaborate on that?

What other benefits do you get when not using those methods?

[Mumbles]

3.1 sounds like a plug for LEO. Nothing really wrong with that, but I felt it was overkill. OOP is especially useful when you have several objects of each class.

 

But take the engine itself. How many engines are going to be instanciated at a time? My feeling, "only one". it feels like rather a waste of time to set up all of access modifiers when there is only going to be one engine object.

 

Now entities are a completely different story. Indeed I have made my own "Entity" class (original name, huh?) which basically does what LEO does anyway. But it's necessary for me because one of my entities will be made up of a Leadwerks TEntity and newton NewtonBody* sometimes even a NewtonUserJoint* . To do with structs in a procedural way would probably get messy after a while.

 

That's the main reason I use the C interface. Things like the engine itself where I don't see the advantage of OO, stay as they are. But for entities, where OO feels to have a large benefit, I wrap the procedural bits up into my own classes...

 

If objects are below the gravitycenter, they would be in Australia, so it works correctly. Without gravity center, people in Australia would fly into space.

 

I don't think the engine can handle worlds that big...