[TibitParticipant]

I would also like to see this unless it is proves to be a massive task. I think anyone working on an IDE, code tools or other external tools would benefit – seems something useful for Ted as well.

[TibitParticipant]

Regarding image assets. Is not the de facto standard to use sprite sheets these days, anyone not using that and calling a direct LoadImage? I see it simplifies the dev flow a lot, but also near needed for performance & memory for flash/ecmacript/ios/android? Then image loading can use the spritesheet “local” scope instead of a path.

So instead of a long list of Open/Load

local sprites:= Assets.LoadSpritesheet(“MySpriteSheet”)

sprites.Render(“Starship1”, x , y, direction)

[TibitParticipant]

Local font:=Font.Open( “fonts::myfont.ttf”, 16 )

So if “fonts” here maps directly to a folder by the same name then the same name would make sense. However if it always maps to a folder called /fonts/ then why not just leave it out? And if .ttf is also something that cannot change then leave that out as well?

Local font:=Font.Open( “myfont”, 16 )

[TibitParticipant]

Nice! So happy to see timeline FX. It is still my favorite 2D particle system package.

You make those effect look so good

I’ll eagerly stay tuned for the release.

Have you tried using Texture Packer in combination with timelinefx?

[TibitParticipant]

 

Solved, I can edit now!

[TibitParticipant]

Maybe there is a timeout on edits, I cannot find any edit link now.

[TibitParticipant]

Owff seems codeboxes are not working, but they where in preview! Let me know if there is something I missed.

[TibitParticipant]

Seems to be quite similar.

This was a fun read, did not know, how-one-programmer-broke-the-internet-by-deleting-a-tiny-piece-of-code/, everything in web development does seem to have a dependancy to npm these days

Seems Macos also use semver version notation, and seems npm does similar with sub-dir but only when there is version conflicts. So in the form of X.Y.Z, changes in Y has non breaking API changes or API additions, Z never breaks but include bug fixes and X is breaking current API calls. So if I want a more stable build I could listen for version 0.* which is fairly intuitive.

So in npm versioning the way I get it. An module has a package.json file, something like this:

JavaScript

{ "name": "nucleus-gamestudio", "productName": "Nucleus Game Studio", "identifier": "com.tibitinteractive.nucleus-game-studio", "description": "A game developer friendly code editor for Monkey 2.", "version": "0.2.0", "author": "Tibit", "copyright": "© 2016, Tibit Interactive", "main": "background.js", "dependencies": { "fs-jetpack": "^0.7.0" } }

1 2 3 4 5 6 7 8 9 10 11 12 13

{ "name": "nucleus-gamestudio", "productName": "Nucleus Game Studio", "identifier": "com.tibitinteractive.nucleus-game-studio", "description": "A game developer friendly code editor for Monkey 2.", "version": "0.2.0", "author": "Tibit", "copyright": "© 2016, Tibit Interactive", "main": "background.js",    "dependencies": {        "fs-jetpack": "^0.7.0"    } }

All modules to the App are found in a app/modules folder, and the modules get there by typing “npm install or npm update” and the modules folder is then updated to match my package.json file (which is the default name if none is specified). This is the same process when I clone from github. git clone && npm install. However I rarly manually edit the package.json in order to install packages.

Then if I find a npm module I like on the internet the how to install usually looks like:

Install the electron command globally in your $PATH
npm install electron-prebuilt -g

Which downloads the module to the apps local /module/ folder or with -g the global /modules/ folder and any dependancies that this module needs that I do not already have in my local module folder. I think that only if a module in it’s package.json depends on an older version that one currently have that it adds it as a “sub-module” to that module.

I guess you are able to device more cleaver solutions more specific to monkey 2.

Local and sub-module versioning seems to relieve the dependancy-fear that a module used might get a breaking API update, might avoid the feeling that you “should” inline code instead of using a proper module.

I also used meteor(meteor.com)’s package manager which has an even simpler interface:
meteor add author:package <– download and compile package
meteor remove author:package meteor <– compiles and starts local dev server if the local folder contains a .meteor folder where all modules and build stuff is in
meteor deploy your-app.com –settings production-settings.json
meteor add-platform ios <– build an app
meteor run ios

What I hope at the end of the day is just a simple command-tool, so the editor can provide an really user friendly interface for easily finding, installing and removing modules + docs + examples which I think could be a key piece of building a flourishing monkey2 community.

[Author]

Posts