Pages: 1 [2] 3
  Print  
Author Topic: What now?  (Read 1809 times)
Offline (Male) time-killer-games
Reply #15 Posted on: November 22, 2016, 03:38:11 PM

Member
Location: Virginia Beach
Joined: Jan 2013
Posts: 1064

View Profile WWW Email
What's next? The ENIGMA project finally dies. It's been suffering severed legs and continual blood loss over the years. It's for the best. (Y)
Your state of mind amazes me.

In other words ENIGMA is long past its expiration date.
Logged
Offline (Male) Josh @ Dreamland
Reply #16 Posted on: November 22, 2016, 09:33:18 PM

Prince of all Goldfish
Developer
Location: Ohio, United States
Joined: Feb 2008
Posts: 2953

View Profile Email
Just to clarify: ENIGMA doesn't have an expiration date. It's a piece of open-source software, and even without me anywhere near the project, others (particularly Harri) continue to commit to it.

As to whether ENIGMA is headed in the right direction, I suppose that's mostly a question of whether Harri is taking it in the right direction. I believe Harri's work will only serve the project good, even if it's not what I'd do.
Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Offline (Unknown gender) SaulGoodman
Reply #17 Posted on: November 24, 2016, 05:32:32 PM
Member
Joined: Nov 2016
Posts: 5

View Profile
Are you suggesting Harri is doing it wrong? Or that he should have given up long ago also?
Logged
Offline (Unknown gender) Darkstar2
Reply #18 Posted on: November 24, 2016, 09:32:10 PM
Member
Joined: Jan 2014
Posts: 1232

View Profile Email
What's next? The ENIGMA project finally dies. It's been suffering severed legs and continual blood loss over the years. It's for the best. (Y)
Your state of mind amazes me.

In other words ENIGMA is long past its expiration date.

Why would anybody subscribe to this fucking rubbish ! I'd say that ENIGMA has more chance now than it ever had, after what appears to me like GMS 2 is one big sham.  Nothing much new, compiled exe tracking, ridiculous licencening packages, ENIGMA is still a good, free alternative, better suited for windows dev than this GMS trite.

Logged
Offline (Male) time-killer-games
Reply #19 Posted on: November 25, 2016, 03:26:16 AM

Member
Location: Virginia Beach
Joined: Jan 2013
Posts: 1064

View Profile WWW Email
@SaulGoodman - I'm suggesting that to run a real game engine worth using, you need much more than just one developer doing it all. Harri is doing great, but again, he is only one person.

@Josh - what is the max number of active developers and contributors we had working on ENIGMA and LateralGM simultaneously? I'm 99.9% positive it was nothing in the double digits.
« Last Edit: November 25, 2016, 03:32:41 AM by time-killer-games » Logged
Offline (Male) Yambam
Reply #20 Posted on: November 26, 2016, 04:51:14 AM

Member
Location: The Netherlands
Joined: May 2016
Posts: 71

View Profile WWW
Watch out! 'Cause here comes a different perspective on the ENIGMA project!

Quote
GameMaker is an environment in which all tools are provided for your average game developer. One thing, I feel, is missing in these tools... which is a word processor with simple formatting for taking notes, checking off stuff, etc.

-- Me, in a topic I posted in earlier today

Really, what I'm trying to say is there is a potential for an alternative IDE for both starting and more advanced game developers. And there is no need in generalizing "the basic game". Just add in the tools!

  • An overworld editor, for organizing rooms in (a) particular order(s), or in any visual constellation
  • A palette editor, so you can choose colors, clone palettes and drag & drop palettes on the colored elements of your game (e.g. sprites, backgrounds, objects, rooms)
  • A sound environment editor, in which you can organize the different sounds in different areas of your game (cave worlds, (pigs in) space, grassy worlds, mossy worlds)
  • A key/value editor (suggested by Josh @ Dreamland), which can be used upon any (group of) instances
  • A category system, which goes with the different key/value-pairs you would/wouldn't need in different the sections of your game (sunlight), or in different materials, or objects (physical properties; the softness of a breakable block, the opacity of a glass block, the starting HP of an enemy)

I'm just trying to be innovative. So there's no need in taking all this seriously. ;)



Next one. Here's an image that goes with:



See how you are supposed to choose what kind of project you're making, before you even started? It's better than starting your first IDE and being presented with nothing! The different options:
  • Game with Overworld
  • Minigame
  • Innovative Puzzle with tens of stages
  • Daily Puzzle with 200+ stages

You know, these options should just work as option presets and do both of these things:
  • Start you off as developer, full of little ideas, or without an idea what they're starting on
  • Help the IDE in specializing in what the developer wants to create

N.B. Once again, I'm just trying to be innovative and there is no need in taking my rants seriously. ;)
« Last Edit: November 26, 2016, 05:12:01 AM by Yambam » Logged

Offline (Unknown gender) TheExDeus
Reply #21 Posted on: November 26, 2016, 07:30:01 PM

Developer
Joined: Apr 2008
Posts: 1919

View Profile
I doubt I will do anything with this project anymore. It is hard to maintain (especially IDE, which I don't maintain at all) and patchy. Now a much better engine can be written from all the things I learned by making ENIGMA. And even though that engine is coming along slowly, I think I won't have a choice as I need an engine like this myself. My daily work (computer vision based software development + Phd program in which I'm still technically in even if I have taken 2 years off) keeps me swamped as always. But I do see a large need for an easy to use cross-platform engine in which you can make complex games/programs in hours instead of days or weeks and it seems I will have to make it myself. I have tried many engines (like Unity (for which I even made plugins) and UE4 (which influenced large part of my PhD)), many windowing and graphics systems, and none convinced me. Not only all of them have massive dependencies (seriously, ENIGMA is the only engine these days that can make a 2mb executable that even includes all the resources), but they are cumbersome to use and require their own IDE's (just like sadly ENIGMA requires).

So I'm not sure what is next for ENIGMA, but most probably I won't be making it. I am still around and if Josh or anybody else starts doing something I will follow and if I have time then gladly pitch in. Josh is the reason I started C++ programming and making this ENGINE with him and others have been the most useful thing I have ever done, as it has given me skills and knowledge that is hard to acquire any other way. He is clearly much smarter than me in all things software and his way of writing posts (calm, intelligent and to the point) has always starkly contrasted others and so whenever I see a post made by him I have this sense of "new message from god" before reading it - so they are posts that I can look forward to. Like notes from a teacher. I guess that is respect I have for him and had all these years. Imagine - I joined 8 years ago.. Couldn't understand a single post Josh wrote because all I knew was basic GML. Yet as far as I know he is younger than me, which just shows how far in front he was.
« Last Edit: November 26, 2016, 07:35:33 PM by TheExDeus » Logged
Offline (Male) Goombert
Reply #22 Posted on: November 27, 2016, 01:18:26 PM

Contributor
Location: Cappuccino, CA
Joined: Jan 2013
Posts: 3063

View Profile WWW
Josh has displayed amazing precognitive senses over the years and I have about the same perception of him. He's not perfect though, I have noticed some limitations in his omniscience and his humor has certainly rubbed me the right way. Not to mention I now have a mini fridge in my bedroom and Trump is president, so yeah, fuck you.

Anyway I've been looking a lot at Love2D lately and what I like about it is also that it's small and has a comprehensive API. The API is one of the most important parts and working with GameMaker's was always a pain in the ass. Simple things like creating multiple windows or setting render targets almost always entailed an extension. But an IDE is a very important piece of the puzzle. I think going forward a great place for us to start would be like Love2D with an engine that can be used independently of our compiler or IDE through a native command line interface. Much like Love2D with a modular API and develop any scripting language or IDE independently. This is the ultimate way to do it so that really really advanced users can just use the engine as a C++ API or however they choose. I think going forward that would be the best strategy for any new project to replace ENIGMA.

PS: Again I have something to show off that I think ENIGMA people will like but I haven't gotten time to finish it because of black Friday sales and school work. It is close to being completed though.
Logged
Offline (Male) Josh @ Dreamland
Reply #23 Posted on: November 29, 2016, 02:10:58 PM

Prince of all Goldfish
Developer
Location: Ohio, United States
Joined: Feb 2008
Posts: 2953

View Profile Email
I'm floored, Harri; thank you for your words.

Times like this, I feel it's time for me to suck it up and focus more on where this project should be, instead of just on what I'm paid to do for work. I think my issue is that I'm spending all my CS frustration budget on corp infrastructure, so I don't feel like putting up with more aggravation working on personal projects.

Anyway.

@SaulGoodman—My (outdated) understanding of what Harri was doing is that he was trying to embrace pure C++ as the sole language used with this engine. C++ is essentially the best language for the task of developing an engine, and one of the worst languages for developing a game. I will grant Harri that it's still better than GML, which is part of what ENIGMA basically sought to demonstrate... it's unfortunate that ENIGMA's parser (A) was never great, and (B) has not aged well at all. I think the project could be improved just by me fixing that, but I have higher ambitions. I would never imply that someone should give up—only that they should rethink.

To DarkStar's point, ENIGMA does not have an expiration date. As a piece of GPL software written in a language that doesn't seem to age (for better, or for worse), ENIGMA is the sort of thing that can lay dormant and crop back up any time. As it stands, it seems our "Active" developer count is approximately zero. That's a highly impermanent state. As long as there is interest in the project, it will continue to grow. Obviously, we've hit a lull in its forward progress, but I'm not sure where people get the idea that this constitutes death. But the fact that you and I are here, and we are having this conversation, means that ENIGMA is "alive" and well.

@time-killer-games—I am reasonably comfortable bounding the number of active contributors we've had, simultaneously, at eight. The peak of that would be the falling edge of forthevin's presence, here, where we had me, Harri, forthevin, polygone, Robert, and canthelp actively contributing code. I might be missing others who contributed during that time (I can't remember if heathtech and/or dazappa was active then). IIRC, sorlok came later, and TGMG was already gone. IsmAvatar was somewhat active in LGM during that time, and she was assisted by Medo42 and possibly Stian (very fuzzy on the chronology, there). In reality, we've had roughly 15 serious contributors in the project's history. Not to discount those who only made one or two commits—as I've said, interested users are the life of an open-source project.

@Yambam—I think you and I are on the same page.
  • Overworlds, as I've expanded on already in this thread, are very important to me. What you call "constellations" I believe is what I was demonstrating with Super Metroid's map.
  • Color Palettes... I recall mentioning something like this on the Wiki; color palettes may be old tech, but along with vector graphics, I believe they're a great step toward the next generation of game graphics.
  • Sound Environments... I'm not completely sure what you mean, here. You might be describing two things. If you're talking about loading/unloading sound resources for you as you enter different rooms, I didn't just want to do this for sounds, but rather for all resources; the ability to load resources quickly as they become needed for an environment is frequently critical. If you mean sounds that play when you enter a certain region, this would be another great feature of the region-based scripting I described earlier. We could specialize it in the UI for playing/looping sounds; that would be cool.
  • The instance key/value property editor is a must. As I said, though, we also need the room and overworld editors to understand instance values, positional values, bounding box/radius values, and vectors. These particular value types should be represented in the room/overworld editor visually.
  • You may have just unified multiple meanings of "category" that I describe separately. Similar to (3), I wanted labels for resources, so that you can load and unload cave/grass/ice/dungeon resources. But I think what you're touching on, here, is traits. Traits are a kind of design pattern where you can add canned functionality to objects, essentially. In fact, I believe an interface (or Protocol) meets most of the use-cases you describe. These are an important language feature, and I agree they are something the object editor should represent visually. In particular, multiple inheritance allows you to do the sorts of things you're describing. As long as this hierarchy was represented in the object editor, it would be trivial to have the room editor enable editing these "categories" simply as the actual parent object that owns them. Right now, you can have, for example, obj_gold, obj_gem, and obj_treasure_chest all inherit from a parent object, obj_treasure; you can then use constructs such as with() or snippets like instance_nearest(x, y, obj_treasure) to treat all types of treasure as the same, and consider them equally. Generalizing this with multiple inheritance and a concept of traits would accomplish what you seem to be looking for. I've said a lot about this on the Wiki, as well.
I'm not sure how I feel about built-in game templates vs a library of examples. I think a bank of community-contributed examples meets that particular need. This project is sorely lacking documentation (and tests, which can serve as examples). That will be another focus of my attention....



The one thing I will take from Harri's remarks, regarding the direction of this project, is how important it is that the IDE is not the ONLY way to develop with the engine. I believe that if I could conjure up code for an IDE that suits my tastes, Harri would never want to use anything else. But since no IDE will fit everyone's workflow, and some will inevitably prefer their own code or image editors, it's important that the compiler is invocable without an IDE.
« Last Edit: November 29, 2016, 04:05:37 PM by Josh @ Dreamland » Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Offline (Male) Garo
Reply #24 Posted on: December 03, 2016, 07:01:49 PM

Member
Location: Szczecin, Poland
Joined: Sep 2014
Posts: 26

View Profile
So to confirm. Does this mean that ENIGMA for now lacks any active maintainers? I'm assuming that now that the GL3.3Normal branch has been merged, there's at least SOME of the functionality that TheExDeus has written up in the past progress reports, right? I feel like that sort of stuff should probably be documented in some way or form, or at least given a few examples. New functionality is there, but nobody knows how to use them unless they take the time and hours to experiment or search through the source code.

A part of me thinks that there should be something done about the vision of the engine, in general. Initially, it was made to replicate GameMaker's functionality, then, later on, it was decided to slowly make it it's own thing. Now it sort of sits in limbo between the two. My general question with this is: What to do? Which direction to poke the engine towards? Personally, I think it should be the latter, but without entirely shedding away from all of the stuff GameMaker offered. I've taken a look at some of the progress stuff at the Progress page of the site, and while I don't know when has it last been updated, how much of it still applies? I honestly don't know. I feel like the general ToDo list on the page should be updated to include some of the more critical things that's apparently bothering the core engine, such as the parser, or the fact that the debugger isn't entirely reliable.

I am speaking of this from an average developer's point of view. I'm not an expert in C++ (Never really sat down to seriously do anything with the language itself, mostly a C# dev these days), and I doubt I'll ever be, though I feel like after years of watching the progress, I feel the urge to do SOMETHING, but I never know what. It's really fun to play around with some of the 2D stuff in the engine (not a 3D guy here, but I also assume it's not black magic), but I sometimes hit a snag here and there, be it scripts annoyingly doubling on the amount of escape spaces, or not entirely knowing with what to do with the particular debug call on some reference to an ID of an object I'm unable to find. The IDE is fine for me (mostly), it does what it does, can't complain. I maybe can do something about maintaining the Wiki (just how OLD are some of those pages?!), but I haven't done anything on a larger scale before, just small and minor edits. There would be a need to have someone to help point people in the right direction.

I hope you don't mind my rambling all too much, just that it's a little confusing for a guy like me as it stands now, among developers who know a lot better of the engine than I do.
Logged
Offline (Male) Yambam
Reply #25 Posted on: December 04, 2016, 10:42:56 AM

Member
Location: The Netherlands
Joined: May 2016
Posts: 71

View Profile WWW
1. Overworlds, as I've expanded on already in this thread, are very important to me. What you call "constellations" I believe is what I was demonstrating with Super Metroid's map.
Yes exactly. I thought I'd loosen the concept of the world being a grid of rooms by making up the term 'constellations' for it. :)

2. Color Palettes... I recall mentioning something like this on the Wiki; color palettes may be old tech, but along with vector graphics, I believe they're a great step toward the next generation of game graphics.
Palettes could sure be useful. Not exactly in old terms, where every sprite has a palette which can be manipulated dynamically. Just being able to give different game elements new colors in new environments could be useful. In a way, it could replace certain color shaders, I think (grayscale, sepia, night vision).

3. Sound Environments... I'm not completely sure what you mean, here. You might be describing two things. If you're talking about loading/unloading sound resources for you as you enter different rooms, I didn't just want to do this for sounds, but rather for all resources; the ability to load resources quickly as they become needed for an environment is frequently critical. If you mean sounds that play when you enter a certain region, this would be another great feature of the region-based scripting I described earlier. We could specialize it in the UI for playing/looping sounds; that would be cool.
I mean something like a place where you can 'test' different sounds and organize them into cave/grass/ice/dungeon, like you said. Like a kids' audio book, where each page is a different situation(/environment), like the shed of a farm, or the pigs' place; you can press the picture of the pigs and you hear an oink, etc. xD

4. The instance key/value property editor is a must. As I said, though, we also need the room and overworld editors to understand instance values, positional values, bounding box/radius values, and vectors. These particular value types should be represented in the room/overworld editor visually.
This. It would also need a clear UI, could be very useful! Don't forget that 'manually' having to edit things like image_[xy]scale is very tedious in comparison to having the right tools for scaling/translation/flipping (and the like) at hand.

5. You may have just unified multiple meanings of "category" that I describe separately. Similar to (3), I wanted labels for resources, so that you can load and unload cave/grass/ice/dungeon resources. But I think what you're touching on, here, is traits. Traits are a kind of design pattern where you can add canned functionality to objects, essentially. In fact, I believe an interface (or Protocol) meets most of the use-cases you describe. These are an important language feature, and I agree they are something the object editor should represent visually. In particular, multiple inheritance allows you to do the sorts of things you're describing. As long as this hierarchy was represented in the object editor, it would be trivial to have the room editor enable editing these "categories" simply as the actual parent object that owns them. Right now, you can have, for example, obj_gold, obj_gem, and obj_treasure_chest all inherit from a parent object, obj_treasure; you can then use constructs such as with() or snippets like instance_nearest(x, y, obj_treasure) to treat all types of treasure as the same, and consider them equally. Generalizing this with multiple inheritance and a concept of traits would accomplish what you seem to be looking for. I've said a lot about this on the Wiki, as well.
I actually have an example of categories! I don't know if it actually has a name, but that's what I call it.

https://gist.github.com/Yambam/da6d2849fcb964a59d06a6d7e2558bbc
This document shows how the various keys of the MySQL database of my website "IndieMendable" is organized into categories.

I also did some reading on interfaces and traits/mixins this week, since I didn't know what you meant when I read your reply haha. It seems that it's more like interfaces, or even protocols (different classes being able to interact and get information about each other using similar methods). I'm also finally grasping more concepts of C# and Java's OOP! xD

I'm not sure how I feel about built-in game templates vs a library of examples. I think a bank of community-contributed examples meets that particular need. This project is sorely lacking documentation (and tests, which can serve as examples). That will be another focus of my attention....
I'm not sure, how we are going to make these tests? This does remind me of a very useful feature of LilyPond/Frescobaldi's notation reference (it's an open-source music type-setting software). The (generated) reference shows graphical representations of the music, the snippets of which can be downloaded and opened in Frescobaldi, which is to LilyPond as GameMaker is to GML. When browsing the (seemingly local) documentation from inside Frescobaldi, trying to 'download' .ly files will open them in a new (single file) tab!

What I meant with my paragraph under the image was just a means of telling the IDE what you're going to make. It will then leave out everything except the features you need to get started. Later on you could check some boxes in the preferences in order to add some unique elements (like adding an overworld to a previously specified puzzle game). I'm not too sure of this idea though. It could also just make things more obscure.

The one thing I will take from Harri's remarks, regarding the direction of this project, is how important it is that the IDE is not the ONLY way to develop with the engine. I believe that if I could conjure up code for an IDE that suits my tastes, Harri would never want to use anything else. But since no IDE will fit everyone's workflow, and some will inevitably prefer their own code or image editors, it's important that the compiler is invocable without an IDE.
Yes this is also something important to take into consideration. Some of the people on ENIGMA forums suggested a single file code editor for all events/attributes of an object. I'm actually against this workflow, since I think it's a good thing GameMaker seperates these pieces of code.

Also, using external editors (e.g. Audacity) in GameMaker are kinda weird; you get all these weird unhelpful filenames (a133299.wav). That shouldn't have to happen...
Logged

Offline (Male) polygone
Reply #26 Posted on: December 06, 2016, 11:50:53 AM

Contributor
Location: England
Joined: Mar 2009
Posts: 810

View Profile
There where only two reasons ENIGMA didn't succeed where it could have:

1) Nobody completed a godamn IDE to anywhere near the level we needed
2) No offence to anyone but there was no super-active developer with the very high-end expertise required. Me, robert, forthevin and harri where all highly active and did what we could with our limited skills, I think between us we got ENIGMA to a position where it needed to be for the lower-level easier stuff but there was always the more higher-level aspects missing which nobody had the knowledge to tackle except Josh.

If I had Josh's skills and knowledge or Josh had the commitment that Robert had then ENIGMA would have got to the place it needed (as long as someone else actually came along and got a decent IDE up and going).

ENIGMA isn't dead yet but it's only chance of succeeding still is if Josh's long-lost unemployed twin stumbles across the project and decides to be fully committed to it. Only then it may stand a fighting chance.
Logged
I honestly don't know wtf I'm talking about but hopefully I can muddle my way through.
Offline (Unknown gender) faissaloo
Reply #27 Posted on: December 06, 2016, 03:09:03 PM

Member
Joined: Jan 2013
Posts: 71

View Profile Email
ENIGMA isn't dead yet but it's only chance of succeeding still is if Josh's long-lost unemployed twin stumbles across the project and decides to be fully committed to it. Only then it may stand a fighting chance.
Hi.

For real though, I'd very much like to contribute more, the issue is that it's not clear what actually needs to be done (aside from bugfixes obv), there's not enough of a detailed plan, just ideas being thrown around with very little idea about how they would actually fit into the project. I've been spending time trying to teach myself the codebase for a while now (mostly SHELL, still don't have much intimate knowledge of the compiler and JDI is still something I don't really understand).

Also, everyone's thinking about an IDE, and if I may say I have a vision where there is no IDE but a set of independent tools, a resource tree editor, an editor for rooms, an editor for objects, an editor for sprites etc so that people can swap out tools easily.
« Last Edit: December 06, 2016, 03:22:46 PM by faissaloo » Logged
Offline (Male) Josh @ Dreamland
Reply #28 Posted on: December 06, 2016, 06:06:40 PM

Prince of all Goldfish
Developer
Location: Ohio, United States
Joined: Feb 2008
Posts: 2953

View Profile Email
So to confirm. Does this mean that ENIGMA for now lacks any active maintainers?
Not for any serious definition of "Active." Contributors are sending in code a month or so apart, now. Myself included, actually. So we have nibbles, but not active development. The project is currently best described as "maintenance mode." Note that in industry, that's a pretty grim prognosis. Note also that I am not worried.

I'm assuming that now that the GL3.3Normal branch has been merged, there's at least SOME of the functionality that TheExDeus has written up in the past progress reports, right? I feel like that sort of stuff should probably be documented in some way or form, or at least given a few examples. New functionality is there, but nobody knows how to use them unless they take the time and hours to experiment or search through the source code.
I believe that was the remainder of what Harri meant to add. Documentation is thin no matter where you go; ENIGMA is no exception. I don't see a technical writer in the cards, and no one else wants to do that sort of thing.

A part of me thinks that there should be something done about the vision of the engine, in general. Initially, it was made to replicate GameMaker's functionality, then, later on, it was decided to slowly make it its own thing. Now it sort of sits in limbo between the two. My general question with this is: What to do? Which direction to poke the engine towards? Personally, I think it should be the latter, but without entirely shedding away from all of the stuff GameMaker offered. I've taken a look at some of the progress stuff at the Progress page of the site, and while I don't know when has it last been updated, how much of it still applies? I honestly don't know. I feel like the general ToDo list on the page should be updated to include some of the more critical things that's apparently bothering the core engine, such as the parser, or the fact that the debugger isn't entirely reliable.
Vision isn't the problem. This thread's full of people's thoughts on where the project should be heading, and those thoughts would put us in an amazing state. There's not a need for a "throw out all the GML" revolution; the GML functions we implement may be unhippily non-OOP, but they're all that's required to make a game of any size. I suppose I haven't said much about my plans for ENIGMA's language (EDL) here. They are large and complicated and include a full-blown type system, generics (of all variance, with specialization), first-class functions, and comprehensions with lambdas. Note that our familiar library of C-namespaced utility commands in no way conflicts with this.

I hope you don't mind my rambling all too much, just that it's a little confusing for a guy like me as it stands now, among developers who know a lot better of the engine than I do.
I appreciate your thoughts, and welcome your contributions (even maintaining the Wiki ;)).

I mean something like a place where you can 'test' different sounds and organize them into cave/grass/ice/dungeon, like you said.
Interesting. I suppose being able to view texture atlases and having a sound test board for various environments/resource groups would be quite useful. Sounds like a nice feature to plan.

Don't forget that 'manually' having to edit things like image_[xy]scale is very tedious in comparison to having the right tools for scaling/translation/flipping (and the like) at hand.
Certainly. I believe we've had numerous requests for this feature, since even Yoyo managed to add it.

I'm not sure, how we are going to make these tests? This does remind me of a very useful feature of LilyPond/Frescobaldi's notation reference (it's an open-source music type-setting software). The (generated) reference shows graphical representations of the music, the snippets of which can be downloaded and opened in Frescobaldi, which is to LilyPond as GameMaker is to GML.
Unit testing (and integration testing) is a solved problem. The tests would be run automatically by Travis or the like (ENIGMA actually has one now, thanks to Cheeseboy, of all people). Don't think of it in terms of Travis playing games in ENIGMA. We wouldn't test things like playing sound—only things like the correct sound decoding occurring. This is possible simply by bundling compressed audio and making sure, eg, the proper codecs are invoked to create the output sound buffer. For FLAC, especially, this is quite easy. We can store a few kilobytes of FLAC and WAV in a test environment, and verify byte-for-byte that decompression succeeded. There are testing frameworks for graphics (even websites). The point is, there are ways to make sure that an application is behaving correctly.

Some of these tests will make good examples: consider tests of the object heredity system, for example. This test would work by creating an instance of objects that are children of various parent objects, and then verifying that the correct objects are considered in functions like instance_nearest. It could also be used to make sure that the correct inherited events are fired (either graphically or by use of console_show_message, for example).

We can also take advantage of mocks for creating better (quicker to run) testing setups.

What I meant with my paragraph under the image was just a means of telling the IDE what you're going to make. It will then leave out everything except the features you need to get started. Later on you could check some boxes in the preferences in order to add some unique elements (like adding an overworld to a previously specified puzzle game). I'm not too sure of this idea though. It could also just make things more obscure.
I believe this is more prone to obscuring things, personally. In general, if you're going to make a platform game, you probably just want to start with a platform game template. Not a whole lot of people want to create engines for people to abscond with, but it does happen. I don't think we could just bottle them up. That would be more of a Stencyl design goal.

As for hiding things, I like to think a well-designed IDE wouldn't require it. Look at MS Word over the ages. You'll see the feature creep you're trying to avoid come and go, for better and for worse. There will be some learning involved in presenting users all and only what they need, but we shouldn't try fitting that to specific game types. Relying on that will just hurt people; we want to keep ENIGMA general-purpose.

Also, everyone's thinking about an IDE, and if I may say I have a vision where there is no IDE but a set of independent tools, a resource tree editor, an editor for rooms, an editor for objects, an editor for sprites etc so that people can swap out tools easily.
As I said, I believe that supporting this workflow is a good idea, but requiring it is a grave mistake. The features of Game Maker's IDE are everything that made the project any good. Its language was inadequate, its workflow was somewhat messy; coding-wise, it was a nightmare. The fact that it loaded all your resources for you was a huge part of why people loved it, but was only half of the picture. You would not enjoy using Game Maker without a room editor. I know that some games don't require one, at all—look at Minecraft. But again, look at Super Metroid. You wouldn't want to make Super Metroid without the editors I have described, here. There's just so much extra work you're doing for no good reason. With 3D games, people have come to accept that you can't have a canned editor. In particular, I believe Harri is holding the inadequacy of GM's room editor as evidence that there's nothing to be gained from having it, but for most users, that just isn't so, and if someone actually invested the effort into making a better room editor, I imagine Harri would want to use it, too.

For real though, I'd very much like to contribute more, the issue is that it's not clear what actually needs to be done (aside from bugfixes obv), there's not enough of a detailed plan, just ideas being thrown around with very little idea about how they would actually fit into the project. I've been spending time trying to teach myself the codebase for a while now (mostly SHELL, still don't have much intimate knowledge of the compiler and JDI is still something I don't really understand).
I can give you a roadmap or a full task breakdown, or any granularity in-between. What's currently "on my plate" (in the scope of things I am looking at doing) this:
  • Replace JDI with LibCLang. JDI is the system that reads function definitions from ENIGMA's engine. In the good old days, we maintained a text file that had a list of defined functions in it. Eventually I started migrating that file into headers, and then I realized, wait; why not just read the headers? So I wrote JDI, a C++ parser. It wasn't great at the time, and has not aged well.

    LibCLang can parse ENIGMA's engine, just fine. It offers an interface (of questionable API stability) to retrieve that definition information. This will allow ENIGMA to understand what data you have access to.

    I have actually already written code that can do this, but adapting it to the current system is not an easy task. It's therefore one I'm not interested in, as I seek to replace the existing system. This brings us to our next point.
  • Re-code the parser to actually generate syntax trees. Currently, the parser essentially uses a find-and-replace strategy to insert parentheses and semicolons where they are needed. Building a tree will be necessary to add the new language features we want. I am personally breaking this down into a few smaller tasks:
    • Code a lexer to break UTF-8 encoded text into tokens. I am personally doing this by building a trie with wildcard paths, so that I can build a prefix tree of essentially regular expressions to extract tokens. I have only just started this; haven't resumed work, recently.
    • Write methods to handle basic code constructs, such as if, for, while, switch...
    • Declare a table of operators, with precedence flags and RTL markers. This should be a map of token type to data structure.
    • Write a handler for all operators in that table.

There are hidden nuances in the bullet points of the second table, which arise from functionality of this language about which I am not certain. A few key points I want are as follows:
  • The language should define a module system to define compilation units and supplant the private/public keywords Java uses for everything. This does not concern ENIGMA, but is important to me as I want ENIGMA's IDE to be written in EDL.
  • The language should have full-blown reflection and complex macros to facilitate the DSLs people tend to fuck up without language support. This is why I'm overkilling the lexer mechanism.
  • The language should have getters and setters, or possibly full-blown listeners. This is required for some features of the engine.
  • The with() construct should not be a part of this language, but rather, a construct defined by ENIGMA (preferably using features of the language itself). Essentially, with() should be a macro defined to accept an expression followed by a statement.
  • I am interested in the possibility of embracing Rust-like variable ownership and lifetimes.

This is all to do with the compiler. As for the engine, it's mostly bug fixes, because we need a lot more compiler and IDE support for more feature progress, there. It's not like we're missing fundamental building blocks: the engine supplies all the tools you need to make literally any kind of game. Could we add more features? Probably. But we're mostly just down to stability problems because the compiler and IDE suck.

One of the engine's biggest problems is the lack of a broad-phase collision check (we have no spatial partitioning, for example, because we need to update that whenever you assign to x and y, and I never felt right about doing that when people usually say x=foo, y=bar; in immediate succession). We can technically overcome that, now.

Otherwise, most of the "engine problems" are from the extension system being crap, the object inheritance model being underpowered and poorly implemented, and the parser constantly blowing a fuse and putting semicolons where they don't belong.

Missing features boil down the same way. The compiler doesn't allow setting resource load hooks, defining dynamic library dependencies, or grouping objects and other resources (except by direct, single-parent heredity for objects). The IDE allows making basically any kind of 2D game that doesn't use environmental scripting.

What I'm trying to convey is, if you aren't seeing much to do, it's because you're looking at the engine, and barring some bugs (which evade even my awareness), there aren't any serious missing features (except broad-phase collisions). The forward progress of this project depends immensely on the compiler and IDE.
Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Offline (Male) time-killer-games
Reply #29 Posted on: December 07, 2016, 03:03:53 AM

Member
Location: Virginia Beach
Joined: Jan 2013
Posts: 1064

View Profile WWW Email
this is a lot to read. i couldn't poop a log half the length of this thing printed out. that says a lot, i have really long poops.
Logged
Pages: 1 [2] 3
  Print