This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 »
136
Developing ENIGMA / Re: Game End Return Value
« on: April 14, 2014, 11:25:58 pm »
It makes more sense than asking for a return value from System.Quit
137
Developing ENIGMA / Re: Game End Return Value
« on: April 14, 2014, 09:32:38 am »
It returns the first argument of the next run of the game, which starts at that call.
138
Off-Topic / Re: Windows XP's demise will help linux ?
« on: April 13, 2014, 03:56:41 pm »
I know which one I picked (also throw a package manager in there)
139
General ENIGMA / Re: Unicode Fonts
« on: April 13, 2014, 09:49:43 am »
UTF-16 is a terrible idea. string_length on UTF-8 is slow and extremely complicated to write correctly. The majority of GM and ENIGMA games don't need Unicode for anything but random symbols. If you do want to use Unicode for other languages, GM's string interface is not the way to do it. An i18n interface would be better.
140
Off-Topic / Re: Windows XP's demise will help linux ?
« on: April 12, 2014, 08:46:59 pm »
They're certainly comfortable to Mac fans
141
Off-Topic / Re: Windows XP's demise will help linux ?
« on: April 12, 2014, 12:27:18 pm »
Windows 8.1 Update finally put back in the start menu (not just button), and lets you run Metro apps in windows on the desktop. With that, you can leave Metro behind completely, which will probably (sadly and strangely) be enough to pull most of those Linux movers back in.
142
Announcements / Re: Heartbleed
« on: April 11, 2014, 07:08:24 pm »
Technically what Heartbleed enables is for the attacker to look at the server's OpenSSL heap, which may contain private keys or passwords if they look long and hard enough, which would then enable them to listen in on secured connections.
So yeah, good news.
So yeah, good news.
143
Announcements / Re: Project Mario
« on: April 06, 2014, 11:13:51 pm »
Visualization tools for arbitrary parameter types, like points, colors, shapes, paths, resource references, etc. doesn't force you, softly or otherwise, to make anything. For the specific example of transforms in the room editor, it's easier to do level design, but that's the whole point of the tool. I think as long as they're not cookie-cutter style (which the ones we're talking about are not), and especially if you can reuse them, make new ones, apply them to different scenarios, then it makes the editor more powerful and thus versatile rather than less. For example, it would be easier to use Unity to make a sound mixer than GM- the higher level tools let you see the mixer interface you're creating in real time, the visualization tools let you see how things are going to affect each other with graphs, etc. The high level constructs make things more versatile because you're spending less time in the low level details.
As far as the type system, I'm not really talking about statically declared verbose types. One idea that would keep 80% compatibility with GM is just to give all values their own type, but keep everything dynamically typed and scoped. This way the debugger would know what stuff is, more errors would be caught (with descriptive error messages), etc. The next change would be static scoping so you get less runtime "variable doesn't exist" errors, real autocomplete on object members, etc. Finally, using statically-decided types (with type inference and/or picking the type through the GUI so it's not verbose or annoying) would give you nice visualization tools in the runtime, even better autocomplete (because you know the types of variables in the editor), etc.
The point of these changes is not to force or encourage you into a specific way of doing things. It's to give you more direct, immediate access to your end result. This makes the loop between "try something, check if it works, go back and tweak it" much smaller, in many cases reducing it to simply seeing something onscreen in the editor that directly corresponds to the behavior you're describing. This makes it much faster to try things, lets you notice more possible cases you have to handle, and lets you explore possibilities you otherwise may have never even thought of. There's still tons of room for GM to be better at general purpose before it starts specializing more.
As far as the type system, I'm not really talking about statically declared verbose types. One idea that would keep 80% compatibility with GM is just to give all values their own type, but keep everything dynamically typed and scoped. This way the debugger would know what stuff is, more errors would be caught (with descriptive error messages), etc. The next change would be static scoping so you get less runtime "variable doesn't exist" errors, real autocomplete on object members, etc. Finally, using statically-decided types (with type inference and/or picking the type through the GUI so it's not verbose or annoying) would give you nice visualization tools in the runtime, even better autocomplete (because you know the types of variables in the editor), etc.
The point of these changes is not to force or encourage you into a specific way of doing things. It's to give you more direct, immediate access to your end result. This makes the loop between "try something, check if it works, go back and tweak it" much smaller, in many cases reducing it to simply seeing something onscreen in the editor that directly corresponds to the behavior you're describing. This makes it much faster to try things, lets you notice more possible cases you have to handle, and lets you explore possibilities you otherwise may have never even thought of. There's still tons of room for GM to be better at general purpose before it starts specializing more.
144
Announcements / Re: Project Mario
« on: April 06, 2014, 01:13:50 pm »
I'm not talking about the built in features of GM or Unity or anything else. I'm not talking about how "versatile" they are, since Unity is at least as versatile as GM (all those "tabs for everything" are accessible from your own code, so it's strictly better). I'm talking about the interface to whatever features are there, regardless of if they're built in or user-created or whatever.
Unity has a nicer interface for that because it's higher level- you work in terms of reusable components so you can say (whether it's a built in or user-created component) "this object does this and this and this," whereas in GM you have to describe objects in terms of the implementation of those behaviors. In GM terms, you could describe this feature of Unity as something like multiple inheritance, with the ability to pass arguments to the parent.
Visualizing parameters to objects/components like Josh described is another example of being higher level. This does not, in any way, turn it into a less versatile engine. It makes it a more powerful editor because you can iterate faster, describe your intent more directly, etc. GM:S's room editor, build mode, etc. are examples of improvements in this direction.
One issue with GML that limits this kind of thing is the type system. Because everything that's not a string or double is hidden behind an index, the editor and debugger can't do much to help you out- they have no idea of that variable is a number, a ds_list, a sprite, whatever. Because variables are dynamically typed, the editor/language can't catch errors as early (you often have to wait until runtime when it's actually triggered and it's not guaranteed that that will happen even before you release the game). Not only that, but hiding most types behind indices (basically weak typing) means that many of these errors won't even be caught, but rather just cause weird behavior.
This kind of thing is why it's harder to make nice games in GM, and easier in something like Unity. This is why GML is an objectively less powerful language- you can describe the same results, but there are fewer/worse tools to get there (and make sure you actually are where you intend to be).
Unity has a nicer interface for that because it's higher level- you work in terms of reusable components so you can say (whether it's a built in or user-created component) "this object does this and this and this," whereas in GM you have to describe objects in terms of the implementation of those behaviors. In GM terms, you could describe this feature of Unity as something like multiple inheritance, with the ability to pass arguments to the parent.
Visualizing parameters to objects/components like Josh described is another example of being higher level. This does not, in any way, turn it into a less versatile engine. It makes it a more powerful editor because you can iterate faster, describe your intent more directly, etc. GM:S's room editor, build mode, etc. are examples of improvements in this direction.
One issue with GML that limits this kind of thing is the type system. Because everything that's not a string or double is hidden behind an index, the editor and debugger can't do much to help you out- they have no idea of that variable is a number, a ds_list, a sprite, whatever. Because variables are dynamically typed, the editor/language can't catch errors as early (you often have to wait until runtime when it's actually triggered and it's not guaranteed that that will happen even before you release the game). Not only that, but hiding most types behind indices (basically weak typing) means that many of these errors won't even be caught, but rather just cause weird behavior.
This kind of thing is why it's harder to make nice games in GM, and easier in something like Unity. This is why GML is an objectively less powerful language- you can describe the same results, but there are fewer/worse tools to get there (and make sure you actually are where you intend to be).
145
Announcements / Re: Project Mario
« on: April 05, 2014, 11:59:05 am »
TheExDeus: You could always have made your own 2D components in Unity (in a much nicer language than GML), it was just geared toward 3D with the builtins. I could easily pull the same kind of crap on GM by showing a bunch of 3D stuff that you'd have to implement from scratch that Unity has built in. This is unrelated to my point. My point is that once you'd done that (and while you were doing it), Unity would provide much better tools for designing, iterating, and debugging. I don't really care what's possible or even easy to implement the first time, I care how easy it is to model data, visualize, tweak, iterate, etc. GM fails here; ENIGMA has the potential to be a lot better with build mode, Josh's post above, etc.
Some other interesting ideas for property editors would involve animation stuff.
Some other interesting ideas for property editors would involve animation stuff.
146
Announcements / Re: Project Mario
« on: April 04, 2014, 08:35:16 pm »
I should be clear that my claims were about GM, not necessarily ENIGMA, which (as with the example of build mode) has plenty of room for improvement without (and with) breaking GM compatibility, although there are still probably a few things that would be nice but make it fundamentally different from GM.
The "high level" nature of these improvements is more to do with the editor interface and its static knowledge of the object's implementation than the capability of the API. Unity's property editors for component parameters, for example, supports a lot of visualization that GM (or for that matter ENIGMA) is nowhere near. Build mode is entirely an interface thing- it doesn't add any ways to organize the game itself.
"High level" here means things like direct manipulation and immediate results, not really anything to do with language constructs per se.
The "high level" nature of these improvements is more to do with the editor interface and its static knowledge of the object's implementation than the capability of the API. Unity's property editors for component parameters, for example, supports a lot of visualization that GM (or for that matter ENIGMA) is nowhere near. Build mode is entirely an interface thing- it doesn't add any ways to organize the game itself.
"High level" here means things like direct manipulation and immediate results, not really anything to do with language constructs per se.
147
Announcements / Re: Project Mario
« on: April 04, 2014, 05:17:31 pm »
Unity just happens to have been built for 3D, and they only recently tacked on 2D. The features I'm talking about apply equally to 2D and 3D games.
I'm thinking in particular about components/multiple inheritance/whatever you want to call that system for better reuse of entity behavior, along with the editor interface that goes with it- nice visualizations, build mode, rewinding, etc.
Some of these are simple to add to ENIGMA without changing the GM-like base, such as build mode, and some are not.
I'm thinking in particular about components/multiple inheritance/whatever you want to call that system for better reuse of entity behavior, along with the editor interface that goes with it- nice visualizations, build mode, rewinding, etc.
Some of these are simple to add to ENIGMA without changing the GM-like base, such as build mode, and some are not.
148
Developing ENIGMA / Re: Changes in the new compiler
« on: April 04, 2014, 04:39:50 pm »
There is just one .git directory; submodules have a .git file with "gitdir: ../.git/modules/<name>" or whatever in them. There's also .gitignore, .gitmodules, etc. that you may want to ignore as well (and that a GitHub zip would still have).
149
Announcements / Re: Project Mario
« on: April 04, 2014, 04:28:07 pm »
I was thinking more along the lines of Unity...
150
Announcements / Re: Project Mario
« on: April 04, 2014, 04:11:27 pm »
GM has crappy games because it's easy to use... and harder than necessary to make good games with. This is the limitation that matters. There are new tools (and alternate conceptions of existing ones) that other game engines have or could have that GM does not, that make it easier to focus on the game design and polish and spend less time on bookwork. GM is actually relatively low-level as far as describing game behavior goes.