Sorry your browser is not supported!

Hi,

One of the issues I have with the scene editor concept has to do with metadata. The unique variable is handy and the array groups are handy too, but it feels to me as though that's not enough to really get data-driven on the levels. A specific shortcoming, I think, is that you can have a sprite in only one array group. If you are making a tile based game, it means one tile, one sprite and then only one piece of meta-data. That's really not enough. A tile can have several attributes that one would like the level designer to edit and I don't think that's currently possible. (I currently put sprites in array groups to tell the game something about the tile but that's one idea per tile, which is not enough). Is there a better way?

On a further note - which just goes a bit deeper on the whole level philosophy - generating code for levels one makes is, in my opinion, not a great idea. For starters, you cannot have user generated content - even if the user has the AppGameKit Studio app, they can't make or edit a level without all the code. Without being able to put function pointers (refs) in arrays, you are also forced to write big select statements where you have a case per level to call setup(), cleanup(), etc. Also not ideal. I am not sure if theGameCreators think of this as a toy (I mean no disrespect - I mean it's not meant for serious production work) or if I am not seeing the big picture, or perhaps jumping the gun (maybe it matures into something more)?

Having used it to make some levels for a game (my game is just a toy, nothing serious) I can say that it's just not a very good editor. Not yet, anyway. The UI is lacking (can't edit properties on multiple selected sprites for starters) and the ability to data drive things is really just not there. If I had the ability to drop pseudo sprites (markers) in the level, that aren't sprites and can coexist with sprites, that would help. If the markers can live in multiple array groups, that would help a lot, and if I could define Types in the editor, and created markers of user defined types with editor defined initialization data, then I can see working with these code generated levels making more sense. If we then got the ability to put function ref's in arrays so I could do something like call(functions_setup[level]) and could load the generated level byte code on the fly, why then we'll be in the money but I know I am now dreaming [I realize it won't give me the ability to call something like scene_setup() unless there was some byte code function discovery mechanism and I can see that goes against having this easy-to-use basic language]. The markers and types though, that would be a great help, I think?

Thanks

Is the scene editor array a type array?

I am not 100% sure what you are asking. The scene file has auto-generated code and all of the sprites end up in array's of integers. You can select sprites and add them to a group (array) for which you specify the name. This is also an array of integers and those integers are the IDs of the sprites. Currently, I add fake sprites to such named groups and in-game I spin through and get the location from these fake sprites and and assign them an attribute based on the name of the array.

This is a snippet from one such a scene (called screen1). It's a Pac Man game so I have one (scene - called screen) screen per level. "dots" are all the editable dots. "walkable" are empty-spaces where I have to put sprites, that I find, note the location of, and then delete the sprites - so pure meta-data. Slow are similar to walkable, but in addition, monsters move slow over these tiles. Ideally I would have been able to specify, with some meta tag, both walkabale and slow (or by having the same pseudo/meta sprite in both arrays). Instead I now have to make an array for all combinations of meta data, which I think will be very cumbersome if you try and make a big level with lots going on.



the walls (screen1_walls) array was made by me and I selected all the wall sprites and assigned them to an array group named walls (which became screen1_walls). Since all of this code is always loaded, the screen1 "namespace" is needed to differentiate between walls from screen1 ans screen2, etc. But, as you can see, this makes it so you need code to specifically work with screen1, and then specifically with screen2, etc. You can't have generic code that just works with the levels.

Very verbose answer - I hope somewhere in there was the answer you were looking for.

Thanks.

Would using a type help?



Also maybe a 2D array where element 1 is the screen and 2 is the sprite or type
AllWalkable as tile[-1, -1]

So when you wanted to deal with screen 1 you could
walkable = AllWalkable[0]

Or just reference the elements in the array directly
Id = AllWalkable[0,5].id

Hi,

Remember that the code isn't written by me - the scene editor writes the code. The output of saving a scene in the scene editor is AppGameKit Tier 1 source code. I can edit the code in another text editor as code, but I won't be able to use that code back in the scene editor which is no good. What I am suggesting in the initial post though, is exactly what you are also suggesting - give me the ability to define a type in the editor, and then populate an array with that type and fill in data into the elements of that array, and have the scene editor save all that out as code. That would work

Thanks

I usually copy the setup function in the scene script in to my own files and do changes in the copied function.

The array the scene editor cretas do i more or less only use to grabb sprite ids and such.

I do my tilemap arrays my self and simply put in the id numbers that the scene throws at me.

Something like i did with this..
I do all gui stuff in studio but create the tile maps with code.

https://play8bitars.itch.io/pixel-grunt

This shows more wath i do.
Old video and me talking

I also usually copy the sprite IDs into user data types but I get what your saying about meta data. To address this problem and its probably not the best way but its comfortable to me is I use the Color Values... Like for example for enemies in the editor I would label the array
scene_1_1_enemy
And then I would differentiate them by colors like:
Bee. (255,255,254)
Fly. (255,255,253)
Bat (255,255,252)
Spider (255,255,251)

I would bring an image of the enemy.. Most likely the 1st frame of there animation and place it in the editor.. Change the color.. R,g,b respectively..

Then i create a createenemy() function that will go through all scene_1_1_enemy[]


Of course its pseudo code but if you can pretty much follow it thats how I include meta data so to speak

"A specific shortcoming, I think, is that you can have a sprite in only one array group. If you are making a tile based game, it means one tile, one sprite and then only one piece of meta-data. That's really not enough. A tile can have several attributes that one would like the level designer to edit and I don't think that's currently possible. (I currently put sprites in array groups to tell the game something about the tile but that's one idea per tile, which is not enough). Is there a better way?"

This is a snippet from a program where I was teaching my kid how to make a dungeon. Doing a type array like this would allow you to assign as much data to each tile as you want.