A Simple Scripted Game

[geezusfreeek]

I have always wanted to create a simple engine with scripting capabilities that basically handle different interactions of several sprites on screen and give them different behaviors. This is game development at its most basic concepts.

With an engine like this a simple game could be created that consists of, for example, one sprite controlled by the player and several other sprites that can function as one of the following: enemies, allies, neutral units, or power-ups. Each type functions differently and is visually distinct so that the player can tell the difference. For example, one type of enemy could always try to circle the player to confuse him. One type of ally could always go after one type of enemy, or vice versa. Power-ups can be scripted to avoid all other sprites as much as possible to make them harder to pick up. Some units could be programed simply to closely follow other units, thus creating collisions (that can be manipulated by players' movements to make them hit enemies). When two units collide, different things can happen depending on what type of unit it is.

Another idea could be to make a point-and-click real-time strategy game involving basic units and resources. The difference could be that the enemy team is not centrally controlled, but is merely sent out to follow each unit's free will. Really the main difference between this and the first game would be that action would be slowed down and the player can control more than one unit at once.

A whole set of mini-games could be created by making new scripts and possible some different graphics (although the sprites could be represented merely as different colored shapes).

What sorts of behaviors would be interesting to see in mini-games like this? What other types of mini-games could be made?

[Quicksilver]

How about a game similar to pocket tanks.

[geezusfreeek]

Come to think of it, this could function as a 2D action game development environment. Make a bunch of sprites, give them behaviors with scripts, and set up some winning criteria, and you've made a game.

Input could be easily handled by basic scripts assigned to each key, mouse click, and mouse movement.

Different behaviors could be handled as separate scripts, plus a default script for when there are no triggered "events" pertaining to that sprite. Different scripts can call each other as functions so that more complex behavior can be created. Simple things, such as physics, can be incorporated directly into the environment and different aspects of these things can be toggled on and off.

Sprite scripts could even have the ability to spawn new sprites to make a simple particle system, each particle controlled as a sprite and with a decay rate assigned to them and everything.

Scripts can also be made to control the whole environment, deciding game states and the like.

Graphics and sound can be created in any way possible and simply imported and saved into an archive used by the game. Levels could be created by using sprites to represent both tiles and interactive parts. This can be powerful. For example, if you are making a game in which characters walk around, you can have a road tile and a rock tile. When the character is on rock a script modifies his walking speed to make it slower than if he is on road.

This would make a great environment for action games, a great diversion from RPG-making environments.

[DaFalcon]

Sounds like an advanced version of the Snake Quest engine, GF :-) The difference is that what you described should have better collision detection than simple tiles, and some things like particle effects would probably be easier in your theoretical environment, but it has been done with Snake Quest. We've even had people use the two-player snake controls as inputs for the single player, effectively executing scripts on a button-press.

Ededed has done some remarkable things with the scripting system, as has "our" user, Don Joe, who has made some of the best SQ level sets ever created.

Just an observation :D

[geezusfreeek]

That's why I said tiles should be treated as sprites, for advanced collision detection.

[AJ Infinity]

Still interested in making this, geezusfreek? How bout a visually oriented, drag n drop, easy to code, scripting system in the style of RCX Code (the program used to program Lego robots). Give it a polished aqua UI and do it in Cocoa Java and then I'll most likely help.

/ / AJ Loves the idea / /

even better: use RealBasic. ColdStone was done with RealBasic. The Green Machine was done with RealBasic.

[ERaZer]

The Green Machine is slow as hell, and Coldstone aint that fast either and still Coldstones engine is C/C++. It shutters on a g3 300 mhz even tought it uses not so advanced 2d...
But if you make the engine in a faster language then RealBasic its good, but making it fully in RealBasic is a bad idea.

[geezusfreeek]

I never intended to make it. It was just something to think about. I was thinking a bit higher level scripting though, like instead of manually doing a bunch of collision math and stuff, the collision detection is done as an event triggered when two sprites collide. Maybe even a scalable physics engine built right in, etc.

[FCCovett]

Yeah, you could cash out $1,200 on Macromedia Director, but I don't recommend it...

[Mark Levin]

This sort of high-level scripting (objects are created, configure basic building blocks, and act on callbacks from the native simulator code) is basically what I have in mind for S2 :D

[AJ Infinity]

Originally posted by ERaZer
The Green Machine is slow as hell, and Coldstone aint that fast either and still Coldstones engine is C/C++. It shutters on a g3 300 mhz even tought it uses not so advanced 2d...
But if you make the engine in a faster language then RealBasic its good, but making it fully in RealBasic is a bad idea.

According to ColdStone's splach screen, it's "Made with RealBasic. I've heard about the Green Machine being slow. (I've also seen how slow RB is)

[ERaZer]

Yeah, the whole Coldstone IDE is made in realbasic. The engine however is made in C/C++.

[ededed]

drag n drop NONONO!
I think it should be python because that looks easy.

It would not exactly be like SQ because if it was then you would have a drag n drop scripting language which should be avoided at all costs. But it would be as extendable as SQ except not grid based.
There should be a console that lets you enter or test commands and scripts in the game.

I made a nice java thing a long time ago, it reminds me of this. You could drop as many bombs as you wanted anywhere then set any off. They would take a short amount of time and you could get nice chain reactions. I image this type of thing an the kind of things seen in SQ as well. Another nice thing would be to have a flammable image so someone could drop petrol and then set off an explosion and the some sort of fill algorithm would fill the petrol area with fire then cause things nearby to burn.

[geezusfreeek]

You've got the idea ededed.

[w_reade]

Do have a look at OSC's Lua Smiley Tag code. It'll seem a little bit confusing at first, and then you'll suddenly start getting very excited indeed, if you've never actually done anything with scripting before. It's an education ;).

[AJ Infinity]

Originally posted by ededed
drag n drop NONONO!
I think it should be python because that looks easy.

It would not exactly be like SQ because if it was then you would have a drag n drop scripting language which should be avoided at all costs. But it would be as extendable as SQ except not grid based.
There should be a console that lets you enter or test commands and scripts in the game.

I made a nice java thing a long time ago, it reminds me of this. You could drop as many bombs as you wanted anywhere then set any off. They would take a short amount of time and you could get nice chain reactions. I image this type of thing an the kind of things seen in SQ as well. Another nice thing would be to have a flammable image so someone could drop petrol and then set off an explosion and the some sort of fill algorithm would fill the petrol area with fire then cause things nearby to burn.

Nonprogrammers would like a drag n drop UI. Programmers (like me) would want hard core ActionScript style scripting.

[ededed]

No I dont think anyone would.
After looking at Lua I think that would definatly be the best thing to use, it is very simple and very extendable.

[AJ Infinity]

Then why was RCX Code and Mindstorms so successful? Huh? www.lego.com/mindstorms

I know people who are scared of programming but then when they use a visual editor (like the PC only GDE RolePlayingMaster) they get along very well.

You've never seen RCX Code, have you?

RCX Code is just a visual interface to Mindscript. NQC (Not Quite C) is a C-style language for programming Mindstorms robots. Yet, most people know about RCX Code and not about NQC.

Maybe a visual interface to coding Lua sounds good. Maybe one like VisualBasic?

[furballphat]

I have Lego Mindstorms. Practically the first thing I did after installing the software and making a few robots was to search for a way to actually code the robots rather than drag funny shaped blocks which make a clicking noise and right clicking them to bring up an animation to change parameters.

Also, RCX code is supremely basic. You can't even define variables with it. I think if NQC came with Mindstorms, a lot of people would choose to learn something a little more difficult to be able to more with their code.

[DoG]

I think you would enter history as the brightest mind of the computer age, would you find a way to replace C code with unambigous graphics. But then again, there are people who do argue against graphical user interfaces. The problem is, anyhow, that the more features you have, the more control you need, and it is quite difficult to implement that graphically without creating a big, gooey mess.

- D.G

[AJ Infinity]

Originally posted by furballphat
I have Lego Mindstorms. Practically the first thing I did after installing the software and making a few robots was to search for a way to actually code the robots rather than drag funny shaped blocks which make a clicking noise and right clicking them to bring up an animation to change parameters.

Also, RCX code is supremely basic. You can't even define variables with it. I think if NQC came with Mindstorms, a lot of people would choose to learn something a little more difficult to be able to more with their code.

Furballphat, you'd like NQC. It's awesome. It allows you to use the "Windows only" mindstorms with a USB IR tower and OS X!

http://www.baumfamily.org/lego/macmind/


A visual interface to Lua would be good, no?

I think you would enter history as the brightest mind of the computer age, would you find a way to replace C code with unambigous graphics. But then again, there are people who do argue against graphical user interfaces. The problem is, anyhow, that the more features you have, the more control you need, and it is quite difficult to implement that graphically without creating a big, gooey mess.


You are right. I've seen gooey mess before. But, hey, if someone got Kai Krause to do it, it would probably be good (BryceScript for Robots? :D). A visualbasic style bot programming dev environment would be good, also. Or maybe, someone could make a Mac port of the RCX Command Center! (An IDE-style interface to the commandline NQC)

[furballphat]

Yes, I have used NQC.

[AJ Infinity]

You must use RCX Code 1.0 or 1.5 because 2.0 has extensive variable support.

[ededed]

I am happy because I created a cool OpenGL app with Lua script. I will upload it when I can, It is a OpenGL view and it lets you put lines anywhere. But its good because it build a gllist from the lua script and I have got a parametric mobius strip and a tree generator (made of lines). I like lua because you can return several variables and that is very useful in game scripting.

I think a good game to script would be a game in the vague style of GTA1/2 but that allows you to burn stuff and put slidey oil things everywhere.

[AJ Infinity]

Cool. When I get RF's deformable terrain system to work, I'll be happy also. :D

[ededed]

You can see a simple Lua/OpenGL example here, that might inspire people to use lua instead of some horrible drag and drop language:
http://www.geocities.com/ed72678954/index.html

[AJ Infinity]

Horrible? :???: :rolleyes:

[w_reade]

:mad:

How is it horrible? Criticise constructively, if you please.

[w_reade]

I can't build it; it complains as follows:

...blah blah...

Completed phase <DeriveAndCompileSources> for <DeriveAndCompileSources>OpenGLStuff.app
StandaloneExecutable /Users/wibble/Desktop/Download Destination/OpenGLStuff/build/OpenGLStuff.app/Contents/MacOS/OpenGLStuff


StandaloneExecutable.LinkUsingFileList /Users/wibble/Desktop/Download Destination/OpenGLStuff/build/OpenGLStuff.app/Contents/MacOS/OpenGLStuff

/usr/bin/gcc3 -o "/Users/wibble/Desktop/Download Destination/OpenGLStuff/build/OpenGLStuff.app/Contents/MacOS/OpenGLStuff" "-L/Users/wibble/Desktop/Download Destination/OpenGLStuff/build" "-F/Users/wibble/Desktop/Download Destination/OpenGLStuff/build" -filelist "/Users/wibble/Desktop/Download Destination/OpenGLStuff/build/OpenGLStuff.build/OpenGLStuff.build/Objects-normal/LinkFileList" "-arch" "ppc" "-prebind" "-framework" "Cocoa" "-framework" "OpenGL" "-llua" "-llualib"

ld: can't locate file for: -llua
...failed StandaloneExecutable.LinkUsingFileList /Users/wibble/Desktop/Download Destination/OpenGLStuff/build/OpenGLStuff.app/Contents/MacOS/OpenGLStuff ...


It also warned about some directory in /Users/ed/ not existing, but I removed it from the search paths, and that got rid of that warning. Any ideas? Did llua (whatever that may be) live somewhere in /Users/ed/?

[AJ Infinity]

Originally posted by w_reade
:mad:

How is it horrible? Criticise constructively, if you please.

Yeah, ed^3

[OneSadCookie]

w_reade: try removing liblua.a from the project and adding the one that was in the archive (I think there was one in the archive...).

Incidentally, you can change what the program draws by using "show package contents" in the finder, removing Contents/Resources/main.lua, copying in one of the other example scripts and renaming it to main.lua. No recompile required ;)

[w_reade]

ok, explanations in order.

AJ: actually, I was having a go at you, but only because I didn't see the question mark. I thought you were saying ededed's stuff was horrible. Sorry for having a go :blush:.

ededed: I'm as suspicious of drag'n'drop scripting as you are, for basically DoooG's reasons. Sorry if you thought I was having a go :blush:.

I'm going to bed now.

oh, hang on... OSC, isn't not having to recompile the whole point and joy of scripting languages?

[OneSadCookie]

OSC, isn't not having to recompile the whole point and joy of scripting languages?

Yep. I was just pointing it out for people less attentive than you ;)

[ededed]

I think you might have to install Lua to get that example to work. I should have given a ready built example with it bit I didnt think that far ahead. But anyway I think this game should be coded with Lua because that way there could be a console that would let you cheat, skillfuly:

Spawn("Dark Rider", 3, "Red team")
or ExplodeTerrain(getXY("base", "Blue Team"), 5000)

[w_reade]

I thought so too, but it didn't work. Nor did OSC's suggestion, until I did as he suggested with the freshly-make'd liblua.a from lua-4.0.1/lib/

The version in the archive, and the version in SmileyTag, both complained about... hell, I've forgotten. Something-or-other being out of date.

Anyway, that's a lovely mobius strip.

[OneSadCookie]

Static libraries (.a files) on Mac OS X are for some unknown reason dependent on their modification date. That means that if you move them or whatever, their modification date becomes newer and the library becomes invalid. This can be fixed by doing as the error suggests, and running ranlib on the .a file from the terminal.

[AJ Infinity]

Like I said nonprogrammers like drag n drop systems. My friend equates programming with math and since he doesn't like math he won't touch C++, Java, or Lua, even. But then, he uses Mindscript in RCX Code and doesn't notice that he's programming:???:. Do gamers (don't answer this one, OSC) mess with the Python scripts in Kiki the Nanonbot? Do nonprogrammers mess with scripts in other games?

[Chris Burkhardt]

I think AJ is right, lots of people would prefer a graphical interface where they could drag things around to script their game entities. But some other people would want more control than a drag-and-drop interface could provide, and also wouldn't mind investing a little time learning a scripting language. I say offer both ways, a GUI for people who want to quickly "program" simple behaving sprites, and the ability to write scripts for more complex behaviors. :cool:

[AJ Infinity]

Exactly. Lego MIT spent who knows how long designing RCX Code as a GUI for Mindscript. No Mindstorms user really knows about Mindscript programming but they know RCX Code.

[AJ Infinity]

Notice: Most commercial games (Warcraft 3, Tomb Raider 5, Starcraft) commercial games use visual editors and not scripting languages. Gamers who don't program prefer visual editors. The War3 World Editor is one of the best visual editors I've ever seen.

[Shivers]

meh, the myth 2 editors (fear and loathing) combined with a bunch of third party tools spurred the creation of a crapload of cool maps, conversions and such. "green berets" was a conversion that was actually released. These maps and conversions have been sold in "Myth: The Total Codex" and "Myth 2 Worlds". This is also how a lot of people got into game dev, myself included.

....take your warcraft 3 editor and go home! lol :D

[Mark Levin]

Um, TONS of Myth 2 mods were released. Green Berets was just the first *commercially published* mod (more like the first 3rd-party game using the Myth 2 engine).

To drag this back on topic, the Myth 2 editors were about 75% drag-and-drop (this was sufficient to build multiplayer maps), but scripting was required for anything more advanced than "this bit of scenery goes here".

[Shivers]

i know, i made myth mods, green berets was just a really good myth mod so it got released...it wasn't really that good tho:cool:

[AJ Infinity]

Limited scripting is in many editors and it's helpful many times. If Interface Builder had scripting, I'd be happy. :D

[Mark Levin]

Originally posted by Shivers
i know, i made myth mods, green berets was just a really good myth mod so it got released...it wasn't really that good tho:cool:

I think we're using different definitions of "release"... Tons of Myth mods were posted to the web for free download, Berets was the first one to show up in a shrinkwrapped box on retail shelves.

[Shivers]

okay man, we both know what we're talking about...it doesn't matter that we are using different definitions because we both already know what we are trying to say...lets not pursue this anymore