

It appears GM looks at what is cool in other editors and adds that Most alternatives to GM use native languages that only look similar to PY or to C, but not exactly.
Game maker vs stencyl code#
GML code looks very very similar to JS and PHP. Other advantages to GM that frequently go unnoticed: An option here is to design for multiple screen sizes andĪnd for touch screens such that when ready, most of your issues are already solved. Testing on other platforms until you upgrade.
Game maker vs stencyl for free#
The option to dev for free and upgrade for production is great. Good plan for an INDI project on a tight budget. Some have even done the odd thing of upgrading, do a release, then downgrade to free for next project. SO, prototype for free, build your engine, get everything working, Upgrade when fully ready. GM can export to most anything (money now) but if you wait until you have a working game, that is not a problem. The free alternatives becomes a very short list and that comes with a limit on the support side. įREE, you CAN get a multiplayer game (demo) up and running (OPERAGX) without spending money. So, you know what it will cost, you know what it can do, you know the support level. My own take on GM is sorta mixed, BUT it does what it says.

won't say what they are, you did not ask. GM is great for all the things you listed. Questions most welcome! Thanks in advance. Game has levels which get progressively harder/more complex but that's through new rules. So in some ways, something like "SpaceTeam" UI.ĥ. All you "do" in the game is drag some objects from one place to another, that's pretty much it. You need to be able to tap some objects to "open" them to show more objects inside (pop-up/modal likely). Majority of game UI is simple/minimal/static (changing content in some places) that shows you objects in the game and text to show information that changes in each level. The player is you and not represented in the game (i.e. Each player likely to have 1 largely static screen that doesn't scroll.ģ. This is 2D and likely a mobile/PC game in first instance. 2 or 3 players is fine for initial prototype.Ģ. This is multiplayer and quite probably only a multiplayer game. The key things I suspect are needed to determine "what tool" are:ġ. If the same tool could use that to build into an actual game, great, but not the priority. To be clear, all I'm really interested in at this stage is prototyping. The question is - is GM the right tool or is there something better for my needs? So I think a simple lo-fi digital prototype would make sense and keen to try do it myself if not too onerous. A human/me could do manually, so my concern would be that if I were to be the "system" in the non-digital prototype, making sure the rules were adhered to and things happened at the right times would be tough and could slow down the game enough to frustrate players prototyping to test if "fun". This game really benefits from having a "system" looking after various things.

non-digital method) I'm not sure how representative/effective that would be. Whilst you possibly could do some early prototyping in paper (i.e. I have an idea for a game that is at the stage where prototyping is the logical next step to see if it is fun and works the way I hope. I have been a programmer (1990-2010) which probably gives you some idea of what languages/tools I used - I get the core concepts of programming but no real urge to get back into it, don't mind doing some to achieve goals. Background: I've always liked designing games and experiences or all sorts of types.
