h a l f b a k e r yPoint of hors d'oevre
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
Please log in.
Before you can vote, you need to register.
Please log in or create an account.
|
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.
Halfbakery: Neurotic Pacman
Neurotic Pacman
Thanks 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/RoboWar
The 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]
[link]
|
| |
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? |
|
| |
Excellent idea, like a more arcade game version of Conway's Game of Life. |
|
| |
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. |
|
| |
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. |
|
| |
//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. |
|
| |
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. |
|
| |
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! |
|
| |
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. |
|
| |
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. |
|
| |
[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. |
|
| |
Every game that has "non-player characters" that interact with the players ... --those NPCs are controlled by scripts exactly like this Idea proposes. |
|
| |
//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). |
|
| |