Pages: 1 2 3 4 »
  Print  
Author Topic: New Beginnings  (Read 5654 times)
Offline (Male) Goombert
Posted on: May 31, 2014, 10:13:52 AM

Developer
Location: Cappuccino, CA
Joined: Jan 2013
Posts: 3110

View Profile
Ok, there has been a lot of discussion of creating a fork of ENIGMA which actually fixes some things in GM. I am beginning to seriously consider this now.

The purpose of the fork is not to remain compatible with any other program, and takes the GM approach in a fundamentally different direction allowing for greater optimization and an intuitive redesign.

Some of the features and differences would be as follow:
* Windowing system would be completely abstract allowing the creation of multiple windows.
* No fake fullscreen, aspect ratio handled natively by the display.
* No view options in room editor and no global constants, views can be controlled via screen_set_viewport functions, because there is an efficient trick to speed up games by allowing two views to be rendered in the same draw call.
* Revamped non-retarded implementation of the audio_* functions.
* Complete redesign of graphics allowing not only vertex buffers but index buffers and instance geometry, with a proper bridge of OGL and D3D and not just a tacky way of emulating D3D by use of an OGL backend like ANGLE.
* Branching path system with improved A* motion planning.
* Cross-platform video interface for hardware accelerated video playback and rendering.
* All resources handled as included files, each will have a "preload" option and if it is unticked you have to load in manually using _load* functions asumming that all resources are extracted locally to the executable, but you will still be able to control how the resources are extracted, kind of like in Visual Studio
* Completely unrestricted file hierarchy, the IDE will also support loading multiple projects at once, and will support only one file format.
* Because the IDE will use a single uncompressed file format, the IDE will also be much quicker with loading and saving and compiling projects.
* CLI programs will exist for building projects outside of the IDE
* Non-object oriented method of compiling and linking code into your game.
* Possibly, strict C++, meaning no GML or EDL and no hybrid language, pure C++, variant type would remain most likely however, only differences would be more strict syntax, which ENIGMA kind of already has anyway.
* File reading/writing revamp, will support the ability to work with multiple INI files at once.
* Script redesign, they will be actual source files, if you want them to act like functions in GM you will have to prototype the function, not sure what to do about forward declarations.
* As a result of the script redesign, there will exist an object resource, but the object structure will be redesigned to allow you to easily and simply code an object using a script, so for instance if an object has a sprite it will inherit an object_sprite class, if it has a model it will inherit an object_model, if it has physics it will inherit object_physics, or a combination of these entities. An event listener and stack may be created similar to Java, C#, or Qt Also important to mention the object resource will not be removed, it will remain allowing a more graphical approach to create an object.
* Possible drag and drop redesign that will follow a more schematic approach like you often see with material/shader editors.
* Certain aspects may follow a more entity component style system, for instance, since views will be removed, you will be able to place camera/projection entities in the room to accommodate, which will also allow you to control aspects such as fog. Unsure of how to handle instance translations and properties however, as it will be dependent upon what entities their prototype class inherits.
* Full threading support, atomic and immutable types etc.

This project will basically allow us to address things immediately by doing them our own way, discussion of feature and implementations will not revolve around compatibility vs. incompatibility. These are simply ideas floating in the air, but I am seriously consider turning this into a practical implementation. I am just sick of working on something that I can't improve or innovate with. Suggestions and feedback is welcome. The project also has no name yet and is simply a proposal.

NOTE: This project would be licensed the same as ENIGMA once licensing for ENIGMA is established.

Just to put some names into the hat or some keywords to work with for a name:
Perform - not an acronym, pretty simplistic
Fluid or FLUID - possibly an acronym, meant to be intuitive, has no relation to F.L.U.D.D.
Formulate - key term, relates to variables/formulas/equations/functions
« Last Edit: May 31, 2014, 12:06:03 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.

Offline (Unknown gender) egofree
Reply #1 Posted on: May 31, 2014, 10:24:14 AM
Contributor
Joined: Jun 2013
Posts: 603

View Profile Email
* Possibly, strict C++, meaning no GML or EDL and no hybrid language, pure C++, variant type would remain most likely however, only differences would be more strict syntax, which ENIGMA kind of already has anyway.

For me, one of the most important aspect of GML and ENIGMA is the ease of use. If you impose C++, you will repel a lot of people, including myself. In this case, why bother ? Let's code everything with C++ and OpenGL. No need of GM or ENIGMA  ;)
But who will do this project ? You said you don't have much free time anymore  :D
Logged
Offline (Male) Goombert
Reply #2 Posted on: May 31, 2014, 10:28:38 AM

Developer
Location: Cappuccino, CA
Joined: Jan 2013
Posts: 3110

View Profile
Yes but egofree, you aren't considering that ENIGMA already has very poor compatibility with all the bullshit syntax of GM. Only real difference is you would need to start placing ; after every line, which I always did with GM anyway. To me it honestly doesn't affect ease of use at all. And it ensures your code won't break with future releases, it also removes the overhead of needing your game to be parsed before compiled. It can simply be copy and pasted and compiled.
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.

Offline (Unknown gender) egofree
Reply #3 Posted on: May 31, 2014, 10:43:13 AM
Contributor
Joined: Jun 2013
Posts: 603

View Profile Email
Only real difference is you would need to start placing ;

You are joking, right ?!!  :o  ;)
I don't pretend to know really C++, i've done only a little bit at university. But what i remember is that from me it was the least pleasant language to read. We have more modern managed languages, so i don't see the pleasure to manage again pointers hell !
In this case, why bother about C++ ? Let's code everything in assembly, as you don't even need to compile the code !  ;)
Logged
Offline (Unknown gender) egofree
Reply #4 Posted on: May 31, 2014, 10:45:28 AM
Contributor
Joined: Jun 2013
Posts: 603

View Profile Email
It's a little bit off-topic, but do you still want to support ENIGMA ? As you are the only developer doing it for the moment, if it's not the case, for me ENIGMA will be a dead project.
Logged
Offline (Male) Goombert
Reply #5 Posted on: May 31, 2014, 10:49:18 AM

Developer
Location: Cappuccino, CA
Joined: Jan 2013
Posts: 3110

View Profile
Who said anything about pointers? All modern managed languages C#/Java are pretty strict with ';' and they are both very easy to read. Also resource identifiers will still be numerically unsigned, the only difference is that they will be reusable, so for instance if you delete sprite #3 and then add a sprite it will take that sprite identifier, so it will act like a pointer. Actually, since pointers kind of act like integers, there may in fact be no need to differentiate the two, in fact using pointers would probably be just fine, in fact, Studio does use pointers now for some of its resources.

Yes I would continue to support ENIGMA, another goal of this project is to potentially help ENIGMA better identify with itself, so in other words, be less confused about its sexuality. I would continue to work on both projects in fact. My project will allow breathing room from GM, allow developers to be innovative and get creative about approaching certain aspects of development, and allow ENIGMA/GM users an advanced step up to a more intuitive and efficiently designed engine. This would also probably lead to less bugs, a lot of ENIGMA's issues are related to incomplete discussions regarding GM compatibility, GM compatibility in fact inhibits a lot of ENIGMA's functionality.
« Last Edit: May 31, 2014, 10:53:31 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.

Offline (Male) Rusky
Reply #6 Posted on: May 31, 2014, 12:32:11 PM

Resident Troll
Joined: Feb 2008
Posts: 955
MSN Messenger - rpjohnst@gmail.com
View Profile WWW Email
Anything intentionally breaking compatibility with GM needs to focus on a better workflow and experience for experimenting with game design. You've got several good internal, technical improvements you could get even when staying similar to GM, but there are conceptual changes that would make things much easier to use- make everything as immediately visible and directly modifiable as possible.

Component-based entity design is pretty much essential. It doesn't necessarily need to be entity/component, although that is a good, clean, efficient way to do it. This is primarily an editor feature to let people describe game objects by which behaviors they have. User components also need to be first class, able to provide just as rich editor interfaces as built ones. They would ideally written exactly the same way as built in ones, which should really be replaceable to avoid engine bloat.

Josh's build mode is also pretty essential- it makes design much easier, and makes many kinds of experimentation possible that otherwise would just never happen. A good design would let this run in the editor itself with an instrumented version of the engine to combine it with profiling and debugging. It doesn't even have to be used only when the game is run- it could be used to preview individual objects, effects, etc. Also, time rewinding is cool.

Good D&D is also essential to ease of use. The phrase "design and build quality games quickly and without code" on the old GM website is the reason I downloaded it as a kid. D&D itself was lacking- just a Scratch/Stencyl-like interface, ideally with the ability to type things in as well as discover them in lists, would be a major improvement, because it's not modal so you can see and edit a script all from one view. Construct has a variant of this where you pick things from drop down menus rather than dragging from a different area, which I actually like (and it makes the typing side of it make even more sense).

Even better, however, would be something like Subtext, which takes all the data flow hidden in off-screen variables and makes it immediately visible and modifiable. The variable D&D actions are another hurdle that can be reduced not only for ease of beginners, but ease of anyone trying to understand and debug the code. Something like this, combined with keyboard controls on the same level as directly typing in code (think supercharged intellisense rather than keyboard shortcuts), could even completely replace textual programming.

Another advantage of this kind of scripting interface is error handling. A visual and highly-intellisensed language can be much more statically typed, without sacrificing ease of use. Anything that now pops up an error message in the middle of the game, potentially getting missed by the developer, and potentially getting all useful debug information stripped out in a release build, should be caught at compile/edit time if possible. The visual part of the design can even make several classes of errors impossible to express, making it even easier to learn and understand.

Rather than trying to fit these kinds of features into an engine, the engine should be designed around these features. If something makes it harder to do time rewinding, or Subtext-like scripting, it should be rethought before the interface design. Interface design and behavior is key. It's easy to forget this as a programmer, but it's the first and biggest thing end users see. Excusing bad interface design with an internal technical reason is worthless.
« Last Edit: May 31, 2014, 12:40:16 PM by Rusky » Logged
Offline (Unknown gender) Darkstar2
Reply #7 Posted on: May 31, 2014, 12:46:28 PM
Member
Joined: Jan 2014
Posts: 1244

View Profile Email
For me, one of the most important aspect of GML and ENIGMA is the ease of use. If you impose C++, you will repel a lot of people, including myself. In this case, why bother ?

He just put the final nail in ENIGMA's coffin.  :D  Looks like we're all headed back to our roots very soon :D :D

The first person who makes an extension in GMS to bring back some deprecated windows functions back, including video, improving on existing functionality, or anything worthwhile, including bringing back external resource access _add functions, I'll be their first customer when they release it in the new extension store.

Talk about  drastic actions ! lol.  Not everyone has the time or could be bothered to code their game in pure C++ ! I guess that defeats the entire purpose and would not attract any people that's for sure and would probably push existing users away.
Ease of use and speed. 

Quote
Let's code everything with C++ and OpenGL. No need of GM or ENIGMA  ;)

Exactly, if imposing strict C++ then might as well use that.  The product would target only one market......Advanced C++ coders.

Quote
But who will do this project ? You said you don't have much free time anymore  :D

Our existence is infinitely multiplied across a span of parallel universes.  He may be working already on this in another dimension. :P

Nothing prevents being a unique product and not compatible to GM but for the sake of ease of use adopting some GML/EDL functionality.  Making a strict C++ scripting that has to be one of the worst ideas !  Not every developer has years time and intentions of writing millions lines of code to do their games.   :D
Logged
Offline (Unknown gender) Darkstar2
Reply #8 Posted on: May 31, 2014, 12:48:47 PM
Member
Joined: Jan 2014
Posts: 1244

View Profile Email
ase, why bother about C++ ? Let's code everything in assembly, as you don't even need to compile the code !  ;)

LOL ! Good idea mate, I say we do direct binary whilst we're at it ! :P :D
Logged
Offline (Male) Goombert
Reply #9 Posted on: May 31, 2014, 01:11:01 PM

Developer
Location: Cappuccino, CA
Joined: Jan 2013
Posts: 3110

View Profile
Very nice Rusky, I like your assessment. Some of the things I disagree with you on, but mostly I agree. While I do agree with you saying it should be designed around these features, I am not sure about a bottom-up approach. In a way I am suggesting a bi-directional approach to redesigning GM being developed discontinuously.

And yes as far as your design mode suggestions, one of the things that need seriously considered are to what degree the program needs certain parsing capabilities for reflection and things. Interestingly LLVM provides nice reflection features.
http://llvm.org/releases/3.0/docs/ReleaseNotes.html

As for drag and drop, you also gave me another idea as far making it more powerful, directly editing the code translation of a schema node. We could also parse the engine and collect all functions making them directly usable in the drag and drop mode. So you could essentially toggle between a graphic and textual representation of your objects.

Quote from: Darkstar2
He just put the final nail in ENIGMA's coffin.  :D  Looks like we're all headed back to our roots very soon :D :D
What the hell does any of this have to do with ENIGMA? And besides, I just addressed this question above.

Quote from: Darkstar2
Talk about  drastic actions ! lol.  Not everyone has the time or could be bothered to code their game in pure C++ ! I guess that defeats the entire purpose and would not attract any people that's for sure and would probably push existing users away.
Ease of use and speed. 
Despite the fact it maintains a variant data type? You literally wouldn't even notice the difference is what I'm saying. Irrlicht is pretty fucking popular, so is Unity, in fact a lot more popular than GM and all 3 of its scripting languages (C#, JavaScript, and something else) enforce ';'

Quote
Making a strict C++ scripting that has to be one of the worst ideas !
You wouldn't notice the difference, and second a lot of people would prefer it, myself included. It would also make your code a hell of a lot more portable.
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.

Offline (Unknown gender) Darkstar2
Reply #10 Posted on: May 31, 2014, 01:53:45 PM
Member
Joined: Jan 2014
Posts: 1244

View Profile Email
LOL.

I wouldn't notice the difference are you joking ?

You said you would restrict to C++ only, no GML, EDL etc...... Again defeating the whole purpose.  How wouldn't we notice the difference ?  I sure know the difference between coding in pure C++ and pure GML. !
and I'd notice the difference even drunk !

Yeah you mention unity and others, those have a steep learning curve and cater a more advanced market.  Some people may have creativity and tools but lack coding skills, this is what GayMakerStudio targets, poorly, yes, but it's easy to use and also offers more advanced functionality to those who want to use it (GML, Shaders, etc.)

More so, there are many C++ / skilled coders who also would use GM and such, as sometimes coding is not the only limiting factor, but time is........ Not everyone has months/years time to write billion lines of code for a simple game.  One of the selling points aside from ease of use is speed.
Some people are hobbyists and don't necessary want to make games for commercial release and spend 2 bloody years working on their games like most commercial games with an entire dev team!

So by your strict C++, this means that what I could do with 1 or 3 line of GML, I'd have to do in 20 lines of C++ code ! Nice.

 
Logged
Offline (Male) Goombert
Reply #11 Posted on: May 31, 2014, 02:11:15 PM

Developer
Location: Cappuccino, CA
Joined: Jan 2013
Posts: 3110

View Profile
You wouldn't notice the difference because variant would remain, and you already don't notice the minor differences in ENIGMA, since EDL does not fully support GML yet, not even close. The only real difference you would immediately notice is having to ';' at the end of each line. GML is practically C anyway, there's not much structure to it.

Unity caters to the lowest common denominator and so does YYG. Also those C++ coders you speak of are also probably bitching like crazy over the fucked up syntax, lack of ISO, and restricted functionality. The very act of featuring C++ would actually make them much more inclined to use such software, since they are by definition, C++ coders, not GML coders, which is what you referred to them as.

And also no, this would further cut down on the amount of coding you would have to do, it would also eliminate the need for extensions, since you could directly access resource structures for instance.
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.

Offline (Unknown gender) Darkstar2
Reply #12 Posted on: May 31, 2014, 02:29:05 PM
Member
Joined: Jan 2014
Posts: 1244

View Profile Email
not even close. The only real difference you would immediately notice is having to ';' at the end of each line.

That's what I've always been doing anyway, the end line ;.

What I am referring to is with GML or whatever name given, you can do things with fewer lines of code.  If I wanted to draw text centered vertically and horizontally on screen, it's easy:

draw_set_valign(fa_center);
draw_set_halign(fa_center);
draw_text((room_height/2),(room_width/2),"Hello World");

Result: Hello world centered on screen.

That's 3 lines of code.

So now you are telling people to fuck off and go learn C++ and do the same task in multiples of lines of code and in C++.

Now this is a simple example.  Now imagine more complex shit that has dozens or more lines of GML code, file reading, processing etc, so asking your users to use C++ !

Quote
GML is practically C anyway, there's not much structure to it.

I am not talking in terms of structure but code. 

Quote
C++ coders you speak of are also probably bitching like crazy over the fucked up syntax, lack of ISO, and restricted functionality. The very act of featuring C++ would actually make them much more inclined to use such software, since they are by definition, C++ coders, not GML coders, which is what you referred to them as.

So basically this caters to advanced developers and pushes away any beginners or people looking for creation speed and ease of use.  Counter intuitive.  This is like YYG all of a sudden saying they would drop GML functions and require all their users to use C++ in their projects, no more GML, if you want to draw a circle, draw text, move sprites, you have to do it through C++.

Quote
And also no, this would further cut down on the amount of coding you would have to do, it would also eliminate the need for extensions, since you could directly access resource structures for instance.

and exponentially increasing the amount of time required to a finished product, no ?
Logged
Offline (Male) Goombert
Reply #13 Posted on: May 31, 2014, 02:44:37 PM

Developer
Location: Cappuccino, CA
Joined: Jan 2013
Posts: 3110

View Profile
Ah, yah no, in fact, my engine would probably handle that in one line.

gui_create_label((room_height/2),(room_width/2),"Hello World");

Since, of course, I am not an asshat like Dailly and recognize the need for static text. And those functions are functions for use with GML, they don't really have anything to do with the language, I'm talking about syntactical structuring, and for some reason you think that's relevant.

That said if you can't recognize this, and you don't like C++, then my engine is not for you, stick with ENIGMA/GM or w/e you're comfortable with.
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.

Offline (Unknown gender) egofree
Reply #14 Posted on: May 31, 2014, 02:52:57 PM
Contributor
Joined: Jun 2013
Posts: 603

View Profile Email
If you want to throw away GML and EDL, what about using C# instead of C++ ? From my point of view it's much more friendly than C++, it has compiler on Windows, Linux and Mac (mono), and Microsoft says the future of C# is open source and it's also possible now to make very fast applications with .Net Native :

Code: [Select]
.NET Native gives you the performance of C++ with the productivity of C#.
http://blogs.msdn.com/b/dotnet/archive/2014/04/24/dotnetnative-performance.aspx

But again if think if GM was so successful, despite all its flaws, it's because it has the reputation to be very easy to learn. Well, i know that you could explain to users that the only difference between GML and C++ is only the semi-colon at the end, but i doubt they would listen to you !  ;)

Anyway Robert, that's was only my two cents. I am always grateful for all the work you've done and all the support you give on this forum, and whatever you want to make, it's YOUR decision, and i will wish you the best in any case !  (Y)
« Last Edit: May 31, 2014, 02:55:25 PM by egofree » Logged
Pages: 1 2 3 4 »
  Print