Goombert
|
|
Reply #15 Posted on: January 04, 2014, 06:46:36 pm |
|
|
Location: Cappuccino, CA Joined: Jan 2013
Posts: 2993
|
Sslaxx, yeah but now that I think about it, what free and open source game creators are there? And I don't mean just a C++ engine or OGRE, but I mean something with scene editing, sprite management and all those goodies. There are like practically 0... I can't even think of one!
|
|
|
Logged
|
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.
|
|
|
Sslaxx
|
|
Reply #16 Posted on: January 04, 2014, 06:54:38 pm |
|
|
Location: UK Joined: Nov 2013
Posts: 72
|
Sslaxx, yeah but now that I think about it, what free and open source game creators are there? And I don't mean just a C++ engine or OGRE, but I mean something with scene editing, sprite management and all those goodies. There are like practically 0... I can't even think of one!
Off the top of my head: Construct Classic is GPL-ed (with commercial game exemption), but Windows only. Game Editor is GPL 3 apparently and cross-platform, but it gets confusing (and potentially expensive) when it comes to making stand-alone non-Windows executables. And Game Develop is closed source, but supports Linux and Win32 natively, and HTML5, and allows commercial sale of your games. Beyond that, there seems to be nothing in active development.
|
|
|
Logged
|
Stuart "Sslaxx" Moore.
|
|
|
Goombert
|
|
Reply #17 Posted on: January 04, 2014, 06:56:31 pm |
|
|
Location: Cappuccino, CA Joined: Jan 2013
Posts: 2993
|
Wow, Game Develop looks the best there, not just in platforms but its interface looks nicer too.
|
|
|
Logged
|
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.
|
|
|
|
|
time-killer-games
|
|
Reply #20 Posted on: January 05, 2014, 03:49:03 pm |
|
|
"Guest"
|
if you aren't a fan of programming Stencyl covers just about all the power GML/EDL in pure DND, while code is completely optional and for every code function, contant, etc this is a DND equivalent for it all. You can also search short keywords and instantly find the DND action you are look for, since after all there's so many to choose from. http://www.stencyl.com/
|
|
|
Logged
|
|
|
|
TheExDeus
|
|
Reply #21 Posted on: January 06, 2014, 06:24:19 am |
|
|
Joined: Apr 2008
Posts: 1860
|
even ones from the 90's that use hardware accelerated graphics, and it also leads to less coding! If you mean do it via the programs GUI then yes. If you mean draw with code, then no. Batching (as we both now know) takes a lot more code than immidate mode. And drawing in ENIGMA/GM is one line per drawing, which is the bare minimum you can actually have. On the other hand the fact that they have GUI's for all of that proves my point that it is a little higher level than ENIGMA/GM as you have already many things included. Which makes GM's system rather counter-intuitive. And this also explains why I had a much easier time learning GDI with Visual Basic than I did with GM's fucked up system. It's actually not counter-intuitive. It's like the debate on GL3 (without FFP) and GL1 (with FFP). When you look for a topic on immediate mode (glBegin/end) deprecation you can see how people (often ones who also teach GL) bitch how GL3 is a lot harder to explain. Because in GL1 you start with drawing - that's it. You make a window and draw a triangle. In GL3 you must at least write two shaders and make VBO's to create one triangle. So while GL3 is a lot more efficient, it is far from intuitive. It takes a lot more code to do simple things and it is a lot harder to learn. And GM in this regard is lower level (as I mentioned before) as you don't do manual batching or push vertices or whatever, but you draw immediately after issuing the draw call. And while this is now batched in both GM:S and ENIGMA, it is still relatively low level. you drag and drop particle emitters and tinker with them in real time to actual see how they will render. But that is my point exactly. I wasn't saying Unity is in any way worse. I was saying that it has a lot of functionality built-in. And that you need to figure it all out. While in ENIGMA/GM you usually write all your stuff on your own. Which for productivity may be bad, but for education it is good. The audio dialog shows the same thing. It has far more options, but that means you need to understand far less. Wow, I never knew Unity's 2d system optimized vertices / polygons like that. Might be enticing to use it over GM for very heavy 2d games... GM:S and ENIGMA also batch vertices. And now you can even make your own VBO's (or just use model functions) to batch.
|
|
|
Logged
|
|
|
|
|
Goombert
|
|
Reply #23 Posted on: January 06, 2014, 05:03:29 pm |
|
|
Location: Cappuccino, CA Joined: Jan 2013
Posts: 2993
|
Harri, you are still way off base. As I mentioned in the Qt hardware accelerated paint scene, you generally don't actually do any painting, you place static text, which is batched one time, and it will always draw until you remove it from the scene, which is different from the 90's style graphics you would be doing with GDI where you have to batch and draw every regular update. Irrlicht does it the same way, Unity3D does it the same way, in fact every comprehensible game engine makes static GUI elements. GM has no method of placing static text in a room. http://developer.nokia.com/Community/Wiki/Archived:Simple_Hello_World_Application_Using_Graphics_View_Framework_in_QtSo again, GM is not designed for easy rendering, or hardware accelerated rendering. The very first thing they should be teaching people is that you don't construct primitives in a regular update loop unless you absolutely have to. But that is my point exactly. I wasn't saying Unity is in any way worse. I was saying that it has a lot of functionality built-in. You don't blindly have to code things, you can code it and view the effects visually. You can actually code how your entity behaves in the scene editor, kind of like if objects handled their draw events while in GM's room editor.
And that you need to figure it all out. While in ENIGMA/GM you usually write all your stuff on your own. And you are still incorrect, because you've never actually tested Unity before. Unity3D can turn off all that built in stuff, and a has WIDE array of extensions, you can add scripts directly to your project that will modify the interface of the Unity editor. You can for instance write a script that brings up a custom dialog for you to import a custom mesh format, or something similar. http://docs.unity3d.com/Documentation/Components/ExtendingTheEditor.htmlWhich for productivity may be bad, but for education it is good. The audio dialog shows the same thing. It has far more options, but that means you need to understand far less. GM isn't good for education either, as I already pointed out, Unity3D is more visual, but somehow magically more powerful too. Also, that argument can not be made about Studio either, or even earlier versions of GM. Because each entity in Unity has an editor only complex as the components attached to it. In Studio for instance, you will always see the sprite options on every object, in Unity3D, you only see that if you attach a material to the entity. Or for instance, you only see the audio options if you attach an emitter, you only see the particle options if you attach an emitter, you only see the phyisics options if you attach a rigid body. You seriously need to venture out and try some different game engines other than GM.
|
|
« Last Edit: January 06, 2014, 05:27:21 pm by Robert B Colton »
|
Logged
|
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.
|
|
|
TheExDeus
|
|
Reply #24 Posted on: January 07, 2014, 05:20:19 pm |
|
|
Joined: Apr 2008
Posts: 1860
|
Harri, you are still way off base. I am not sure if my English is absurdly bad or something, but people keep somehow not understanding me. What you described in the rest of the paragraph is exactly what I described in the paragraph about GL1/GL3. And you are still incorrect The rest of your sentence just said the same thing I did. " WIDE array of extensions", "add scripts directly to your project that will modify the interface of the Unity editor", "custom dialog for you to import a custom mesh format". All that is an example of "And that you need to figure it all out. While in ENIGMA/GM you usually write all your stuff on your own. ". That is in no way a good thing, but it does teach you more. That is what I am saying. I am not saying that a person should use ENIGMA/GM over Unity. I am not saying Unity is bad. I am just saying that for "learning" and "first programming language" you should actually use a tool that requires "learning programming language". GM isn't good for education either It actually started specifically as an educational tool. Mark Overmars was teaching game design and GM was a tool he created to teach that (originally was for animation though). You seriously need to venture out and try some different game engines other than GM. I have. I haven't tried that many tools though. I have used C++ based and Python based engines. I also dabbled with Source a while back, but it's also C++. GM is about the only game tool that I have tried. Hasn't been that many reasons to try something else.
|
|
|
Logged
|
|
|
|
Goombert
|
|
Reply #25 Posted on: January 07, 2014, 07:44:26 pm |
|
|
Location: Cappuccino, CA Joined: Jan 2013
Posts: 2993
|
I am not sure if my English is absurdly bad or something, but people keep somehow not understanding me. I thought you were Aussie? All that is an example of "And that you need to figure it all out. While in ENIGMA/GM you usually write all your stuff on your own. The argument you're making though is equivalent to this. I am going to make an application, but I want it bare bones, so I am going to write it in assembly and or binary. But also, in ENIGMA you can simply add your code to namespace enigma_user and it can become usable just like you would write an extension for Unity3D. In GM you have to mess around with an extension, dll's, and mangling around with scripts that implement callbacks. Not only is GM slower and less optimal by jumping through more hoops, it's also a lot harder to make an extension for. Every part of GM's design is wrong, and ENIGMA only partially corrects some of the issues, but that doesn't change the fact that the whole concept is just fucktarded.
|
|
|
Logged
|
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.
|
|
|
TheExDeus
|
|
Reply #26 Posted on: January 08, 2014, 05:29:36 am |
|
|
Joined: Apr 2008
Posts: 1860
|
I thought you were Aussie? No, I'm not. The argument you're making though is equivalent to this. My argument is that the person here wanted to learn a programming language. Not a tool. That means he wants to start with something which actually requires programming. Like PyGame or some Javascript based thing. Or GM/ENIGMA. And yes, knowing assembly is also very useful as it gives you understanding on how your code works (that is why every CS class I know teaches it). You end up knowing what creates branches, cache misses and so on. And then you can code stuff more optimally. No one has to code anything in assembly though. Just like I wouldn't actually make a game in PyGame, but for learning it would work fine. Every part of GM's design is wrong, and ENIGMA only partially corrects some of the issues, but that doesn't change the fact that the whole concept is just fucktarded. I guess that depends on perspective. I do think, and I doubt I will see anything that changes my made, that GM design is the best, user friendly and one of the productive (even when you have to code everything yourself) game design tool I have ever seen. That is why I still use and develop ENIGMA. It's very easy to learn, very easy to use and when you know enough, it takes minutes (yes, minutes) to create what you want. I have lots of programming tasks at university and if I used anything other than ENIGMA it would take probably a week per task. Now it takes about a day max. So the concept is awesome. It's hard to make it work very fast on hardware as it is more immediate mode than retained mode, but I guess that is one reason it is so easy to learn. And for 2D games the performance is in spades.
|
|
|
Logged
|
|
|
|
Goombert
|
|
Reply #27 Posted on: January 10, 2014, 09:33:32 am |
|
|
Location: Cappuccino, CA Joined: Jan 2013
Posts: 2993
|
My argument is that the person here wanted to learn a programming language. Not a tool. That means he wants to start with something which actually requires programming. Like PyGame or some Javascript based thing. Or GM/ENIGMA. And yes, knowing assembly is also very useful as it gives you understanding on how your code works (that is why every CS class I know teaches it). You end up knowing what creates branches, cache misses and so on. And then you can code stuff more optimally. No one has to code anything in assembly though. Just like I wouldn't actually make a game in PyGame, but for learning it would work fine. Right, if they wanted to learn a real programming language they should definitely learn a real programming language, like BASIC or C# like I did when I was 12. I am by far not a genius I consider myself of average intelligence. GM did not help me learn programming in the slightest, as I have mentioned before I tried to start with GM but moved right on to Visual Studio because I found GM's drag and drop confusing. Later on I came back to GM because it was really the only RAD tool back then for Game Design that actually featured a built in map editor and stuff, BlitzBasic and the other competitors didn't have such features like that back then, but all of that has changed now, there is tonssssss of that stuff that is community led now for those programming languages. As we've already pointed out there are a ton of newer, cheaper, and better RAD tools for game design that take modern approaches as well. And the argument that GM is out of date and out of touch with modern video game design still holds an ocean of water. I guess that depends on perspective. I do think, and I doubt I will see anything that changes my made, that GM design is the best, user friendly and one of the productive (even when you have to code everything yourself) game design tool I have ever seen. That is why I still use and develop ENIGMA. It's very easy to learn, very easy to use and when you know enough, it takes minutes (yes, minutes) to create what you want. I have lots of programming tasks at university and if I used anything other than ENIGMA it would take probably a week per task. Now it takes about a day max. So the concept is awesome. It's hard to make it work very fast on hardware as it is more immediate mode than retained mode, but I guess that is one reason it is so easy to learn. And for 2D games the performance is in spades. That whole paragraph goes against everything we just discussed with you still not directly debating any specifics. The only real evidence that GM is better for learning is that it is more popular than these new tools for game design that have popped up, which is not very good proof at all. Just because something is popular doesn't mean it's the better alternative, especially a product name like Game Maker having such good search relevance. Take for instance the GUI functions I've wanted to add since I got here, something like the following... int gui_label_create(); void gui_label_destroy(int id); void gui_label_set_text(int id, string text); void gui_label_set_position(int id, gs_scalar x, gs_scalar y); void gui_label_set_font(int id, int font);
int gui_button_create(); void gui_button_destroy(int id); void gui_button_set_text(int id, string text); void gui_button_set_position(int id, gs_scalar x, gs_scalar y); void gui_button_set_font(int id, int font); int gui_button_get_state(int id);
These functions when I do get to add them will effectively resolve some of the issues about dynamic drawing. Every game engine has an interface similar to this for GUI controls. I am not talking about widgets like you see in a GUI framework, just hardware accelerated GUI controls, there is a distinct difference between the two, that distinction is mainly software vs hardware. I really really feel you are being biased here Harri.
|
|
« Last Edit: January 10, 2014, 09:47:56 am by Robert B Colton »
|
Logged
|
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.
|
|
|
TheExDeus
|
|
Reply #28 Posted on: January 12, 2014, 12:44:58 pm |
|
|
Joined: Apr 2008
Posts: 1860
|
GM did not help me learn programming in the slightest And this seams very subjective for me. Of course there is no one way to learn programming, but saying GM is bad because it didn't help YOU isn't a good argument either. It did help me. GML was the first programming language I used (did see some Basic code a short while before, but didn't code anything in it) and I didn't use any other language for about 7 or 8 years. Then when I went to university I started using C++ and I found that it's mostly GML. Then I used different languages as well and in the end GML was stepping stone more for me. GML really looks like every language ever - because it has the most relaxed syntax ever. You can write GML that looks like C, you can write GML that looks like Delphi, you can even write GML that looks like python. So for me it helped a lot. Others (especially nowadays) say that Python is something people should start with, and I kind of agree as it is very easy and powerful, but I do dislike it more than GML. I think transition from GML to C (and to C++) is a lot easier than transitioning from Python to C. But I guess all of that is subjective. That whole paragraph goes against everything we just discussed with you still not directly debating any specifics. Because I already said the specifics. Like the past 6 posts is how I say that GM is easy to learn and use - and most probably because the code for rendering is more like immediate mode than retained mode. You then disagree that it is, but then say exactly the same thing I do. Take for instance the GUI functions I've wanted to add since I got here, something like the following... And? You do know that we already discussed this. I already agreed that GM doesn't have these functions and it does everything in immediate mode - and that means it is a lot more straightforward and easier to learn/use. Like with your functions it can take 4 functions to draw text on screen (create, position, set text, destroy) and while it is good for performance, it is easier for a total noob just to use draw_text(). That is exactly my point and you just keep pointing it out while mysteriously disagreeing. I really really feel you are being biased here Harri. I don't think I am. I might be, as the biased one is not usually the one to notice. I don't think I am biased as I (and you) already pointed out everything I wanted to say together with arguments and examples. Also, all of this is mostly subjective. We can analyze it objectively (like I tried to do it here by counting how many functions it is need to do something), but mostly it is subjective.
|
|
« Last Edit: January 12, 2014, 12:47:48 pm by TheExDeus »
|
Logged
|
|
|
|
captainkraft
|
|
Reply #29 Posted on: January 12, 2014, 01:11:02 pm |
|
|
Location: Lincoln, NE Joined: Jan 2014
Posts: 5
|
I thought I'd toss in my two cents.
C++ was my first exposure to programming but it didn't get very deep into the language and I stopped programming for years after that. Once I got to college I learned Java and OOP which is intimidating if you don't have people to guide you through the process.
Next I toyed around with any programming language that seemed interesting. Stuff like Python, AS3, Haxe, C, Ruby, Perl, and on and on. I can't use most of them without lots of references to help me figure out what's going on. The only two languages I can use "fluently" are Java and Haxe (or AS3 - nearly identical). But, even though I am not a pro at most of them, I feel like dabbling exposed me to different paradigms and practices that made me a better programmer.
If you are starting fresh and teaching yourself, I would highly recommend picking a language based on a project you want to complete. I would also recommend bottom-up learning instead of top-down (as much as possible anyway). Basically the difference is that bottom-up would be you learning what you need when you need it and top-down would be following a book to teach you the ins and outs.
If you want to make a small game for your first project, there are a ton of options for languages. Doing some research into the nuances between languages would be a good idea to find out what each language does well (or poorly) so you can choose what and how you want to learn.
Just like choosing a language in the real world, picking your language to learn is dependent on what you want/need to do. Pick the language that seems interesting and does something you would like to be good at. If you aren't sure which language is best for what you want to do, come up with some very specific goals and ask someone to give you some pointers on what language would be best for the job or what language would be best for learning certain concepts.
If you follow my advice it will probably take you a bit longer to "learn to program" (such a broad concept) but you will be better from the beginning and I think you will enjoy the climb better. Programming is all about using the right tool for the job and getting it to work. It's usually not about writing the best code or maximizing performance, especially for solo developers.
PM if you want to ask any more specific questions. I'd be happy to help in any way I can.
Cheers
|
|
|
Logged
|
Build a man a fire: he'll be warm for a day. Set a man on fire: he'll be warm forever.
|
|
|
|