ENIGMA Development Environment
Website is in read-only mode due to a recent attack.

Show Posts

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.


Messages - Josh @ Dreamland

526
Ideas and Design / Re: ENIGMA Entity-Component-System?
« on: October 21, 2013, 01:16:24 AM »
Indeed; I stopped reading around the time he ceased using punctuation in high frequency and just started asserting random ideas. He repeatedly states that this system is better than the "traditional inheritance hierarchy" while giving no indication that he has considered multiple inheritance/typical interface-based systems as an alternative. From what I can tell, this system is identical to multiple inheritance, except the ability to swap out components at runtime. This, he seems to handle using boost::dynamic_bitset to flag entities as having certain components. Personally, the solution makes me want to rip off my own skin, but it's cool if you're into that.

Since ENIGMA's extensions don't change out at runtime, it handles this by keeping lists of items which are known to have what you're calling "components." Instances add themselves to the proper lists on creation, and remove themselves from them upon destruction. You could do the same thing dynamically by just creating classes to handle this automatically, and simply pushing them onto some list in the instance and popping them off and deleting them when done: the ctor/dtor for those classes would take a pointer to the entity (here, instance) and handle everything for you.

That brings me back to my original question: why would you ever want to do this?
This reminds me of a lecture I had to sit through on decorator patterns. I can see this as being a fantastic and brilliant replacement to decorators. To clarify, my question at the time was, why, oh why, would you ever use a decorator?


My assessment of your ability to achieve this easily in either of Game Maker or ENIGMA has not changed. In game maker, nothing is to stop you from setting object.has_component to true, or checking if it has been set. Unfortunately, same in ENIGMA.

That said, I will look into making sure that quickly stapling attributes to objects is possible at runtime. My primary focus, however, will remain on doing so at compile time.

527
Ideas and Design / Re: ENIGMA Entity-Component-System?
« on: October 20, 2013, 05:22:56 PM »
Game Maker already makes that simple, if ugly. Consider this:

Code: (EDL) [Select]
// The parent object's draw event
script_execute(renderer);

// The parent object's step event
script_execute(physics);
for (i = 0; i < number_of_arbitrary_behaviors; ++i)
  script_execute(arbitrary_behaviors[i]);

// Somewhere that wants to demonstrate how "a Ninja could become a Tank!":
myninja.renderer = scr_render_tank;
myninja.physics = scr_physics_tank;
myninja.arbitrary_behaviors[0] = scr_ai_tank;
myninja.arbitrary_behaviors[1] = scr_armor_tank;
myninja.number_of_arbitrary_behaviors = 2;

In GM, any object can call any script. So essentially, you can already do that with either of function pointers or script references and script_execute. So, as long as all of your behaviors are scripts, you can already use this system.

I don't care for this as a design choice; my preference is virtual functions, which are planned. Multiple inheritance is also planned, so that you can inherit multiple behaviors which cannot be changed at runtime.

Disclaimer: This capability is the exact reason Game Maker is slow, and using it will make you quickly discover how slow ENIGMA can be.

In fact, it used to be that ENIGMA would not support this method, until polyfuck changed it. The reason for this is simple. Say scr_tank_armor processes collisions in self.collision, and changes self.armor accordingly. What if a Ninja doesn't have self.health? In GM, that isn't relevant; variables are stored in a hash table, so all variables can exist in all objects, and so we have variable_local_exists, et al, to help us. In ENIGMA, that just isn't the case. So if your behaviors don't all use the same variables, ENIGMA will resort to polygone's map of vars by varname, and you'll get all the speed of var (about 12x slower than double) and all the speed of map.find() (hundreds of times slower than an assign) at no extra cost.

If you have a compelling reason to change behaviors at runtime, then by all means, store a pointer to some behavior class which contains its own variables to modify. Of course, then behaviors can't share variables, and you'll need to work that out by having the health behavior know of or extend the physics behavior so it can respond to collisions... Mess, mess, mess.


The new EDL specification supports or will support the following to help deal with this:
  • Multiple inheritance. Right now, each object can only have one parent, so with (enemy) { health -= 1; } might be useful, and with (destructable) { if (distance_to_object(other) < 64) instance_destroy(); } might be useful, but since no object can be both destructable and enemy... Well, now they can.
  • C++ Classes: The new EDL specification (available in the Wiki) calls for classes which can have fields, inheritance, and virtual functions. Everything you need to make these behaviors as separate classes.
  • Closures: Perhaps the element about which I am most doubtful, EDL2 calls for closures. This is catalyzed greatly by C++11's own support for lambdas. A closure is a function that inherits the scope in which it is created, so assignments in the function will change the variables in the calling object. My understanding of C++11's implementation of this is limited; if it's anywhere near as capable as JavaScript functions, this will prove an invaluable asset for dynamic design. Of course, JavaScript offers methods such a bind(), which would make implementing GM's scripts less of a kludge, so I'm not expecting quite that much power from C++11.

That said, you can probably tell that this component-based system is not my favorite design element. I would never use it unless I had a glaring need for a tank to become a ninja, or vice-versa. It sounds powerful and disarmingly fun and silly until you realize that it may be the dumbest and most harmful capability employed by your engine. There's always a trade-off.

ENIGMA's extension system uses multiple-inheritance. A long time ago, when Rusky was interested in the ability to change out fucking graphics systems at runtime, there was a battle over this structure versus components. I have yet to encounter a reason to embrace components for the task, and in general do not encourage them, but if you have one, I'm interested in hearing it.

528
Tips, Tutorials, Examples / Re: Setting up External Editors
« on: September 06, 2013, 09:45:15 AM »
Most people would expect you to write the setting without attempting to change the theme knowing it would fail.

529
Tips, Tutorials, Examples / Re: Setting up External Editors
« on: September 05, 2013, 06:53:36 PM »
Robert: That is part of LGM's original functionality. I have no idea what compelled you to map that properties file to a UI dialog without mentioning, "by the way, %s indicates the filename and, odds are, your program will want to know that."

Thanks for sharing, Ben.

530
General ENIGMA / Re: Contributing to the Wiki
« on: September 05, 2013, 08:33:28 AM »
Templates take time to propagate when edited. My preference would be to have pages requiring that link to instead link users to the correct download page on the Wiki. That said, I'm not opposed to the idea.

I should point out, though, that down the road, we will be adding a feature to this website for serving the latest version of ENIGMA. I'm not sure how far down the road we're talking about, so at this point, do whatever.

531
Third Party / Re: CLI and new IDE for Enigma
« on: September 02, 2013, 10:21:47 PM »
Heheheheh... I am very curious as to how these IDEs will turn out. Our third contender is, of course, NaturalGM. The projects vary in projected capability; let me give my honest (and skeptical) opinion of each really quick.

Contender 1: canthelp's (ssss's) project, Game Editor
The pros:
Being written in Python, this IDE has grown up extremely quickly. It borrows code from LGM and ENIGMA's code bases, as well as from Robert's IDE's codebase. In addition to that, it is by far the most functional and quickest growing of these IDEs. It may come as a surprise that in general, the IDE performs better than LGM, which is powered by Swing rather than Qt. This IDE is also being tailored largely to the needs of ENIGMA, which means it is likely to have the new features we need.
The cons: Everything in this IDE kind of melts together. Plugins are doable only by virtue of python being a scripting language. The author will attest to the code being quite messy. The user has to install Python to be able to work with this IDE.

Contender 2: Robert's C++ LateralGM
The pros:
Being completely native and designed specifically with ENIGMA in mind makes this IDE an obvious choice for a new user. Thus, like canthelp's IDE, we're likely to see the resources we've planned out within a few releases. In addition to the speed problems, this IDE seeks to address the EGM/GMX loading issues from its Java predecessor.
The cons: While focus has gone into keeping the file readers and writers modular, not a lot of attention thus far has been paid to general modularity. The individual editor components are not themselves separate; there is a lot of interdependency that is unlikely to be sifted out. Maintaining this IDE will also take back seat, as Robert is generally preoccupied with other facets of ENIGMA.

Contender 3: DaSpirit's NaturalGM
The pros:
Spirit has taken care to ensure modularity of each component of the IDE. It is (as far as has been seen) possible to develop a resource plugin for NaturalGM without regard for other resource plugins in the system, which means the odds of us finally adding an overworld resource to the mix are great (we should be able to duplicate the path editor plugin and go from there—its functional requirements of the remainder of the system are identical). Additionally, this should help ensure that users wishing to add their own resource types to ENIGMA are able to do so easily, as both IDE and engine will be able to accommodate them.
The cons: At this point in its development, I can't isolate any concrete issues with the software. That in itself is the only issue: at its present state, NGM is mostly backbone, but the backbone is shaping up comparatively well. The issues that I am able to foresee have all been addressed; only time will reveal any remaining problems as he starts on the concrete implementations.

532
General ENIGMA / Re: Contributing to the Wiki
« on: September 02, 2013, 09:49:48 PM »
Really appreciate the work you've done, Ben. Thanks a ton!

533
What error does ENIGMA fail with? That part's probably easy to fix.

534
Issues Help Desk / Re: Parenting and even inheritance
« on: August 29, 2013, 04:35:11 PM »
I told polygone to implement a new AST node for me, but he gave up in roughly the expected time. I'm taking a break from the compiler long enough to work with Ism on the EDC's new cloud server. It has been a bigger pain in the ass than anticipated. Both, actually. If you've been keeping an eye on JDI's progress, you'll notice the C parser in the branch throws roughly twice as many errors parsing <string> as the one in ENIGMA. That's the bad news. The good news is that it is parsing with 100% accuracy, which is both the source of the errors (if it can't parse accurately, it throws errors instead of assuming A-OK), and the reason that the new compiler is able to do the advanced type inference required for OOP.

I understand that in addition to the new features I want to see in ENIGMA, a lot of the longest-lived bugs are counting on the new parser. There's not much I can do about it unless I want to take another shortcut, which will only mean repeating this again in so many months.

On the plus side, the reason for my lack of free time is working against itself: I took courses over summer and am graduating in a few months. This will mean a brief transitional period wherein my output is even less than right now, followed by a time where the bulk of the stress in my life is between the hours of 9-5, and, if all goes according to plan, 20% of that stress will be this project.

535
General ENIGMA / Re: Compiling from source
« on: August 29, 2013, 04:25:11 PM »
What? The default OS is supposed to be Windows, as it is the only operating system too incompetent to identify itself from the CLI. I don't know where it's getting that ---------- shit.

536
Issues Help Desk / Re: Mouse over event
« on: August 26, 2013, 09:42:49 PM »
Each step, set a mouse_xprevious and mouse_yprevious. You can then get the direction using point_direction(mouse_xprevious, mouse_yprevious, mouse_x, mouse_y), and likewise, the speed using point_distance(mouse_xprevious, mouse_yprevious, mouse_x, mouse_y).

To also test if the mouse has passed through your object, use this:
Code: (EDL) [Select]
if (collision_line(mouse_xprevious, mouse_yprevious, mouse_x, mouse_y, obj_myobject, true, true)) {
  double dir, spd;
  dir = point_direction(mouse_xprevious, mouse_yprevious, mouse_x, mouse_y);
  spd = point_distance(mouse_xprevious, mouse_yprevious, mouse_x, mouse_y);
  // ...
}
mouse_xprevious = mouse_x;
mouse_yprevious = mouse_y;

537
Off-Topic / Re: Introductions
« on: August 26, 2013, 08:36:27 AM »
Welcome aboard, Ben. Thanks for the help!

538
This is what happens when people edit code without bothering to check for things such as "does my code still compile?" before committing upstream. I've added .c_str() to the caption parameter Harri passes to the GTK functions. Try compiling now. If that doesn't work, let me know, and I'll set it up so I can fix the rest of them tomorrow.

539
Off-Topic / Re: Do you like this forum software?
« on: August 23, 2013, 07:57:25 AM »
This site is completely integrated into the Simple Machines forum software. The Wiki account system, the EDC, the issue tracker: all of these use the SMF developer API to work with accounts. I don't really feel like recoding them, and I haven't heard any volunteers.

Moreover, "It's ugly" is never reason not to use anything. Ugly can be fixed. We have complete control over the templates, including the private message box. Your problem with the private message system is an option which you are capable of enabling yourself—it just isn't the default. You can enable it by selecting the As a conversation view instead of All at once. As a special note, if you don't save a copy of your message in your outbox (also not the default), it won't display in the conversation. You can enable doing so by default from your PM settings, too.

I'm guessing MyBB doesn't support that, since you've never heard of it before. User preferences aren't really an uncommon feature of SMF, as opposed to in hacked-together, 20KB pieces of forum software I could write myself in a couple of hours.

That said, if you have any legitimate reasons not to use SMF, go ahead and post them.

540
General ENIGMA / Re: Learning to develop?
« on: August 21, 2013, 07:40:09 PM »
1. C++. If you'd prefer to develop a different language plugin for ENIGMA, we'd be happy to support it, but the work would be enormous (Unless you're interested in continuing the existing, but very early, JavaScript port).
2. Git's pretty easy to pick up on. Most of us learned from small tutorials on the internet; I can't find the one I used, but I'm sure the others are just as good.
3. You can start flamewars asking what constitutes "Good coding practice." I can't even tell you "just comment your code well," because lately, the trend has been "self-documenting code," which uses functions so tiny as to be self-explanatory. In the words of my journalism advisor: just try not to suck.
4. It is certainly preferable to use Linux, as the package manager can fetch and set up all your tools for you. However, a good number of our developers use Windows, and MSys-Git comes packaged with the ENIGMA zip.

The basics of Git are pretty simple. The idea is this: everyone has a local copy of the entire git repository, history and all. Because of this, no one versions binaries; doing so causes terrible bloat, as you have all the previous versions checked out at all times. On the plus side, you can commit and use all features of version control locally. Everyone can, even without having repository access. You only need credentials when you're ready to publish your changes.

When you obtain changes from the Internet, it's called a pull. So basically, we enact changes, you pull them. When you publish changes, it's a push.

Our publishing is handled through GitHub. GitHub makes it easy to fork a repository; you just sign in and press the "fork" button. A fork is just a copy of the repository which you own entirely; you are free to make any modifications to it you like (per the terms of the license of the code, which, in our case, is GPL). When you are satisfied with the changes you've made to your fork, you can drop a pull request to the owner of the repository (in this case, us), and after reviewing your changes, they'll decide whether to accept, or pull them.

When I go to commit changes, I usually start by running git status to see what's changed. That way, I can see if I'm about to accidentally commit a file that doesn't belong in the repo. You'll notice the Windows developers use a UI frontend for git, and carelessly commit binaries to the repo all the time. By listing the files before committing them, I usually avoid that. After checking status, I run git add --all and then git reset HEAD <file> for any files I didn't want to add, if any. Usually, those files go in .gitignore, a file listing what files and directories git should ignore. After that, git commit or git commit -m "My commit message" to commit them, and then git push to publish them, if they're ready.

Words of caution: I think the git checkout command is one of the few commands capable of destroying something you've worked on. I have never found a way to undo it.

As far as developing, I don't really have any words of caution for you. Something to note is that if a check needs done to avoid users performing invalid operations on something, we try to confine those checks with #if DEBUG_MODE, so as to avoid slowing the engine down on trivia where the check takes longer than the operation.