In my ignorance, I thought it would be easy to move everything from GameMaker to OpenBOR; I mean, adjust a few scripts here and there and everything would be ready to continue. It's a shame it's not that simple... =/
Yeah, it doesn't work like that at all. Every engine has its own workflow, structure, and assumptions about how a game is supposed to be built. Even if two engines used similar scripting for the coded logic portions - and GameMaker and OpenBOR definitely don't - the containers around that code are completely different.
OpenBOR, for example, is built with a lot of native behavior and physics already in place. The usual flow is levels loading models, models becoming entities, entities using built-in movement/collision/attack behavior, then script hooks letting you override or rewrite those behaviors as needed. GameMaker works from a different direction. Its basic structure is built around rooms, objects, events, layers, cameras, viewports, and its own scripting language. Rooms are a central part of how GameMaker organizes gameplay. They are not just maps - they are where the active instances and room-specific setup live.
That is not just a naming difference. OpenBOR does not really have "rooms" in the GameMaker sense, and GameMaker does not really have "levels" in the OpenBOR sense. An OpenBOR level is more like a stage definition: terrain, scrolling rules, spawn points, branches, and conditions for moving on. The level can say
"spawn this enemy here" or
"end the stage when this boss is defeated," but the models and entities do most of the actual work once they are in play. GameMaker rooms are closer to a runtime container. They hold the instances, layers, views, cameras, and setup the engine uses while that part of the game is running. You can make either engine produce the same gameplay result, but the path to get there is different. One is not just the other with different labels.
That same idea is true of pretty much every engine. Unity, Godot, Unreal, MUGEN, OpenBOR, GameMaker - they all have their own way of organizing assets, logic, scenes/levels, objects/entities, physics, animation, and runtime behavior. Some basic skills cross over - collision design, sprite making, animation timing, level engineering, enemy behavior planning, hitboxes, hurtboxes, and general game logic. Everything else has to be adapted to the engine you're using.
Pretty much the only things GameMaker and OpenBOR have in common are that they can both run sprites, and they both got their early start in the Netherlands.
DC
