A computerised environment can be anything from a blank arena, a maze, a series of platforms viewed side-on, or a fully realised 3d world.
Normally, the player of a game negotiates the game-world, taking advantages of positive items (power-ups, coins etc) and avoids negative ones (baddies, holes, explosions etc) This negotiation is normally performed through use of a control device such as a gamepad, joystick or mouse.
Instead of providing the player with a direct interface to controlling their character - the game instead provides them with a simple decision interface that allows them to provide their character with a "control script". Having set up the configuration, the player then sits back and watches as their character blunders about, following his user-generated instructions.
The gameplay would start off on simple levels, allowing the player to use relatively simple rules such as: Scan 30° in front - can I see anything? ...If yes, ......Is it something good? ............If yes - then turn to face, and continue forward motion. ............If no - then turn away and retreat. ...If no, turn 15° to the left and go back to start.
The script is passed on through each level, providing the player with an opportunity to tweak and rewrite their script as they go along, and their character encounters ever trickier opportunities and obstacles.
A multi-player "battle" mode allows 2-many players to enter their scripts into a given arena, and their characters to battle it out for supremacy.
A sufficiently open sandbox style environment engine might allow particular game styles to emerge - for example, instead of a direct "battle", you might place your characters into a racetrack style arena, and have them negotiate a course - the first to complete a given number of laps wins. By tweaking friction/propulsion variables, and some of the graphics, you could create space-battles, naval skirmishes, or inter-ant warfare.
Initial thoughts picked up from an annotation on [nineteenthly]'s Neurotic Pacman idea.-- zen_tom, Dec 04 2009 Halfbakery: Neurotic Pacman Neurotic PacmanThanks to [nineteenthly] and [hippo] [zen_tom, Dec 04 2009] Wikipedia: Core War http://en.wikipedia.org/wiki/Core_War [jutta, Dec 04 2009] Wikipedia: RoboWar http://en.wikipedia.org/wiki/RoboWarThe Core War entry linked to this, but I don't know anything about it - it does seem closer to the idea. [jutta, Dec 04 2009] ACM Queue online programming competition http://queue.acm.org/icpc/Write a player in C++, C#, or Java, and compete with others in a game called Capture for bragging rights. [jutta, Dec 21 2009] http://0x10c.com/ http://0x10c.com/An upcoming game from Notch (author of Minecraft) featuring a fully programmable 16-bit CPU emulator (which presumably will be) in control of your ship's systems. [zen_tom, Apr 27 2012] MMORPG_20ScreenSaver [FlyingToaster, Apr 27 2012] Code & Conquer http://codeandconquer.co/"Be part of the game by programming the strategy of your army." [zen_tom, Sep 04 2013] Yes, OK, i like. There are some games which are a little like this. For instance, Bamzooki and probably Spore (never played it) have a fairly limited number of options and an environment. You seem to have some kind of AI in mind here though, am i right?-- nineteenthly, Dec 04 2009 Excellent idea, like a more arcade game version of Conway's Game of Life.-- hippo, Dec 04 2009 Years ago, I started off making a physics sandbox - objects would float along, bumping into one another and producing realistic(ish) collisions. It was quite good fun.
Then, I added a spaceship - think asteroids - The triangle could be steered using the left/right keys to change orientation, Ctrl for thrust and Space to fire little red triangles out the front.
Initially, the "baddies" were just big circles that bumbled along on their linear tracks, bouncing realistically against the walls, each other, and the spaceship.
Then, I added a bunch of blue triangles, and programmed them to operate in a swarm (look ahead, find a target like myself, try to keep close to that target, if I can't find a target, rotate to the left and look again) but ones that reacted to (either by going towards, or by running from) the player's spaceship.
It was eye opening how, with only the tinyest set of rules, I could create really quite lifelike behaviour, albeit on a 2d screen. It would be cool to have another crack at something like that.
So yes, AI, Conway's Life, Emergent behaviours - all that exciting stuff, only in computer game form.-- zen_tom, Dec 04 2009 I am no programmer, but i did once have an idea for Breakout in orbit, so the paddle orbits Earth and shoots at bricks which are also orbiting, all in ellipses and obeying proper laws of motion. Can't do anything with the idea of course because i'm an inept programmer and have never grasped OOP.-- nineteenthly, Dec 04 2009 //have never grasped OOP//
Really? It's an exciting concept - rather than coding from a massively top-down; do this, then this, then that, sort of paradigm; you define the architecture of all the objects that you want to interact with one another, including the environment (essentially as a great big object that contains and manages all the little ones by defining all the protocols through which they will interact) and then let them get on with it.-- zen_tom, Dec 04 2009 This reminds me of "Core War", a game some engineers at Bell Labs came up with in the mid-80ies. It's played between programs written in a language called "redcode", with computer instructions occupying places in linear memory in the same way chess pieces occupy places on a board. It's not so much self-contained robots battling but two programs - the more territory you own, the more complicated your code can be; but the more territory you own, the more vulnerable you are to instructions lobbed into your code by the enemy. I've never actually played, but it struck me as a great teaching tool not just for machine programming, but for all kinds of deep software engineering and systems design lessons.-- jutta, Dec 04 2009 Forth is something i understand (mentioned in your link, [Jutta]), and i've played Core War.
[zen_tom], i've read books on it and looked at source code, and it doesn't get any clearer. It also feels like a lack of control, somehow, and i probably superstitiously believe it's responsible for unnecessarily large bits of object code, and i know memory isn't the scarce resource than it used to be but i can't shake the idea that that's offensive and messy, but to be honest i don't even like the ideas of virtual memory or privileged op-codes, so i'm clearly a bit screwed up.
But OOP - it never gets any clearer to me, and i don't know why! Actually, it might be the use of analogy. Most attempts i've seen which try to explain it talk about something like a radio being an object, then a TV being an object with extra properties added to it, and so on. But those are, in a sense, instantiated physical items out there in the world and not objects in the programming sense, aren't they? How can they get on with it if you don't tell them what to do?
The first time i saw Program Manager, i thought there seemed to be some kind of theme going on where everything seemed to be sort of turned into variables which the user could tweak, which applied to the applications as well as and i wondered then if there was a connection with OOP there.
I feel like i can sort of glimpse something but it always eludes me. I look at, say, a bit of Java or C++ code, and it just seems to be declaring that there are all these things and they don't seem to be told to do anything. I know not all programming languages are imperative, for instance Prolog and APL don't seem to be, but - aarrgh!-- nineteenthly, Dec 04 2009 Many years ago, I was into playing MUDs (Multi User Dungeons), which were (do they still exist?) multiplayer text adventures.
The typical way to connect to a game server was through a telnet program, *but* there also existed alternative clients programs, which could programmed by the user.
One of the most useful/interesting ways that such a client could be programmed, was to tell it to look out for a particular bit of text, and whenever the game server sent that text to the client, the client program would send back a command, just as if the player had typed that command himself.
Thus, a player could program his client to play the game without his intervention.-- goldbb, Dec 08 2009 RoboWar is a class board game, [Jutta], where you take the part of robots racing on the floor of a giant factory. Conveyor belts, timed electrical traps and pushers add spice to the tactical challenge, as does upgrades that act as weapons.
Each player draws so many movement programming cards, orders them and then each player plays their cards in order interspersed with the other players. Damaged bots have certain of their programme cards stuck so they can't be replaced.
Played it with a gaming group of fellow programmers. It used to make my mind melt.-- Aristotle, Dec 09 2009 [Nineteenthly] - it all depends on your programming style - some programmers are "functionistas" - they write relatively small, discrete bits of code that describe some process that can then be called from higher up in the main code-line.
Real "functionistas" build and haul around with themselves entire toolkits of functions that do certain jobs, reliably, that can be slotted into properly formatted main code-lines. After a while, each coder will develop a further style based on their own personal Armada of code.
An ideal main-line of Functionista code would probably look like this:
Start: Loop While StillLooping: ThinkSomething; DoSomething; ObserveResults; End Loop: End:
It's super-simple, all the underlying functions take care of the bits that they're supposed to do, leaving the main-line clean, simple and unencumbered by details.
A functionista will deal with all the detailed stuff at as abstract level as possible, in order to be able to reuse code and add a useful extra to their own personal toolbox.
My "toolbox" of functions works a certain way, which seems perfectly sensible to me, but which is entirely undocumented and which might be tricky for someone else to pick up and use.
Java and other OOPs define a means to commonly wrap these snippets into easily recognisable lumps that provide ease of use between programmers.
Imprinting this philosophy into the code just formalises what lots of programmers were doing already and tacitly approves this "functionista" programming philosophy.
What's more, and it's this that I expect is the driving force behind its commercial acceptance, it allows a programme manager (i.e. someone who manages the development and implementation of a system according to their available human resources) to easily break a task into cleanly delineated, discrete components, each of which can be built and tested independently, by different people, in parallel, before finally being assembled into the overarching system proper.
To expound on your radio and tv analogy examples - both of those 'objects' have common control interfaces - for example, "switch on", "tune to channel x" that might belong to some more abstract superclass of object "broadcast receiver". That interface could be thought of as a sort of abstract object of itself - if you decide that "switch on" or "tune to channel" were going to be common across multiple 'objects' (but you don't necessarily know what those objects are going to be) you could code these bits up front and then, retrospectively apply them to future objects that fit the same pattern, like 'dvd player' or 'cb radio'. This ability to code common patterns, to perform this kind of abstraction is sometimes called 'inheritance' - and is another feature of the OOP design model, allowing you to let the object taxonomy (that you have to manage yourself, you decide how this architecture is going to work, based on the problem at hand) take the strain of having to recode things, and also to avoid the problem of having differently accessible bits of code for what could have been an homogeneous design pattern.-- zen_tom, Dec 09 2009 Every game that has "non-player characters" that interact with the players ... --those NPCs are controlled by scripts exactly like this Idea proposes.-- Vernon, Apr 27 2012 //NPC's// true; I've even got an "all npc" screensaver idea<gratuitous link>, *but*...
this idea is that programming an npc is the gameplay, with higher-ability programming constructs available at higher levels of the game; geeky [+]
[zt]'s newest <link> looks cool: emulating a computer evens out any speed difference between players' computers. I vaguely remember a tank-based game (probably <jutta>'s 2nd link).-- FlyingToaster, Apr 27 2012 random, halfbakery