So I came across this last night while I was looking for some pixel art tutorials.
This seems ideal for indie games, this and na game studio.
Yeah, that is oooooooolllllld stuff. It's been around forever, and was pretty much the definitive 2D Indie and hobbyist engine for a while. I think Unity pretty much supplanted it in that field though when it introduced direct 2D support back in 4.0.
These days, even if you want something that simply allows you to circumvent traditional programming you probably have better options. Like Unity + PlayMaker (among other assets).
In the open-source front there's a moderate amount of pixel-art games made with OpenFL, but it requires programming knowledge: http://www.openfl.org/showcase/
So open fl and xna is the current. Lol I didn't know that it was that old. I'll check em out too. These two ( game maker and xna ) looked appealing to me because Devs who made Terraria and Risk of rain are using it for their indie game projects. It will also motivate one to practice some coding.
This and that, maybe not for everything you intend to do, but check this http://mightyfingers.com/editor-features/ engine out, runs smooth, is available online and isn't hard work!
Have been playing with it on my free time for a while.. this far I really like it.
As a game designer and artist, I have to say game maker is amazing.
The only thing I regret is that I didnt start with it years ago.
I started with unreal and unity (not counting modding) and in all this time I was always reliant on a programmer or a team, and now I can finally make my own games all alone, without anyone setting me constraints.
2 weeks ago I had never touched any form of programming before, and game maker language is so easy and convenient, I already do somewhat complex stuff and can do anything I want with the polish I want, which is just so much fun. Maybe im a special case here, but I really recommend game maker. But only if you want to do 2D, for 3D get something else. Unity is so much complexer already and needs so much more work to get something done, I dont think one replaces the other in any way after doing a lot of unity.
Im having so much fun with it right now, wow.
They also recently put a new update with a asset store and such things. Most game maker games you see suck very hard, but thats not the engines fault, it just mainly attracts unexperienced users. You also dont need to make pixel art, just the tools inside help you make quick pixel art.
- I would also strongly suggest learning unity and or unreal over or before game maker, especially as a beginner, its just a lot more valuable to know, but id highly recommend for experienced people just wanting to make a game
If you want to have a long and successful career I think you need to learn at least some amount of programming. Not only does using proprietary visual programming limit what you can do, but it also means that if the developers ever stop supporting GameMaker you'll have to start over practically from scratch in learning a new engine.
Unity has a few giant strengths over it anyway.
It costs way less. You can use Unity for free and get much of what you needed out of it for a typical Indie project. Even support for every reasonable platform. Especially a 2D one. GameMaker on the other hand charges a fair bit for every single platform you want to release to, regardless of the scope of your game.
The Asset Store is an extremely powerful source of premade assets, from art to scripts, and even has amazing plugins to improve basic functionality, like Playmaker for visual scripting or SmoothMoves for tweening animations.
Unity is also more stable and reliable. I once tried to play a GameMaker game on my Surface Pro, and it straight up just did not work because of some stupid video driver incompatibility.
Finally, as an industry standard it has comparatively great support behind it and receives massive, regular updates.
The other way to look at it is, if you wish to learn / code in C# starting to code in 2d is much easier then in 3d. GML resembles java so I didn't have much problem in understanding how things work. The only thing that is bad about GML coding is the coding structure ends up being something you made in NetBeans in a fast pace for prototyping, which is considered bad in software engineering, according to few discussions on dream in code website.
Constructive programming that is implementing everything without using drag and drop is on the other hand much appreciated. I am studying unity 3d, modo and possibly Mari. I want to get away From Autodesk products, but currently I feel like i am being useless if I dont start practicing coding and make a personal website for all the work from portfolio pieces to concept arts to pixel game code snippets. So this is it for me for the time being until I am ready to move back to unity or cryengine.
GameMaker is pretty great, but it does have it's limits. I'd actually consider UE4 for 2d games that aren't necessarily very simple (and has the same advantage of not requiring any prior programmming experience to get started).
Visual scripting is still programming. You are using the same logic as a general-purpose programming language like C++.
Visual scripting allows you to write your own custom actions. There's nothing stopping you from mixing visual scripts and javascript, for example.
The advanatage of visual scripting is speed of development. You can drop an action into your scene, make your connections, and see the result immediately. For smaller indie games, this is much better than spending time waiting for compiles and builds.
Whilst visual scripting does share a lot of the same principles, they are absolutely not the same thing.
Programming languages are systemic and can handle the same tasks as would be handled in assembly. They can build or extend any part of an application, can build an entire application from scratch, and generally include features like memory management that have hefty implications for performance that mean that you are not restricted to (and aren't likely to apply) the basic techniques you might in a visual scripting language.
Scripting languages are implemented directly on top of programming languages and will compile into something that is interpreted by the native code - they are an extra layer on top and as a result they can never match the efficiency of code. This isn't strictly important for small games, but it can have a massive impact on more sensitive things like networking. The most important distinction is that scripting languages will only ever allow you to do what the underlying code has exposed to the scripting language. The moment you want to step outside of those boundaries, you're screwed.
As an interesting example, try making a shotgun that fires 30 pellets simultaneously in your visual scripting language of choice. The caveat is that each shot needs to be individual and the pattern of spread not predictable.
I can compress that network traffic down to about 8 bytes in C++, but in UE4's Blueprint scripting language, you could be using as much as one hundred times the bandwidth or worse...
Whilst visual scripting does share a lot of the same principles, they are absolutely not the same thing.
Programming languages are systemic and can handle the same tasks as would be handled in assembly. They can build or extend any part of an application, can build an entire application from scratch, and generally include features like memory management that have hefty implications for performance that mean that you are not restricted to (and aren't likely to apply) the basic techniques you might in a visual scripting language.
Scripting languages are implemented directly on top of programming languages and will compile into something that is interpreted by the native code - they are an extra layer on top and as a result they can never match the efficiency of code. This isn't strictly important for small games, but it can have a massive impact on more sensitive things like networking. The most important distinction is that scripting languages will only ever allow you to do what the underlying code has exposed to the scripting language. The moment you want to step outside of those boundaries, you're screwed.
As an interesting example, try making a shotgun that fires 30 pellets simultaneously in your visual scripting language of choice. The caveat is that each shot needs to be individual and the pattern of spread not predictable.
I can compress that network traffic down to about 8 bytes in C++, but in UE4's Blueprint scripting language, you could be using as much as one hundred times the bandwidth or worse...
My only point is that visual scripting is still programming. Just because you change the language or the symbols, it doesn't change the requirement of using logic. It may not be as sexy as typing lines of code, but it is a legitimate choice for making many games.
If you want to create your own engine from scratch in C++, that's fine.
My goal is to make relatively simple games using finite state machines that I decorate with pretty pictures. Visual scripting is an efficient tool for that task.
seemed good for tiling the map and character animation, currently you can buy a solo license for as low as $10 or contribute as much as you wish to support this project.
Also @ Ryan; scripting is partial programming as all the libraries are imported for you so you not need to worry about importing any libraries or extending any other relevant class to it. All you need to worry about is creating a function in a specific class.
This clearly resembles the actual programming but if you compare any code with actual java code or C# or even python you will (if you are a programmer,) will debate that its not exactly the code you would expect while coding in a specific game engine or editor there fore you call it scripting since part of the work is done for you.
Open source game engines of any kind are on the other hand require you to know programming back and forth because there is light to heavy coding involved, you cant simply drag, drop and double click the item to stamp a code snippet and / or write a function for it to act according to you in the game (if that makes any sense.)
EDIT: Before starting to code your own game engine or editor I would highly recommend that one should study a current open source game engine like OOgre 3d for 3d and XNA game studio.net for 2d (or 3d,)
To me; these studies seem necessary to be done because if I do these I will understand how things work, there fore if I go back to something like Unity 3d or Unreal, I would know exactly what needs to be done instead of struggling with it.
If typing out code line by line is what you enjoy doing or you believe that makes you a better programmer, cool.
If you want to try and write your own engine or learn how other engines work under the hood, cool too.
The games I work on at home are simple, commercially-viable mobile-oriented games. My preference is to use visual scripting for those kind of games. That's about all there is to it.
I save my typing skills for working on PIC and Arduino microcontrollers.
PIC and Arduino you say!! Then you pretty much dont have to worry about coding anything.
Currently for me, since I have wasted alot of time and I already know coding so I wanted to start something. There fore; I am looking towards this direction.
What you say is true regarding Visual scripting for convenience sake.
Replies
[ame]www.youtube.com/watch?v=T0mGXNE8VIs[/ame]
Yeah, that is oooooooolllllld stuff. It's been around forever, and was pretty much the definitive 2D Indie and hobbyist engine for a while. I think Unity pretty much supplanted it in that field though when it introduced direct 2D support back in 4.0.
These days, even if you want something that simply allows you to circumvent traditional programming you probably have better options. Like Unity + PlayMaker (among other assets).
http://www.openfl.org/showcase/
Sorry for the old news.
Have been playing with it on my free time for a while.. this far I really like it.
The only thing I regret is that I didnt start with it years ago.
I started with unreal and unity (not counting modding) and in all this time I was always reliant on a programmer or a team, and now I can finally make my own games all alone, without anyone setting me constraints.
2 weeks ago I had never touched any form of programming before, and game maker language is so easy and convenient, I already do somewhat complex stuff and can do anything I want with the polish I want, which is just so much fun. Maybe im a special case here, but I really recommend game maker. But only if you want to do 2D, for 3D get something else. Unity is so much complexer already and needs so much more work to get something done, I dont think one replaces the other in any way after doing a lot of unity.
Im having so much fun with it right now, wow.
They also recently put a new update with a asset store and such things. Most game maker games you see suck very hard, but thats not the engines fault, it just mainly attracts unexperienced users. You also dont need to make pixel art, just the tools inside help you make quick pixel art.
Hyper light drifter is also a really nice game made with game maker
[ame]https://www.youtube.com/watch?v=GmMosNHhyxI[/ame]
here is a good tutorial page with some pixel art tutorials as well
https://www.youtube.com/user/uheartbeast/videos
- I would also strongly suggest learning unity and or unreal over or before game maker, especially as a beginner, its just a lot more valuable to know, but id highly recommend for experienced people just wanting to make a game
Unity has a few giant strengths over it anyway.
It costs way less. You can use Unity for free and get much of what you needed out of it for a typical Indie project. Even support for every reasonable platform. Especially a 2D one. GameMaker on the other hand charges a fair bit for every single platform you want to release to, regardless of the scope of your game.
The Asset Store is an extremely powerful source of premade assets, from art to scripts, and even has amazing plugins to improve basic functionality, like Playmaker for visual scripting or SmoothMoves for tweening animations.
Unity is also more stable and reliable. I once tried to play a GameMaker game on my Surface Pro, and it straight up just did not work because of some stupid video driver incompatibility.
Finally, as an industry standard it has comparatively great support behind it and receives massive, regular updates.
[ame]https://www.youtube.com/watch?v=8F1cOvZ3nS8[/ame]
Constructive programming that is implementing everything without using drag and drop is on the other hand much appreciated. I am studying unity 3d, modo and possibly Mari. I want to get away From Autodesk products, but currently I feel like i am being useless if I dont start practicing coding and make a personal website for all the work from portfolio pieces to concept arts to pixel game code snippets. So this is it for me for the time being until I am ready to move back to unity or cryengine.
Visual scripting allows you to write your own custom actions. There's nothing stopping you from mixing visual scripts and javascript, for example.
The advanatage of visual scripting is speed of development. You can drop an action into your scene, make your connections, and see the result immediately. For smaller indie games, this is much better than spending time waiting for compiles and builds.
Programming languages are systemic and can handle the same tasks as would be handled in assembly. They can build or extend any part of an application, can build an entire application from scratch, and generally include features like memory management that have hefty implications for performance that mean that you are not restricted to (and aren't likely to apply) the basic techniques you might in a visual scripting language.
Scripting languages are implemented directly on top of programming languages and will compile into something that is interpreted by the native code - they are an extra layer on top and as a result they can never match the efficiency of code. This isn't strictly important for small games, but it can have a massive impact on more sensitive things like networking. The most important distinction is that scripting languages will only ever allow you to do what the underlying code has exposed to the scripting language. The moment you want to step outside of those boundaries, you're screwed.
As an interesting example, try making a shotgun that fires 30 pellets simultaneously in your visual scripting language of choice. The caveat is that each shot needs to be individual and the pattern of spread not predictable.
I can compress that network traffic down to about 8 bytes in C++, but in UE4's Blueprint scripting language, you could be using as much as one hundred times the bandwidth or worse...
My only point is that visual scripting is still programming. Just because you change the language or the symbols, it doesn't change the requirement of using logic. It may not be as sexy as typing lines of code, but it is a legitimate choice for making many games.
If you want to create your own engine from scratch in C++, that's fine.
My goal is to make relatively simple games using finite state machines that I decorate with pretty pictures. Visual scripting is an efficient tool for that task.
Sorry for bumping this, it's not my intent but I wanted to place another link.
http://pyxeledit.com/features.php
seemed good for tiling the map and character animation, currently you can buy a solo license for as low as $10 or contribute as much as you wish to support this project.
Also @ Ryan; scripting is partial programming as all the libraries are imported for you so you not need to worry about importing any libraries or extending any other relevant class to it. All you need to worry about is creating a function in a specific class.
This clearly resembles the actual programming but if you compare any code with actual java code or C# or even python you will (if you are a programmer,) will debate that its not exactly the code you would expect while coding in a specific game engine or editor there fore you call it scripting since part of the work is done for you.
Open source game engines of any kind are on the other hand require you to know programming back and forth because there is light to heavy coding involved, you cant simply drag, drop and double click the item to stamp a code snippet and / or write a function for it to act according to you in the game (if that makes any sense.)
EDIT: Before starting to code your own game engine or editor I would highly recommend that one should study a current open source game engine like OOgre 3d for 3d and XNA game studio.net for 2d (or 3d,)
To me; these studies seem necessary to be done because if I do these I will understand how things work, there fore if I go back to something like Unity 3d or Unreal, I would know exactly what needs to be done instead of struggling with it.
If you want to try and write your own engine or learn how other engines work under the hood, cool too.
The games I work on at home are simple, commercially-viable mobile-oriented games. My preference is to use visual scripting for those kind of games. That's about all there is to it.
I save my typing skills for working on PIC and Arduino microcontrollers.
Currently for me, since I have wasted alot of time and I already know coding so I wanted to start something. There fore; I am looking towards this direction.
What you say is true regarding Visual scripting for convenience sake.