It is currently Fri Sep 20, 2019 3:36 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 22 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Sat Jan 26, 2019 8:15 pm 
Offline
User avatar

Joined: Fri Feb 27, 2009 2:35 pm
Posts: 367
Location: Fort Wayne, Indiana
I really like WarioWare DIY but it's got a lot of limitations I don't like, such as a lack of integer variables and no buttons, and it'd be nice to have something that wasn't as limited. I also feel like the NES would be a cool target for playing microgames on (and it'd be awesome to have a big 512KB cart stuffed with tons of microgames as a community project).

I've been working on an experimental compiler specifically for making microgames with, where you define a map, define a list of actors, place the actors on the map in locations and describe the behavior of the actors, primarily through chaining together premade behaviors.

So far it's actually looking pretty feasible? I've got things to the point where this:
Code:
        "player": {
            "graphic": "$01",
            "size": [16, 16],
            "run": [
                ["set", "speed", 2],
                ["8way-movement", 255]
            ]
        },
        "getme": {
            "graphic": "$e8",
            "size": [16, 16],
            "run": [
                ["set", "speed", 1],
                ["ball-movement"],
                {
                    "if": ["touching-type", "actor:player"],
                    "then": [
                        ["destroy"],
                        {
                            "if": ["not", "find-type", "actor:getme"],
                            "then": [
                                ["win-game"]
                            ]
                        }
                    ]
                }
            ]
        },


gets translated into this:
Code:
.proc actor_run_player
lda #2
sta ActorSpeed,x
 
lda #255
jsr Actor8WayMovement
 
Exit:
rts
.endproc
 
.proc actor_run_getme
lda #1
sta ActorSpeed,x

jsr ActorBallMovement

lda #ActorTypes::player
jsr ActorTouchingType
jcc lbl_12
lda #0
sta ActorType,x

lda #ActorTypes::getme
jsr ActorFindType
jcs lbl_14
jsr WinGame

lbl_14:

lbl_12:

Exit:
rts
.endproc


and I've got a whole bunch of behavior primitives written, though the actual rest of the engine is far from done, as is any actual stuff to put the microgames together in a ROM, though I imagine that wouldn't be hard. The rest of the sample file I'm using is here with the output here. That shows off some math (including optimizations to use INC and DEC when possible), and conditionals using OR and AND, and other features.

I guess the question is, is this worth doing? Expressing it through JSON like this doesn't really seem that much easier than just writing the instructions yourself, though it could probably benefit from being able to accept a file that's in more convenient-to-write form, where you could add comments. I'm not really interested in making a GUI editor for this, but maybe an existing one could be tweaked to work with this?


Top
 Profile  
 
PostPosted: Sun Jan 27, 2019 4:21 am 
Offline

Joined: Mon May 27, 2013 9:40 am
Posts: 543
I like this idea. The Json like dialect may be good 'cause it can be produced easily by a GUI driven application (even visually) if somebody is willing to create one in the future. I find it cumbersome to write it myself, but it's easily understandable and parseable by machines, so why not?

_________________
http://www.mojontwins.com


Top
 Profile  
 
PostPosted: Mon Jan 28, 2019 1:50 pm 
Offline

Joined: Thu Jun 04, 2009 9:07 am
Posts: 37
If you don't mind reinventing the wheel (writing your own parser) once you have the workings well defined, a VRML-style syntax would avoid quoting everything, comma separation between properties, and the need to put code in strings.


Top
 Profile  
 
PostPosted: Sat Feb 02, 2019 10:57 am 
Offline
User avatar

Joined: Mon Feb 07, 2011 12:46 pm
Posts: 1042
Some alternatives for the syntax are YAML (which is a superset of JSON, so JSON code can still be used too), or RDF, or Lisp.

I also notice the 6502 code could be optimized in some ways, such as a tail call optimization to WinGame.

_________________
.


Top
 Profile  
 
PostPosted: Wed Feb 06, 2019 3:10 am 
Offline
User avatar

Joined: Fri Feb 27, 2009 2:35 pm
Posts: 367
Location: Fort Wayne, Indiana
So I actually went and wrote more of the stuff to actually make the compiled microgames runnable. Observe this test "game" that just lets you run away from enemies that mostly target you but sometimes go off in random directions. I don't have actor+actor collision in yet (or the concept of winning or losing a game at all) or I would also have them react with the player.

Code:
      "player": {
         "graphic": "$01",
         "size": [16, 16],
         "run": [
            ["set", "speed", 2],
            ["8way-movement", 255]
         ]
      },
      "avoidme": {
         "graphic": "$25",
         "size": [16, 16],
         "run": [
            ["set", "speed", 7],
            ["ball-movement"],
            {
               "if": ["every-32-frames"],
               "then": [
                  {
                     "if": ["random", 192],
                     "then": [
                        ["set", "direction", 0, "random", 31]
                     ],
                     "else": [
                        ["find-type", "actor:player"],
                        ["look-at-actor"]
                     ]
                  }
               ]
            }
         ]
      }


Image
(using sprites from Chase and other things from http://wiki.nesdev.com/w/index.php/File ... et.chr.png for placeholders for now. I should draw some of my own simple premade graphics for this)

I actually wonder how hard it would be to make a simple clone of the Scratch UI in HTML5. I might try to do that later on.


Top
 Profile  
 
PostPosted: Wed Feb 06, 2019 8:04 am 
Offline
User avatar

Joined: Sat Jan 09, 2016 9:21 pm
Posts: 625
Location: Central Illinois, USA
zzo38 wrote:
Some alternatives for the syntax are YAML (which is a superset of JSON, so JSON code can still be used too)


I've started using YAML in place of JSON for files that I want a human to be able to edit, and it's great from that perspective. It's just a lot easier to read/write manually. This might be a good idea.

_________________
My games: http://www.bitethechili.com


Top
 Profile  
 
PostPosted: Wed Feb 06, 2019 10:50 am 
Offline
User avatar

Joined: Fri Feb 27, 2009 2:35 pm
Posts: 367
Location: Fort Wayne, Indiana
Honestly anything I can still get a Python dictionary out of can be easily swapped in where JSON was. A lack of comments in the input game sounds like it'd be a huge pain for more complex games which is another reason to move away from JSON.


Top
 Profile  
 
PostPosted: Wed Feb 06, 2019 1:20 pm 
Offline
User avatar

Joined: Sat Jan 09, 2016 9:21 pm
Posts: 625
Location: Central Illinois, USA
NovaSquirrel wrote:
Honestly anything I can still get a Python dictionary out of can be easily swapped in where JSON was. A lack of comments in the input game sounds like it'd be a huge pain for more complex games which is another reason to move away from JSON.


That's what made it easy for me to slowly swap in my current game. Just replace a json parse with a yaml parse (of which there are python libraries for both) and be done with it. My one beef is that the default python yaml parser is fairly sensitive about whitespace details. I've had a few yaml files that validated with every yaml validator I tried other than python.

_________________
My games: http://www.bitethechili.com


Top
 Profile  
 
PostPosted: Sat Feb 09, 2019 3:34 pm 
Offline

Joined: Wed Feb 23, 2011 4:14 pm
Posts: 24
Location: Belo Horizonte, Minas Gerais, Brazil
That's a very interesting experiment. :)
Its declarative format could easily be generated with a tool such as Blockly, owl-bt, Edgy, Waterbear or RPD.


Top
 Profile  
 
PostPosted: Sat Feb 09, 2019 7:11 pm 
Offline
User avatar

Joined: Fri Feb 27, 2009 2:35 pm
Posts: 367
Location: Fort Wayne, Indiana
haroldo-ok wrote:
Its declarative format could easily be generated with a tool such as Blockly, owl-bt, Edgy, Waterbear or RPD.

I figured there was probably a tool out there that I could use! That would be a lot better than making my own, and I could focus on the actual engine and the compiler instead.


Top
 Profile  
 
PostPosted: Sun Feb 10, 2019 1:19 pm 
Offline

Joined: Wed Feb 23, 2011 4:14 pm
Posts: 24
Location: Belo Horizonte, Minas Gerais, Brazil
NovaSquirrel wrote:
haroldo-ok wrote:
Its declarative format could easily be generated with a tool such as Blockly, owl-bt, Edgy, Waterbear or RPD.

I figured there was probably a tool out there that I could use! That would be a lot better than making my own, and I could focus on the actual engine and the compiler instead.


I'm glad to help. :)

I also just found something that could maybe be adapted for the task: Mobile Microgame Maker
Whether this one would require more or less work than the alternatives, it would be up to experimentation.


Top
 Profile  
 
PostPosted: Sun Feb 10, 2019 5:26 pm 
Offline
User avatar

Joined: Fri Feb 27, 2009 2:35 pm
Posts: 367
Location: Fort Wayne, Indiana
Image
Here's the above code but in Blockly. It took a long time to define all of the blocks but I should have all of them in so far and it probably won't take much longer to actually get the game defined here into the JSON format.

I think I'll probably have the actual art aspect and the actor placement in a separate part of the tool, instead of being inline with the code.


Top
 Profile  
 
PostPosted: Mon Feb 11, 2019 2:27 am 
Offline

Joined: Mon May 27, 2013 9:40 am
Posts: 543
This is awesome. Congrats.

_________________
http://www.mojontwins.com


Top
 Profile  
 
PostPosted: Mon Feb 11, 2019 11:17 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8564
Location: Seattle
I find it really striking how similar that looks to ZZT's or Megazeux's built-in programming languages.


Top
 Profile  
 
PostPosted: Mon Feb 11, 2019 3:10 pm 
Offline

Joined: Wed Feb 23, 2011 4:14 pm
Posts: 24
Location: Belo Horizonte, Minas Gerais, Brazil
NovaSquirrel wrote:
Here's the above code but in Blockly. It took a long time to define all of the blocks but I should have all of them in so far and it probably won't take much longer to actually get the game defined here into the JSON format.

I think I'll probably have the actual art aspect and the actor placement in a separate part of the tool, instead of being inline with the code.


The tool seems to have great potential. Can't wait to see it working! :)


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 22 posts ]  Go to page 1, 2  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group