Programmer's Quest – The Programming RPG

[Chromatix]

I rather like this concept of coding/scripting to get ahead in a game.

It would also be a very good logical progression for a "sandbox" game like X-Universe or ... Elite!  X is already halfway there since it has a scripting engine built in which is extensively used, but it is a rather poor job.  So maybe this would be a good concept for the next version of Elite.

For those that don't know, a sandbox game generally dumps you in the middle of a more-or-less functioning economy, usually in a spaceship and with just about enough cash left over to buy a hold full of the most basic trade goods available.  You can then do whatever you like, for the most part, and the economy and local factions will react accordingly.

In X-Universe, the game usually finishes the built-in plotline only when the player has built up a navy rivalling any of the local major factions, and has corresponding economic power required to build such a thing, and has used it to destroy the Big Bad which was too big and bad for the factions to deal with by themselves (at least not without leaving their flanks exposed to rival factions).  And all of these navy ships are run by remote control.  The other ships in game have pilots.

Reprogramming the various autopilot systems to maximum advantage would be the main focus of a scripting-oriented sandbox game.  The justification could be that the autopilot industry has stagnated into providing only safety-related functions, and you are a bright-eyed startup who is willing to take risks and innovate in order to outcompete the incumbents.  Or the equivalent in plain English.

So while you *can* go and fly a ship yourself, you would soon find a nice safe station to hang out in and run everything remotely.  You could even travel between stations merely as a passenger in one of your own autopiloted ships.

Potentially it would even be feasible to allow designing ships by assembling components and applying engineering and physical constraints.  These would then be built at realistic costs by your own factories (or under contract by NPC factories).

This sort of thing doesn't even need a new language, really.  Lua is powerful enough and designed for embedding in a game.  The trick would be designing the API so that scripts have the correct amount of visibility into and control of the game universe - which is the part that X-Universe games fail at.  This is not an insurmountable problem if approached correctly.

[jeznav]

Abishur,

If I can sum your post, it looks like your going into the realm of game modding. The game engine is the backbone and is restricted from players but the game logic will be barebones but customisable.

If you really want people to use their own language like C, Lua, Python, the game engine will need a bridge interface for said language for the engine which exposes the accessors of the game logic so you can override them.

I'm not sure if I understand code compile checking. Some languages like Lua, Python are interpreters and require a runtime to execute scripts and checks errors as it executes, they are also easier to incorporate into game which is why its popular for game modding. C like languages will have to compile first and upon success it will create a static code which can then be loaded into the game's memory. Think of C's output are plugins that produce dlls or .so object files when the game is run. Lua, Python, Ruby will execute the code directly by interpretation.

This is going to be a huge project, what languages are you planning to incorporate?

Chromatix,

Interesting that you mentioned spaceships, autopilots, I just heard recently that Notch aka Minecraft creator is working on a MMO space game which includes an in-game 16-bit CPU virtual machine that will run assembly code customised to affect how your spaceship will run.

http://www.dealspwn.com/notchs.....x10c-98501

Pretty much what you described, but everything is done at low-level. Someone said that its possible to program a rocket injected with a virus and if anyone doesn't have their shields protected with anti-virus, it can your ship's system down or perhaps change it of-course to a nearby blackhole(game over=rewrite code from scratch). The daunting part for most players is that it will be coded in assembly, but he said that players have the right to exchange code within the game to build economy in exchange of currency. I can see that geekiest programmers will be ranked the richest.

[abishur]

I'm really not thinking about game modding per se.  The idea for "compiling" the code you wrote is really just to check it for errors.  If it compiles correctly then the code is error free (there might be logical errors, but you know what I mean) and you're allowed to use it.

Basically, I want to make users use real code, maybe it's just a pipe dream, but I think it can work (if I could just explain it clearly enough!).  So while they write real code, I know it wouldn't be possible to run their code directly.  Instead I'm thinking that the game is designed to look for key words within what they write.

So we compile it to make sure they've written the program correctly, then we grab key words from it (for, if/then, else, while, and then special in game command words: sweep, attack, defend, use, etc) and throw that into the already existing code for how to handle it.

It is my hope that the program could be written in such a manner that a simple interpreter layer could exist to allow different programming language.  I mean I know not every language uses a for loop with the same syntax, so the interpreter layer would grab the key words and then send them in the correct format for the engine to use.

I think I might have initially shot too high for the game engine Now I'm thinking it would be better to give the illusion of the user inputted program literally controlling things, but now I'm thinking it only grabs the keywords.  The compiling (done by installed compiler outside the game altogether) is to make sure their syntax is correct.  Wrong syntax = no compile = time to go fix it, Right syntax = compile = grab and execute keywords.

[oninoshiko]

I *LOVE* this idea!

Actually, there are some good options for tile-based graphical RPGs out there, I've been playing with cocos2d/python over the last week, figuring out how to do a simulation game (a la SimCity), and it strikes me as a pretty good option for something like this.

It also strikes me as the kind of idea that would work well in a fantisy setting, with some humor on the graphics side, things like a program blowing up and leaving the player covered in soot for a moment, or like Mickey being overwelmed by the brooms in Fantasia... I think there is a lot of potental to have some fun with this!

[jeznav]

Then what your looking at would be a pre-processor. A custom pre-processor would look through the source code (if it has the right keywords?) before it will send it off to the compiler. But then again your diving into creating an interpreter.

Don't forget the external compilers will also produce errors too. Why not just use those to catch errors instead?

If you want to access game commands/keywords from a multitude of languages all you need is to do is expose the game logic(objects, classes, methods) and create an api to bind other languages while using their own compiler. The compiled code can access your game logic this way. No need to create an interpreter to check if the keyword exists or not.

[abishur]

jeznav said:


Then what your looking at would be a pre-processor. A custom pre-processor would look through the source code (if it has the right keywords?) before it will send it off to the compiler. But then again your diving into creating an interpreter.

Don't forget the external compilers will also produce errors too. Why not just use those to catch errors instead?

If you want to access game commands/keywords from a multitude of languages all you need is to do is expose the game logic(objects, classes, methods) and create an api to bind other languages while using their own compiler. The compiled code can access your game logic this way. No need to create an interpreter to check if the keyword exists or not.



Nah, I don't want to do any sort of pre-processor junk.  I'm talking about sending the text directly to an external processor and having it compile (though in one of my other posts, I did say I wanted to use the error message it returned for the user to view later).  The code they created would have the keywords grabbed (ignoring syntax) and pass those keywords along.  An interpreter level would allow quick swapping of language modules.  There would also have to be an area for dialog, but as long as it's clearly documented and marked the basic idea of the dialog could be keep, just updated for whatever language was chosen.

[oninoshiko]

My first thought was Forth,  my second thought was "Everyone RPN Partial not is"

Seriously though, I would think a good approch would be to define it with one language in mind, then expose the interface to other languages later. LUA might be good, Python seems popular. I don't think I'd go with a compiled language here.

What might also be fun is different towns do different languages.

I think you might have to be careful from a gameplay perspective to make sure that user-code doesn't make the gameplay too easy... "HP =+ 10000000". I'm not sure how you would create limitations without making them seem arbitrary.

[abishur]

Keeping it to one language at first is definitely what I'm thinking too.  While I'm partial to C/C++, Python is a close second.

The user code will have limits on it.  For instance I plan on having an approved command word list.  Anything they haven't gained yet won't be useable (That way they can't start the game using the most powerful commands or spells).  While you can do statements that say if your HP is less or greater than something else, then do an action, you won't be able to say make my HP = such and so.

[Chromatix]

That's easy: data hiding and encapsulation, the cornerstones of object oriented programming (and, conveniently, available even in C via "file scope").  You don't expose the variables themselves to the player, only getters and manipulators.

The getters can check if the player is supposed to be able to see this information, and return an error or inaccurate information otherwise.  Good example: maps.

The manipulators can simply not exist if the user isn't supposed to do that kind of thing, or they can always have balancing side-effects (eg. you can buff HP, but only by draining mana, thus producing a healing spell rather than god-mode).

Seriously, if you have the time, play around with X3TC and it's script engine - and take away plenty of examples of how *not* to do it.  You can do too much (give money, give reputation, create goods, all out of thin air) and yet not enough (can't track turrets on a fast target *while* firing even if it's a light weapon, can't select a custom aiming angle for turrets, can't replace the stupid autopilot that likes to crash you and your ships into the station they're trying to dock with...) - and to cap it off, the script editor itself will magically cause a large head-shaped dent to appear in your wall.  The "approved" set of ready-made scripts isn't much better.

The basic data model holds even if you give the player a virtual CPU to program in machine code - the CPU is in the ship, and the ship has limited influence and visibility to the outside universe, so the getters and manipulators are the device interfaces to the ship's sensors, engines, weapons, radio and docking clamps.

[JustThisGuy]

I just ran into a programming game that might help out. It's called laby in which you control an ant thru various puzzles with C or python code. It might be worth a look to you.

Edit: added link

[oninoshiko]

Ok! So most of us like this IDEA, but it seems to me that we need to sort out how to make it happen. So what do we need…

Engine (Programming) -  Oninoshiko

Mechanics ("player-script" engine) -

Cartography (World Map) -

Plot Elements (Writing) -

Graphics (Artists) -

Foley (Sound Effects) -

BGM (Music) -

As I said, I've been playing Cocos2d, which allows for easy creation of tile-based games. Although it could do with some documentation improvements, their unit-tests are GREAT for figuring out how to do things. While I'm not particularly partal to Python, this API is just too good ignore. I can probibly hack out a preliminary engine in a week.

So who wants to take a lead prototyping on any of the other areas? I think the things we need to start are some preliminary tiles (graphics), maps, a preliminary "player-script" engine.

The plot elements, foley work, and BGM can be worked on independently, as I shouldn't need them to make sure the rest of the system works, but as soon as that kind of material starts to trickle in, we can work it in.

I really don't have a story to tell, and I'm not an artist. So unless you guys want this to be all lavishly painted stick-figures, with the deep rich narritive of Plan 9 from Outer Space I'll have to depend on you guys for help. If we are going to have swappable script-engines it's better someone else do even the first engine, I think, as that will help force us to really keep them modular.

[abishur]

I can help on the plot, I've put down most of what I had thought of initially, but I certainly don't want to abandon this

[oninoshiko]

Abishur said:


I can help on the plot, I've put down most of what I had thought of initially, but I certainly don't want to abandon this


GREAT! I was really hoping you'd say something like that ;) This is your idea, so I don't think anyone would be better.

I'll start working on the engine over the weekend. I can make some stub functions for the player-scripting engine for now. I took a cue, and the liberty, of setting up a wikia page, because some things dont fit well in this format: http://programmersquest.wikia......kiActivity

Right now it only contains a the list from above (although I'm starting to fill in names of vict^wvolunteers)

[tufty]

Just saw this : http://0x10c.com/

As far as the language / interpreter goes, you would do very well to read Sussmann"s SICP, and / or Queinnec"s "LiSP in Small Pieces".

[abishur]

The game looks interesting.  It looks like they're going the route I was first thinking of with having a full embedded compiler and going one step further by having it on a virtual PC in the game.  I did decide that was needlessly complicated and choose rather to just grab specific approved words out of the user's code.  It gives the illusion that they're running things off their own code, but with much less hassle and with making it far easier to swap computer languages.

[Bakul Shah]

tufty said:


Just saw this : http://0x10c.com/

As far as the language / interpreter goes, you would do very well to read Sussmann"s SICP, and / or Queinnec"s "LiSP in Small Pieces".


I read the first few chapters of LiSP in Small Pieces in small pieces but its exhaustive treatment of the subject exhausted me! May be I had to be writing a Scheme/CL compiler while reading it to really inspire me. But do I think it is bit of an overkill for a programming RPG language! SICP is great if one likes Scheme -- I would certainly prototype such a game in Scheme but most people seem to be more comfortable with C like languages. I am reading Nils M Holm's "Practical Compiler Construction -- a no nonsense tour through a C compiler"  and that may just be at the right level for a subset of C compiler. Even if you "interpret" C like code, you will end up writing a simple compiler (to some pseudocode).

[Chromatix]

I had a closer look at Lua to see whether it could handle running as a large number of parallel virtual machines.  It seems that it can, in principle, using native OS threads (or processes) that each run a separate Lua instance.  This is good because it means not having to solve the Halting Problem.  Just make sure that you give the player a way to manually halt a runaway script, or otherwise include a reasonable timeout in each problem so that infinite loops and implausibly inefficient solutions are caught.

Anticipate that many scripts running in parallel are going to leave little CPU power for running the game interface, and will slow each other down.  If you will need scripts to run in the background for a long period, perhaps waiting to trigger on some event, you'll need to provide a way to do that waiting without wasting CPU time.  A sleep() and a waitforevent() should be good starting points.

My opinion is that attempting to support every possible language is going to be highly problematic, not least because languages like BrainF*** exist.  Instead, pick one language - probably a simple one - and do as good a job as you can supporting that.  Lua seems to be a good candidate for this, since it is a simple imperative language that is specifically designed for embedding into another program.

It is also important to decide key parts of the game universe early on.  Something that is currently missing from 0x10c (by the author's admission) is a mechanism for FTL travel - rather important in an interstellar sandbox game.  Warp drive like Star Trek, hyperdrive like Elite, jump nodes/gates like Freespace or X-Universe, or something else that is novel?  Similar considerations apply to other types of game.

[abishur]

@Chromatrix, it sounds like you're referring to the original idea I had where user created code would be directly run.  I've *long* abandoned that idea   Bakul, is more or less on the right track, the user created code will have key words plucked from it and processed.  It will be *very* basic (I'm thinking first semester) so it won't be too complicated but it will be there.

We've already decided to limit it to a single language (probably python), but my goal is to create it such that alternative languages could easily be implemented (Since the user created code is only having key words picked out, then all you need to do is grab those words and add a layer that takes the syntax and moves it around to match python).  Additional languages will be up to the community to decide on.

Finally, the universe and story on the whole is coming along nicely.  You can visit the wiki that oninoshiko set up to see what we're doing and where we could still use some help.

[oninoshiko]

Now for what Abishur doesn't know. While he's been busy writing (and I think he's made more posts to the wiki then I have), I've been hacking away at this most of the weekend (I managed to hit a couple of bugs in the python framework I'm using... A little time on forums and I'm moveing right along again). I also refactored some transitions 3 times before settling into something I liked.

I have splash-screens, the main menu, and credits (although these are slightly empty, as we could use some more help in a few areas!) working.

I think the next step is to make the first town start to work. There are a couple of resources for free pixel art I might be able to use, at least for the moment. I'm not sure yet if I want to set up a map manually (ugh) to use for testing and writing this core code section, or write a tool for quickly laying out the maps for us (once one is done it will serve as the basis for the other).

I'll do what I can on this, but I'm going to be pretty busy at work this week, and will likely be pretty busy with some spring-yard work this weekend.

[abishur]

Awesome!  For the first "town" do you want to just do a very simple here's a house/screen transition sort of deal to start with (probably not a bad idea just to get some testing done) or do you want the full blown deal?  If you want the full blown deal... I'm no artist, but I could probably cobble together something that *resembles* a hand drawn sketch of a first town (like draw it on a piece of paper and take a picture of it)

[oninoshiko]

Just something like a generic map would be great.

I don't expect what I come up with to be a final map, but since I need to create one anyway, I think I would like to use the effort to be working toward something we can use in game.

Like I said, there are some tilesets I can use which are licesensed for FLOSS use, if we want to later, we can always swap them out.

9+1=2, clearly

[Joefish]

You could consider an icon/token-based programming system.

Two examples spring to mind – the old Playstation game Carnage Heart used a grid where program execution hopped from cell to cell starting from the top-left, branching in different directions at conditional tokens.  When execution reached the edge of the grid, it would flow around the edge to the bottom-right then start again at the top-left.  Though it distracts a little from pure programming as you had to manage optimal use of space against ease of flow, it was a great way of programming visually.  The game offered larger grids or faster flow as upgrades – sometimes even cannily offering a smaller grid but with faster execution.

The sadly defunct LEGO Universe had an interesting but little-used programming system for your own models.  You created simple strips of icons to form a single scripted sequence of actions, each one starting with an 'event' icon (e.g. object is struck, interacted with, is given password).  The power of this language came from being able to switch to another 'state' with an entirely different set of event-based actions, and the ability to 'whisper' words that would trigger events in other objects in the vicinity.

You could also simply allow the player to create a visual flowchart-like program – LEGO again derived their Mindstorms NXT programming system from LabVIEW, designed to make things easier than learning a language syntax.

As for education, an icon-based system would allow you to start with pre-programmed sequences (e.g. UP 1, LEFT 2, UP 3), develop that into relative directional commands (e.g. FWD 1, LEFT 90°, FWD 2, RIGHT 90°, FWD 3), then develop that into branching decision making:

IF OBSTRUCTION -> LEFT 90°

|

ELSE

v

FWD

As I see it, instead of giving characters commands, you could create an automaton to fulfill a task.  These would grow in size and complexity from something tiny like a clockwork mouse toy to a retrieving robot dog to a water-fetching golem to a battling animated suit of armour.

Initially they must accomplish tasks along fixed paths, but as time goes on you could alter their programming grid from a long 1D script to a small 2D grid to force a change from linear sequences to branching decision-based programming.  Then introduce alternative or dynamic environments that can only be negotiated with more decision-making.

If the aim is to teach the principles of programming, I'd suggest starting with simple, visual cues.  You could maybe introduce the syntax of a written language later, once the basics are understood through a visual system.  It would give you something to look forward to.  You could even introduce an alternate language/syntax in a later part of the game, say, set in another country.

[mole125]

Thanks for this post, it has some really interesting ideas and thoughts in it.

I think you are right that a mechanism that starts visually is likely to be more accessible and allow commands to be built up without bombarding the user with syntax exceptions and cryptic error messages.

[abishur]

It's a fun sounding idea, and I hope someone makes a system using just that, but it's outside the scope we got going for this game

I actually have a couple ideas to help with overcoming the issue of information/syntax overload.  We're not just going to drop them cold turkey into this world, it's very much going to be designed in such a fashion that you slowly get introduced to the various programming functions.  That said, we're really hoping that this game is an effective and fun way to learn programming on your own so I'm rather committed to keeping things on a real world programming language level

[Joefish]

Thinking some more, I can expand on these ideas into how an icon system could be implemented.

At its most basic level, the task would be to click on icons for remote control, e.g. UP DOWN LEFT RIGHT GRAB DROP (that old BBC dock/crane/ship/container loading game springs to mind).  Then you introduce the concept of preparing a list of instructions, and add 2x, 3x and 4x repeat postfix tokens.

Then you introduce a prefix N-LOOP token and a closing NEXT.  All still in the linear space.

Then branching decisions that can divert flow onto a second row below the first one for the FALSE case.

At this point, you can either go down the left-to-right flowchart layout route (with IF-ELSE-ENDIF branches splitting then recombining program flow, and FOR-NEXT loops bracketing sections of code) or break out into a free-form 2D grid space, depending on preference.  The former, or a more vertical flowchart system, is probably easier to relate to actual lines of code later on.

Just a warning that concepts of 'state' or 'variables' are particularly messy to handle in this sort of program – I've yet to see it done particularly well.  They have to exist outside the flowchart and be referenced by operation tokens, so something as simple as C=A+B can get messy – particularly if there's no concept of a temporary result.

I'd probably go with a temporary result as a kind of 1-slot stack/running total/accumulator, with curried operations.  That might be as hard to grasp for a beginner as RPN.  Then again, it's pretty close to how you use a calculator (assuming you don't want brackets).  e.g. LET A=1, LET B=2, GET A (to temp), ADD B (to temp) SAVE AS C (from temp).

The other side of the 'golem' system of tasks is that the golem can be constrained to operate in a fixed activity area, entirely separate from the player's RPG roaming space.  It can initially have a grid laid over it for N/S/E/W movement, 90° turns and fixed step movement, but this can be relaxed for more complex free-form movement later on.