Developing modules in parallel with a game

[EthernautParticipant]

Suppose you’re developing “MyAmazingGame“.

In parallel, you’re also developing the modules required by the game: “EntitySystem“, “GraphicSystem“, “MessageSystem“, etc. Also suppose that you’re being really careful with how you design everything, so none of the systems depends on each other. That way you hope things will be much more manageable as the project gets larger and if you want to improve one of the systems in the future.

How would you organize that?

Option 1: If you put all systems under their own folders inside the game folder and import “entity/entitysystem”, “graphics/graphicsystem”, etc. Everything works, and you don’t need to compile the systems individually – just compiling the game automatically compiles all necessary systems, since they all belong inside the game.

Downside: if you create other games/apps using the same systems, you have to make duplicates of them. Things will get messy and out of sync quickly. You’re not really taking advantage of the fact that the systems are completely independent.

Option 2: You create separate folders for each game system, outside the game AND outside the monkey2/modules folder, and create scripts that copy each module to the modules folder and compile them as modules.

Downside: It’s a pain, every time you want to make a small change in one of the modules you need to save the module, go to a command shell, run the script, come back to the ide and then compile the game with the change.

Option 3: You create separate folders for each system INSIDE monkey2/modules, and use those folders as your module development folders.

Downside: Similarly to option 2,you always need to pre-compile the module changes, plus the added pain of not being able to just wipe monkey2’s folder clean when you download a new zip file.

Option 4: Does not work in Monkey2, but in Monkey1 I used to keep my modules in any folder I wanted, then created symlinks to them inside the modules folder. Monkey1 also always compiled the modules when necessary, removing the step to pre-compile the modules before compiling the game when a change is made in one or more modules.

Downside: Does not work in Monkey2.

Option 5: Some Github magic? I’ve read a little about sub-repositories, but it seems buried under complicated shell commands.

Any suggestions? What’s your favorite setup?

[Mark SiblyKeymaster]

I’d start with pseudo modules ‘inside’ the app folder. You can code them pretty much the same way you’d code a real module – ie: have a root src file that imports other module files.

Then, when everything’s stabilized a bit you can think about making them real modules.

‘Links’ to modules will eventually be fixed, and it may be possible to have some kind of ‘auto-updating’ of modules when they’re imported, but for now it’s sanest to work on new module code as part of an app project so you don’t have to remember to update modules all the time.

I have tried my best with mx2 to make it easy to move files around without upsetting a project too much. You should only have to modify some import statements, and maybe some usings, so you try a few ways to organize things until you come up with something that works for you.

This is what I’ve done with ‘mojox’ – see ted2/mojox. All I really need to do to ‘modularize’ this is move the mojox folder to /modules and change my #import “mojox/mojox” to #import “<mojox>”.

[EthernautParticipant]

Thanks, I was thinking about settling with something like that.

Also, to help me keep development folders for modules outside M2’s folder, I made this shell script that performs some basic checking, clears the module’s folder inside M2, copies the new files to the appropriate folder and compiles it, all in one easy command. I realised this would be useful since I had to run mx2cc anyway to compile the module, even if M2 supported symlinks.

Hopefully this can be useful to someone else:

https://github.com/DoctorWhoof/makemod/blob/master/makemod.sh

I would love if someone with experience in shell scripts takes a look at this for anything that could be improved, especially safety (my first versions used to wipe the entire modules folder when no arguments were given…)

[jondecker76Participant]

I do pretty much what Mark suggested – just build them as extra source files during development until I feel they are done, then I’ll make them into a module if I feel it’s something I might use again.

I’m not a huge fan of the modules system yet in Monkey2 yet though.  I think the ability to organize in subfolders is  a must, as my modules folder is already a jumbled mess.  I really liked how it was implemented in BlitzMax.  All of BRL’s stuff was in brl.mod, and each subfolder could be another module.  Under BMX, I had my own jmd.mod, with several individual modules that I could import one at a time if needed.

[Simon ArmstrongParticipant]

I have always liked developing apps in a single source file.

When it is time to split app into separate files I am considering putting app source in module.

 

Most apps will have a primary module and unless you are on MinGW or Pi update modules cycle is no delay.

Maybe just for open source, but it seems tidy to have #import “<builder/mx2cc-app>” as the starting point for custom tinkering with the monkey2 transpiler just as much as community editions of Ted2 that begin with #import “<mojox/ted2-app>”

[Mark SiblyKeymaster]

I’m not a huge fan of the modules system yet in Monkey2 yet though.  I think the ability to organize in subfolders is  a must, as my modules folder is already a jumbled mess.

You *can* use subfolders within a module no problem – see std, mojo etc. So you could stick all your ‘modules’ inside a single ‘jmd’ module, where the main jmd.monkey2 file #imports all the bits, ala std, mojo etc.

The main difference is that you can’t build individual ‘parts’ of a module this way, but in my experience this hasn’t been a problem as yet. When it is, I’ll investigate.

The upside is that importing/linking jmd is easier/faster because it’s just linking with one archive, and sticking your stuff up on something like module manager is much easier as it’s just one ‘chunk’.

> I have always liked developing apps in a single source file.

I try to avoid this if possible, as I find it too tempting to use globals which end up being hard to ‘unpick’ when you’re splitting things up into multiple files, eg: mx1 mojo.graphics! But that’s probably just me…

[wiebowParticipant]

I am developing my module and game separately. I have a subfolder in modules and a separate game folder. I use Sublime Text, so it is VERY easy to switch between projects (CTRL-ALT-P)…  So I jump between these two projects as I develop.   I need to keep my module folder save during Monkey updates, but this is a minor issue for me. Once linked folders work I will move my module sub folder to a new physical spot.

I don’t use single files It makes it hard for me to focus once the file gets above a certain size

[Gerry QuinnParticipant]

This isn’t Monkey 2 specific, but like Mark and jondecker, I would just try to develop my game in an OO fashion, then when it’s done, refactor out the particular system into a module for my next game.

[Author]

Posts