It’s been a while since my first blog post. Lots of things happened in the meantime, most of them slowing down the development of the editor and game engine. However, I’m back and I bring good news! Remember those area checks (triggers) and scripts I was talking about at the end of my previous post? Well, they’re here!
Area checks have been in there for a while. Scripts were working as well about 2 weeks ago. In the level editor that is. Getting them to run in the preview tab (actual game simulation) was quite tricky. It took a lot more than I anticipated, but now they’re getting along quite nicely.
So how do those exactly work? Quite simple actually. Each prop can have an unlimited number of areas defined inside and each area can have its own script. For now, scripts are run only when the player enters the area. In the near future, each area will be able to have lots of scripts attached, based on the triggering condition: time greater than something, player has certain properties, per-frame, etc.
Scripting system
The scripting system is a very powerful tool and this means there’s a high chance of over-using it. Scripts, unfortunately, are very slow compared to compiled code, but offer a lot of customization. Obviously I’m trying to keep the best of both. Instead of having scripts rule the game, I plan on keeping them one-shot actions. In other terms, I mean to have the scrips execute as rarely as possible and tell the engine what to do, instead of having the scripts run everything. This keeps the flexibility of the scripts while preserving the speed of the engine. Of course, it’s not free and it’s not as easy as it sounds. In order for the scripts to pull the levers, first I have to make the levers and connect them to something. Time for an example! Let’s say we want to control they movement of the player. The slow way would be something like: “If left key is pressed, move player to left. If right key is pressed, move player to the right.”. This would be defined in the script, which is supposed to run every frame, check the keys and move the player if necessary. Does the job, but it’s very slow. The right way to do this is to run a script once that does this: “Set the left movement key to: Left Key. Set the right movement key to: Right Arrow” and then have the engine run according to what the script configured. Advantages: the engine runs the code (fast), you can set any key for movement (flexible). Disadvantages: the support for this has to be built withing the engine. That means more work for me, but better speed in the end.
Other stuff
Being low on “Programmer Enthusiasm”, I worked on a few small examples which will come in hand quite soon. One is a small (and very fast) particle system. Another is something very similar in concept, but quite different inside the code. Both of those are very useful when the time comes to add in the eye-candy. The last experiment is a small (fast as well) pathfinding system. Not sure how useful this will be in the future, but since I was bored and it only took about 45 mins, I say it was well worth it. Working on a big project and dealing with complicated problems really drains the enthusiasm, but having completed those small experiments with exciting results refills it quickly.
Got a large TO DO list and lots of inspiration, so it’s back to work for me!
I hope this shed some light on the latest progress on our engine. Feel free to use the comment form below 
Tags: editor, game engine, scripting
Glad to see that despite set backs you are still getting the work done in a timely manner. I always find in programming that you can never be 100% sure how things are going to play out. The engine sounds like it is coming together quite nicely. Keep up the enthusiasm! This game sounds awesome!! Cannot wait to see the final product!