Messages

1

Programming / Re: Playing around with a new kind of program architecture: "component system"

« on: May 04, 2013, 11:53:23 PM »

Thank you, requerent and Nymphaea, very much! This makes it much clearer. Also the linked thread on sensory systems is quite interesting.
On a different note, I really enjoyed your blog, requerent. Keep it up! And as you seem to like Lua, I'm currently reading Programming in Lua, 3rd Edition and like what I've seen so far (half way through). The best part is that there don't seem to be any WTF?! moments I've come to expect when looking at a new language. Also the book is very well written.

2

Programming / Re: Playing around with a new kind of program architecture: "component system"

« on: May 04, 2013, 01:12:25 AM »

Very interesting topic, thanks for the input so far!
I've been looking into the concept and my main problem is how to deal with systems that have to deal with different kinds of entities.
For example, how to deal with a situation like this. We have a city building game, with buildings and peasant who will automatically react to some situations. Suddenly a building is set on fire. A peasant who currently has nothing to do should immediately try to extinguish the flames.
My first idea would be to make the system that set the building on fire emit an event, which would make an UnemployedPeasantSystem add an ExtinguishFireComponent to some peasant.  According to requerent, this is probably not the best idea, and it would be better to not mix event- and component/entity-based programming.
Another way would be to have some kind of FireBrigadeSystem that handles all BurningComponent entities. This system would then pull all jobless peasants from the entity manager and add an ExtinguishFireComponent to one of them. This seems to be the way that Artemis for Java prefers. Somehow this does not seem right to me, as one system pulls entities it did not originally subscribe to.

More generally, how do we handle updates on entities the current system is not subscribed to? Or, in a more general sense, how do we handle tasks without knowing who might handle them?
Thanks a lot!

3

Programming / Re: game licence (need help)

« on: October 19, 2012, 10:48:27 PM »

I guess by "in game usage/modification" you mean usage in your game? I don't really understand that part, especially the "no credit".

In general Creative Commons licenses are better suited for assets, than the classic "code" licenses. A variety of CC licenses and information are available at http://creativecommons.org. They are well known and familiar to a lot of people, possibly including your artists. If one license does not fit perfectly, it would probably be more advisable to talk to the contributors and see if a compromise can be reached, rather than to make up a new one.

Code:
* yes for using it for other project/game (no credits needed)
* yes for forks/similar games (credit required)
* no for commercial usage

Noncommercial "open source" licenses are rare, at least I don't know any. Such a license would certainly not fit the open source definition. You could use a noncommercial CC license, but a classic open source license would be better suited, if you want people to actually use your code. The "fear" of commercial exploitation of open source projects by other people is mostly unfounded.

Tiles:
* yes for modification/additions for game purposes (credit needed)
* yes for forks (credit needed)
* no for anything else (including commercial)

I don't quite get the "yes for forks"/"no for anything else". Does fork mean a fork of the tiles, or the game? In the long run there could be arguments if a derivative work could still be considered as a fork. "Game purposes" means only for your game?
Otherwise CC BY-NC-SA would fit quite nicely. Reuse/modification is allowed for noncommercial purposes, as long as the resulting work is covered by the same conditions and credit is given.
http://creativecommons.org/licenses/by-nc-sa/3.0/

Graphics:
* yes for in game usage/modification (no credit)
* yes for forks (credit needed)
* yes for private usage
* no for commercial

Same as above, CC BY-NC-SA.
http://creativecommons.org/licenses/by-nc-sa/3.0/

Music:
* only for specified in game purpose (credits included)

CC BY-NC-ND, only allows copying, but no modifications or usage in other games.
http://creativecommons.org/licenses/by-nc-nd/3.0/

4

Programming / Re: Cookie I/O

« on: September 28, 2012, 08:51:17 PM »

@Robobot: Dag nabbit, I think you're right.  Hmm, not sure if it's worth the extra effort, then.

If you want to code in Java and for the web, Leaf's suggestion of GWT sounds like a good approach. I never used it, but heard a lot of good things about it. You might want to use localStorage instead of cookies though.

5

Programming / Re: Cookie I/O

« on: September 27, 2012, 11:40:34 PM »

So I'm in the planning stages of my next project, and I'd like to do it as an applet (I'm a Java programmer).  My reasoning is that it would make updating very easy, and I'd be able to make it accessible to mobile devices while still allowing keyboard input (I'm thinking a button bar on the side; phones are TERRIBLE interfaces for games).

Sorry, but which mobile devices support Java-Applets? I don't' know any.

6

Programming / Re: How to distribute executables with shared libraries?

« on: September 17, 2012, 04:24:55 PM »

Another newbie thing I'm concerned with is 32vs64bit. I have downloaded Brogue and it's binary is ELF 32bit while I'm compiling and using 64bit library. Obviously I can't run Brogue because it says my libSDL is in wrong ELF class...

Most distributions allow you to install the 32bit libraries in addition to the 64bit ones. Your distribution's wiki probably has an article on how to do that.

7

Programming / Re: How to distribute executables with shared libraries?

« on: September 17, 2012, 12:40:58 AM »

That's actually not entirely true. The GPL is a viral license, but the LGPL isn't. That is, if you modify an LGPL'd piece of code, you'll have to release the source under LGPL. If you link to an LGPL'd piece of code, you aren't forced to adhere to the LGPL, and in fact software linking to an LGPL'd piece of code can be closed-source and even commercial.

Okay, I should have pointed that out more clearly. What I meant with "standalone binary" was what UglyTroll was referring to as "one huge binary", aka static linking. If you do that, your code has to be under the (L)GPL.
What you say is of course entirely correct for dynamic linking.

8

Programming / Re: How to distribute executables with shared libraries?

« on: September 16, 2012, 10:45:31 PM »

Just to clarify, if you compile a standalone binary, you still have to adhere to the SDL's license, which is the LGPL. This means your game has to be licensed under the LGPL or GPL. The LD_LIBRARY_PATH solution is much more hassle-free. Also most Linux users will probably be able to install SDL themselves, if they haven't already.

I can't believe I registered to post this, but I'm lurking for quite some time now. Hi, folks!