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

Pages: 1 2 [3] 4 5 ... 186
31
All your assets are yours, yes, and the pre-ENIGMA source code is completely your property. This is for the same reason that works created in GIMP or InkScape or even MS Paint are yours. Your game is a work you have created in ENIGMA, and probably various other tools. You may license it how you wish.

But that's not the whole story.

When you compile your game in ENIGMA, it is transpiled (a specific synonym for "compiled") to C++. The code it generates still belongs to you (just as the code InkScape or Flash generates still belongs to you). But then ENIGMA links your game's source against its engine. This is where things get hairy.

Because our engine is GPL, your use of it in combination with your source code (ENIGMA-generated or otherwise) subjects you to the terms of the GPL. Thus, you are free to use and modify it locally however you want, but as soon as you release it to the public, you must provide source code. And because the GPL is a viral license, you must also provide all source code that links against it. This means you must provide the source to your game.

It gets worse. The GPL is crafted in such a way as to prevent companies or groups or individuals from providing only obfuscated versions of the source code, which by some definitions, ENIGMA-generated source code qualifies. Specifically, the GPL defines source code to be "the preferred form of the work for making modifications to it." So that means the plain GML/EDL, like the kind you see in your GMK/GMX/EGM.

Other (non-code) assets are easier to license in GPL-compatible ways, and it's easier to work around that.

As Harri pointed out, members of this team have no intention of enforcing the GPL on users who are legitimately distributing games. If one of our contributors is nagging you, you should report that to one of us. Only copyright holders can enforce the terms of the GPL, so if anyone else is nagging you, you may explain or ignore them. That said, it should be sufficient to take us at our word that we will not force you to release your game as a GPL work. However, we are not legally bound by that word unless you get it from each of us in writing for your specific product, which creates potential trust issues. So if you want to play completely safe, the only sure-fire way is to go for the signatures or adhere to the terms of the GPL.

So let's talk about circumventing the GPL, or leveraging it to suit you. Specifically, you mentioned non-code assets.

Since your game as a combined work is covered by GPL, your users are theoretically free to use, modify, and distribute it as they choose. This may sound problematic at first, but it also means that they are free to use proprietary resources with it locally. Theoretically, you can include placeholder art with your game, or include no art at all. You could then distribute those assets separately, under whatever license you please—such as a basic license to use the art with games locally, but not to modify or redistribute it. Thus, while users are allowed to use the art with your game on their machines, they are not allowed to distribute the two as a combined work (they are forbidden from redistributing your assets).

This is one way of preventing legal redistribution of your complete game. However, since there are other copyright holders of the GPL code, those copyright holders are able to demand that you cease to release packages bundled in such a way. This would be exceptionally petty dickery, which you should once again report to the rest of us. This cannot lead to you being forced to GPL-license your art assets, however.


At the end of the day, though, I'd just like to point out that if people don't want to pay for your game, they aren't going to do it. And if they want to reverse-engineer your game, they're going to do it. Yes, source code makes it easier, but it also makes it less of a specialization, which serves to remove the black market from around it as well as the demand for doing so. In my opinion, you'd do just as well to point out that you expect to make $x/copy and that buying a copy is the right thing for users to do. Nothing in the GPL stops you from putting a gentle nag in your game to remind users to support you by purchasing a copy. Honest users will do so, and dishonest users won't, either way. Only a dick would redistribute copies of your game without that nag in them. Just don't overdo it, or it'll become much more reasonable for people to want to do that. ;)

As for other people publishing modifications, it can happen, and as your game grows in popularity, it will happen. If you cease to maintain your game, someone else might make a spinoff that could catch on. The good news is, you can always cherry-pick things they have added to your game—their changes must be GPL as well. The bad news is, if you don't actively do this, or otherwise maintain your code to make it appealing, or do something to maintain presence as the real originator of this game in the eye of the public, then the world will forget about you and move on to other versions. But then, at the point where your game is really that popular, you'll probably have the resources to take your project in all kinds of creative directions, and regardless of your license, ceasing to maintain your game wouldn't allow you to thrive in the current gaming market for very long.


So yeah, you have a lot of options relating to how to distribute and "control" the distribution of your game. But I wouldn't worry about it too much, especially before any serious development or planning begins.

And regarding the bit on modified code, don't worry about that—you're linking against an unmodified ENIGMA. A link to our repository would be more than sufficient.

32
Issues Help Desk / Re: Compilation problems on Linux 32bit
« on: April 10, 2015, 05:37:42 PM »
We don't currently have a list of SuSE package names. Feel free to add one to that Wiki page. Apparently someone rewrote it without an understanding that Ubuntu isn't the only Linux distribution.

33
Announcements / Re: We SSL now
« on: April 09, 2015, 05:31:17 PM »
Seems to be on your end. Just tried it on this machine without issue. Other forum pages will complain because user-posted content (images, mostly) is not secured, but login should work without issue.

34
General ENIGMA / Re: First Impressions Of ENIGMA
« on: April 01, 2015, 10:56:23 PM »
I'll develop again, at some point. I have other interests, at the moment (and an increasing number of them). Though I'll admit, there's something I'm hoping will come along that would rekindle my interest in the project.

35
Announcements / Re: Java Easy Image Editor 0.0.1
« on: March 29, 2015, 09:04:42 AM »
There are migration steps, Ism; if you want to be totally safe, you can manually move the Google Code repo somewhere new on GitHub.

36
General ENIGMA / Re: New To Enigma
« on: March 06, 2015, 09:11:28 PM »
The project isn't as active as it used to be, but yes, it's very much alive. Your options on Linux are a bit limited, but even apart from that, I think ENIGMA is still a viable contender, especially if you want extensibility. Depending on where you're coming from and what you're looking to do, there are certainly better options, but if you just want to take game development for a spin, then ENIGMA is probably a good choice.

37
Issues Help Desk / Re: Crashing Ubuntu 14.10
« on: March 01, 2015, 11:02:34 PM »
Strange. It seems something LGM/OpenJDK is doing is aggravating a compiz bug, which I assume is a big part of how Unity operates, so Unity gives up the ghost and logs you out. I have no idea why running LGM without ENIGMA would solve this problem. I'll see if we can't reproduce this in a VM.

38
Issues Help Desk / Re: Crashing Ubuntu 14.10
« on: February 26, 2015, 11:53:01 PM »
Strange... The window opens as a tab for me, and closing it returns it to the tab pane. This is extra strange, because you are using the exact same OpenJDK build I am. Would you be willing to copy LGM somewhere it won't find ENIGMA, and verify that the problem persists without it? If no C++ code is involved, then this is an OpenJDK bug, and we'll need to file a ticket about it. This sort of thing has cropped up before; last time, using drag and drop at all after displaying a splash screen caused OpenJDK to crash the X window server. This time, your guess is as good as mine what might be causing this crash.

When it crashes, what does your system do? Does it black out, or just become completely unresponsive? Do the LEDs on your keyboard flash? Flashing LEDs indicate kernel panic, which theoretically shouldn't ever happen, and spells certain reboot. Otherwise, did you try switching to TTY1 (control-alt-f1) then back again (alt-f7)? Some minor X hiccups cause me to lose keyboard and/or mouse input until doing that. Can you move the mouse at all? Does anything on the system start consuming tons of memory? (If OpenJRE begins consuming more than 500MB of memory, that's another bug—Java processes are supposed to have limited memory).

Apologies for the 20 Questions. It'll help me to know exactly what's breaking (though it seems at this point that no LGM code can be causing it directly).

39
Issues Help Desk / Re: Crashing Ubuntu 14.10
« on: February 24, 2015, 11:48:04 PM »
3) Close the event selector — The event selector is a tab that can't be closed. How are you closing it? Switching tabs or floating the tab and closing it does nothing for me. I can click "Modify" all day, no problem.

40
Issues Help Desk / Re: Crashing Ubuntu 14.10
« on: February 20, 2015, 11:23:06 PM »
That sounds like a JRE bug. What platform are you on? OpenJRE or Oracle JRE? What Java version?

It's a bit severe a bug to ask you to try to reproduce it, but if you can find consistent steps to do so, that would help. This is the first time I've heard of this issue.

41
Issues Help Desk / Re: Extension .egm does not match EGM?
« on: February 19, 2015, 09:36:04 PM »
Even with that ugly indent scheme, the XML will be on the order of twice as large for a typical room. The only advantage of the XML is that named attributes allow you to elide attributes with default (probably zero or one) values. If this proves necessary, YAML also allows this using maps. So <inst id="1000009" obj="2" x="32" y="432"/> becomes {id: 1000009,obj: 2,x: 32,y: 432}, which is pretty meager savings, but that's still the worst-case, and large rooms will be mostly instances. The ease of parsing of (E)YAML vs XML is also a major feature. And if we're going to go toe-to-toe with full specs, XML will lose outright by YAML's superior support for primitives, node types, and even node references.

Not to mention that the best thing about YAML is that users' code appears verbatim in the format, with the exception that it is indented. I'll grant that it is unlikely for code to contain "</crc>", and unlikely for a given user to want to edit the file manually, and that together this means it's extremely unlikely that a user would want to paste in code with a closing tag, but correctly-formatted code uses HTML entities in place of reserved characters (and there are lots), so in general, a user can't open the room file and copy the code somewhere else, because if (x &lt; xprevious) is not valid EDL.

The comment line we would place in the YAML would be optional; it prevents cases where valid code entered in an IDE would break the format. In the 99 percent case, pasting in a well-formatted piece of code and indenting it twice will suffice, because the first line usually has the least amount of indent. The 99 percent case of the 1 percent case is where someone decided to indent their opening doc comment. They will have to either not do that, or place the opening YAML comment, which we might consider simplifying to, eg, eight or more hyphens.

42
Issues Help Desk / Re: Extension .egm does not match EGM?
« on: February 18, 2015, 10:59:07 PM »
XML is the ugliest imaginable format. It's extensible by nature, yes, but it is extremely verbose. And while its hierarchy makes storing code obvious, the problem is simple enough to work around in YAML. As for XML's propensity for hierarchical data, well, rooms are pretty linear in the scheme of things. I posted a proposal somewhere (or maybe I just started coding it and didn't finish) about what I wanted rooms to look like. Consider something like this:

Code: (YAML) [Select]
name: room_0
background-color
: 00C0FF
backgrounds
:
- name
: bkg_3
  depth
: 1000
  h-repeat
: yes
  v-repeat
: no
- name
: bkg_overlay
  depth
: -1000
  h-repeat
: no
  v-repeat
: no
views
:
- id
: 0 # Optional for in-sequence
  visible
: yes
  viewport
:
    x
: 0
    y
: 0
    w
: 640
    h
: 480
  projection
:
    x
: 0
    y
: 0
    w
: 640
    h
: 480
  follow
:
    object
: obj_player
    border
: [32, 24] # Also allowed: separate lines for h/v
    speed
: [4, 4]
object-format
:
- id
- object-index
- x
- y
- rotation
object-names
:
- obj_player
- obj_dirtwall
- obj_7
objects
: [
  [1000001, 0, 64, 400, 0],
  [1000002, 1, 0, 432, 0],
  [1000003, 1, 32, 432, 0],
  [1000004, 1, 64, 432, 0],
  [1000006, 1, 96, 432, 0],
  [1000007, 1, 128, 432, 0],
  [1000008, 1, 160, 432, 0],
  [1000009, 1, 192 432, 0],
  [1000012, 2, 32, 432, 45] # obj_7 is still index 2 on our list, even if its id is really 7.
]
creation-codes
:
- ind
: 0
  code
: |
   // Code begins here
    can_fly = false;

- ind
: 8
  code
: |
   // Code begins here
    text = "To jump, press [space].";

The "// Code begins here" bit is to prevent issues with code snippets wherein the first line is indented for whatever reason. This is important since YAML is indentation-based. XML deals with this by escaping < and >, which I also disapprove of. Comparatively speaking, the cost of YAML is cheap.

I'll also point out that the verbosity around viewport/projection can theoretically be replaced with viewport: {x: 0, y: 0, w: 640, h: 480}, although e-YAML doesn't presently support that.

43
Announcements / Re: Google Summer of Code
« on: February 18, 2015, 09:08:01 PM »
daz: I have paid literally seventeen cents for my Rackspace Cloud Files so far. Cloud files is not Cloud Servers. They charge by the megabyte, and we're using a couple dozen.

And yes, our GSoC participation is out the window due to lack of proper coordination, and for an overarching reason: more minimum-time contributors is not what we need right now.

44
Announcements / We SSL now
« on: February 11, 2015, 09:09:40 PM »
I recommend using our shiny new SSL connection for signing into the forums from here on out. I will look for a way to enable this by default.

We don't want the default forum browsing to be secured, though, as you will just receive warnings that the content users post (images, avatars, etc) will be from third-party sites.

However, I made some arrangements, and these domains and the certificate are now paid through 2020. The website, however, is not. Right now I have launched an IRC bot, which the host said was okay despite the terms of our VPS lease. I will continue to renew this VPS as long as they allow both of these to run. I will also be, at some point in the next century, setting up a build bot here. If at any point this becomes "too much load" for our VPS, we will be moving to a dedicated server.

Cheers

45
Announcements / Re: Google Summer of Code
« on: February 08, 2015, 08:28:01 AM »
Yes, the IDE is my number one pain point. I know Java; I have to work with it far more often than I like, actually. The issue is that even if I do add the resources and features I want LateralGM, the amount of work required to make it work well with the EGM format seems out of my reach. That's why I've started putting my chips on NaturalGM, which I think might warrant a spot in GSoC, if you pardon its small age. But ENIGMA? Yeah, I might let this one go....

I finished my MEI generator and am moving back to the flags header. A chunk of today will be spent doing my laundry (about three weeks' worth) and going grocery shopping. I might finish Flags today, but I doubt it. I'll probably finish it tomorrow after I get home from work. After that, I have one more pet project that is more interesting to me than ENIGMA, and then I guess I'll try to muddle through this merge once more.

I'll be a little more clear; the parts of ENIGMA that are now interesting to me are the parts of ENIGMA the IDE doesn't support. And I don't want to do Java IDE work. I don't really want to do IDE work at all, actually; Java isn't all that bad for it. But Swing is broken and LGM needs major surgery on its other two tiers for this, so what's the point?

Pages: 1 2 [3] 4 5 ... 186