so i wrote this outline...... and my word proscessor made it into a bit of a wall of text. but what do you guys think? normal game engines are: not cross platform not easy expensive not expandible. so i did an outline for something better. oh and this outline and technolgy is open and i wrote it so if you like the ideas feel free to use them in any way. if i actuallly develop this the player will be open source and the spec too. only the development tools will cost but the spec is open so you can do your own. at this point i have 0 lines of code written for this and I'm not even sure i have time to start. but i would like an opinion :) Universal Game Code revision 0.1 Introduction: UGC is a system to make games with only a text editor that have modern features that you would expect in a commercial game with no previous coding knowledge. UGC is based on “Frames” which are like pages is a book, and “events” which flip between them. Every frame has a table that links to other frames when events are received. One frame is always the active frame. Remember choose your own adventure.? Game books? Each frame has simple code attached to it that can draw pictures, play sounds, respond to input, ind more! A frame code example: <frames> -my frame- &events& buttons= myframe2 ;when buttons is pressed go to myframe2 &code& setBG mypic.jpg ;show a picture UGC Binaries can run on almost any platform! All functionality in UCG is divided into Modules. Since modules are native executable, any feature the computer supports can be used. Since you can write you're own modules, you can put as much or as little as you like of you're game into them. All modules contain commands that can be called in addition to the UGC standard commands. *note: custom modules are not cross platform unless you make a version for every platform or if you are using a java based ugc player, Standard Modules planned for rev 1 Include: UGC: The UGC player itself. Handles game file loading, script execution, game state management. This can be put in one executable with all of the modules the game uses to create a file that does not need any other files to run. See work flow. UGC_CORE: handles keyboard and mouse I/O, basic text graphics, math functions, file save/load. UGC_2DGRAPHICS: handles drawing a window and adding sprites and pictures. Also handles mouse interaction with onscreen graphics,video playing,and image scaling. Can call events when a video finishes. UGC_SOUND: play sounds(and call events when finished) future modules: UGC_3DGRAPHICS: handles rendering of 3d content. Interfaced to the same as UGC_2DGRAPHICS, but in 3d. 3d objects are still treated as sprites that can be placed in 3d. Loads 3d graphics from obj files. UGC_MOVEMENT: handles movement of objects on screen. UGC_FIX: development/troubleshooting. Syntax: UGC script has a very simple syntax. There really isn't any. Commands are executed in the order they are written in. there is no “if” operator. Instead you have “jump to frame F if Rule C applies to A and B”. loops also involve jumping between frames. There is no “assignment” like “a=b+a”. instead where to put the result is a argument in all commands that return a number. As in add(test,a,b). the sum of a and b would be stored in test. A command can never have more than 6 arguments. Every line of code is the command and its arguments. Nothing more. Module interface: every module weather built in or realized as a library function must communicate through an interface that: Allows the external code to load files easily. allows internal code to pass commands to it. Commands must have numbers for names. Allows external code to modify RAM values in the virtual machine allows external code to call events. Glossary: UGCVM: the virtual machine games run on. Module: external code adding functionality to the UGCVM UGC script: the code you write to make games UGC binary: a compiled file containing byte code for the game plus some extra data. game file reference binary(compiled output): cfg area: 64 reserved bytes event mapping table: 64 bytes File system area: TOTAL length,32 bit number (the length of the whole game file including this in bytes) number of files, a 32 bit number (number of files packed into the main file) for each file: 64 byte file name, stored as ASCII with 1 bit padding. if the file name is under 64 characters long use NUL as null. start byte,a 32 bit number, the first byte of the file. note that byte 00000000(hexadecimal) is the first byte of the file area, not of the file system area. end byte, a 32 bit number, the last byte of the file all files also have a number, but this is implied by the order they appear in in the table. File area: the files are stored here with no extra data, that goes in file system. Files that must be in a game: GAME: the games code file. structure: number of instructions(16 bits) number of frames(16 bits) instructions:(each area is 16 bits,unused arg are 00000000 for nu;) for each: frame op code arga argb argc argd arge argf STT(state transition tbl) number of states(16 bits) for each state: 64 16 bit numbers, containing the number of the new state should the game receive that event(1-64) optional files: Text file: should your code include any text at all(filenmes, messages,etc), it is stored here. each string is a file. it does not matter what the file names, you reference it by file number(starting at 0) if you're code has any string literals at all they will be converted at compiletime to references to files here. CFG: a standard INI file. You can map states to events here and configure the VM. Example: event61= ASCIICODE_q_DOWN if you put this in your code, event 61 would be called when you press “q” you can also set a key to <USER> type where type is the type of data(string,file name,number,color,date,etc) and allow the player to change it at run time. Put an X after type to not allow runtime changes. example source code(what you write to make it): <<BEGIN>> ;<<>>, <> ,-- and && form a tree structure with <<>> at the root and && as leaves. <Comment> a simple game about going in a museum. <CONFIGURATION> ; this along with events will go in the CFG section in the binary. X=480 Y=640 ;sets the resolution to be VGA. <EVENTS> A= button A B= button B ;maps buttons to events <FRAMES> ;note the state table data and code is in the same section -outside- ;specifies a frame called outside &TABLE& A=inside ;specifies that event A (button A being pressed) leads to the frame "inside" &CODE& ;the code SetBackground (outside.jpg) ;lets imagine that the image also contained the text "press a to go inside" -inside- &TABLE& ;indentation is not required at all because the tags maintain the structure. You can use. B=outside &CODE& SetBackground (insidemuseum.jpg) ;again imagine the picture said "press b to go outside" <FILES> ;you can manually create files here is you want to. -example- ;a file name &type& text ;says the file is text and not to try to convert it from hex to binary &content& this does nothing. it would be included in the compiled output but it would only waste space. it does serve to show how manual file creation works. you can copy and paste a bitmap file here from a hex editor if you want to not reference an external file. Internal file names start with IF_ <END> everything after this is comments and won't be compiled. if you want to compile comments make a text file called comments to hold them. comments in <comment> sections are not compiled.

Quote:and my word proscessor made it into a bit of a wall of text.

When posting something like this to the forums, you can (and should) use HTML to make it nicely formatted for reading. There's really no reason to resign yourself to (or subject us to :) a 'wall of text'. With better formatting, more people will be likely to look over your post, and you're likely to get a better response overall.

Anyway, I skimmed it. Just for the sake of discussion I'll play devil's advocate a bit here:

Quote:normal game engines are:

not cross platform

Many game engines and game authoring tools that are widely used today are indeed cross-platform.

Quote:not easy

There are several game authoring tools available today that are quite easy to use.

Quote:expensive

There are several game engines or game authoring tools available today that are either free, or inexpensive.

Quote:not expandible.

There are several game engines or game authoring tools available today that don't impose many limits at all on what can be created with them.

What game engines/tools have you looked at? (I'm kind of curious as to how you arrived at the above conclusions.)

I just skimmed over your description, but I'm not completely clear on whether your system is supposed to be able to create various types of games, or whether it's specifically intended for 'point-and-click'-style adventure games. If the latter, it seems like something like this could be of interest to someone wanting to make that type of game. If the former though, I think you have to look at game engines/tools such as Game Maker, Unity, etc., and ask yourself what this would offer that those tools don't.

Quote:A command can never have more than 6 arguments.

This seems pretty arbitrary.

In addition to cleaning up your original post, perhaps you could post a short summary explaining in simpler terms what the purpose of this framework would be, and what it would offer that other currently available game engines don't.