Sign in to follow this  
  • entries
  • comments
  • views

Boring Entry....

Sign in to follow this  
Sir Sapo


Hey everyone!

Not much to report tonight, I've been busy at work making working demo for you guys, and unfortunately that entails an assload of boring bug fixes, so not much new stuff has been added to the game, although there are a few items I'd like to talk about.....

The Tree Plopper
This is a pretty simple tool I added to the level editor, but it makes a huge difference when creating a level with the editor. Before this tool, you would manually select which tree type you wanted to place, and then you had to manually place each tree at the right point so that it looked like it was sprouting from the ground. It was also a pain in the ass to make a "forest" look realistic, as you had to manually switch tree types to add diversity. Anyways, the "tree plopper" just places a random type of foliage on the terrain when you click the mouse button. It doesn't sound like much until you try and create a lush tropical island without it. In the screeny below you can see the result of about 30 seconds of work, where it would have taken me way longer to do it manually.

I was looking back on my journal entries and I saw that mldaalder had asked about how the scripting works and if I could post a snippet. Well as it turns out, scripting has been my prime focus as of late, and I have quite a few new features I'd like to inform you guys about.

The scripting language in Angels 22 is a homebrewed one that I wrote because I didn't feel like learning another language such as Lua or Python, so thinking that it would be easier to make my own, and that it would be a good learning experience, I rolled my own. It's a very simple system, where the scripts themselves reside in text files, and the game engine parses them in and converts them to "events". Each "event" has a trigger and a reaction (with a few other components I'll get to).

The trigger is essentially what criteria must be met to execute the script. These range from simple ones like "ONSTART" which executes as soon as the level loads, to more complicated ones such as "PLAYERPASTX", which executes if the player has flown past the xposition given in the triggers parameters.

The reactions are what the script actually does, so you can think of triggers and reactions like causes and effects. Like triggers, reactions range from simple, such as "SETLIGHTLEVEL", whihc *gasp* changes the how bright the level is, to the more complex, such as the "PARATROOPDROP" command which consists of 4 parameters for x and y-positions, number of aircraft, drop zones, etc.

There are at this time 2 modifiers that can be applied to any script, the "persistent flag", and the "phase identifier"

The persistent flag is simple a '-' that is placed at the beginning of a script. Essentially it makes the script never go away (unless internally told to do so). This is handy for constant behavior, such as damaging the player if their plane flys past a certain point.

The "phase identifier" is a number in brackets (ie. [2])at the beginning of a script that denotes what "phase" the level must be in before the trigger criteria will even be tested for truth. The "phase" of the level is simply an integer that can be used by the scripter for a multitude of purposes from branching the scripts to preventing actions from occuring too early. The "phase" of a level always starts out at 1, and any script without a bracket in front of it will be tested no matter what the current "phase" of the level. A script with [2] in front of it will only be tested when the phase of the level is equal to 2. The phase of the level can be changed using the "SETPHASE" reaction in a script to set it to whatever value the scripter wants. It may seem like an odd system, but it works well, and gives tons of flexibility to the scripting system without too much added code.

So now that I've gone through the components that makes up a script, here are some sample scripts I grabbed from a test file, along with explanations of their functions:

This script is a persistent one that will damage the player by 2 every time the plane's xposition is greater than 5500. Since the script starts with a '-' it will always do its job, instead of being thrown away after one execution.

This script is a bit more complicated, in that it includes a phase modifier and a string parameter for the reaction. When the phase of the level is equal to 3, the script will jump straigh to the reaction (INSTANT automatically executes), and the script will play the sound of an air raid siren.

This script is odd in that it requires a persistence modifier even though the reaction only last for a determined amount of time. This is a case in which the reaction is required to be executed over and over again until it determines its time is up and it sets its persistence flag to false, and the script is discarded. As you may have guessed, this script simply focuses the camera at (5500,0) for 300 milliseconds.

As you can see, the scripting system is far from a full fledged language, but it is becoming more powerful every day as I add more triggers and reactions to the interpreter. And hopefully it will be user friendly enough to be released with Angels 22 for people to script their own levels in (The level editor will be released as well).

The Demo
As I said before, Mark and I are working diligently to try and get you guys a demo as quickly as possible, but we really want this to be an awesome experience for you guys, so we are spending lots of time scripting cool stuff into the levels and fine tuning the gameplay. If it turns out like we are envisioning, then you guys will be in for quite a treat when we are finally content with it. Sorry its taking so long, but we feel its going to be important to have a demo with the polish people will be able to expect from the finished version.

Well, thats all for now, if you guys have any more questions about how something in A22 works, I'd be glad to answer them, I had lots-o-fun explaining the scripting system, and theres tons of other stuff I could talk about, so if you have a thought, drop us a comment and we'll get back to you. Peace Out!
Sign in to follow this  


Recommended Comments

I'm telling you: You're damn smart! [smile]

Apart from that I was wondering how you do your parsing (or I don't know if that is what I mean). I guess you are using C++ so how do you read in numbers, events and so on and then change it over to methods/functions? Do you use std::string.find() or do you use something else? Can you point me to any tutorial you may have used?

Thanks alot! [smile]

EDIT: It also looks as if the SAM is "floating" above the ground. Maybe you can make the vertices "wield" together with the SAM quads vertices or something like that?

Share this comment

Link to comment
Why thank you!

It does use C++ and std::string, but unfortunatly, I couldn't find any good tutorials on the subject, so I had to come up with my own system, so I don't know if this is the best way to do this....

The way the parsing works is that there is a repository of tokens in the script interpreter that corresponds to each scripting command, so I have something that looks like this for every command:


Then the parser reads each line of the script file in as a std:string, and then does a preliminary search for the two modifiers I mentioned in my entry. The actual code to look for the persistence modifier looks like this:

/*rawscript is a string with the script in it*/
if(rawscript[0] == '-')/*Is the first character the '-'*/
tempevent.persistent = true;/*Make the event persistent*/
rawscript.erase(0,1);/*Get rid of the '-' so we don't have to worry about it anymore*/

After that, the parser searches for the first occurence of a comma, then creates a copy of the string, erases everything after the comma, and then checks to see if the remaining fragment matches any of the tokens defined. Then, the parser looks up how many and what kind of arguments should be found after the command, and then does the same "look for a comma, copy the string, delete whats past the comma, analyze the fragments" that got us the first command. Because we know what kind of data should be expected, we can then atoi() or atof() as needed, and the results are stored in a variable list in the event structure.

Then since we know what type of event we are working with, the interpreter just jumps through a switch statement of all the types of events that can happen, and when it finds the one that matches our own, it executes that code block.

Sorry if thats kinda long winded and hard to follow, the code for chopping up the strings is pretty wierd looking and hard to read, but if you'd like I can post it for your reference, and I'd be happy to help you out if you want to make a system like this.

Share this comment

Link to comment
You may want to consider converting from a std::string to a simple C string and using sscanf on it (or using a sscanf equivalent for std::string, if there is one). Makes a lot of things a lot easier.

Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now