New Cube-Related Project: Intensity Engine

by kripken on 11/22/2008 21:36, 23 messages, last message: 12/30/2008 22:14, 6003 views, last view: 05/05/2024 06:17

I've been working on an open source project using Sauerbraten, and I just finished an initial 0.1 release and put up a website, so (following suggestions on the Sauerbraten IRC channel) I thought I'd introduce it to people here on the forums, maybe you'll find it interesting.

The name of the project is the Intensity Engine, and the website is

http://www.intensityengine.com

The website explains what the project is, how to download and run it, etc. Here is a quick overview.

Basically the goal is to create a general-purpose platform for things like virtual worlds and online FPS games, etc. To achieve that goal, I started with Sauerbraten, which I modded quite a lot, then integrated it with Python, SQLite/Storm, and CEGUI/Lua, and wrote a custom API for tying it all together.

One example of why this makes sense is that, if one wanted, they could write a capture-the-flag type game and write the 'game logic' - how long it takes to capture a base, how many points for capturing bases, etc. - in Python, and in a way that most of the client-server complexity is transparent to the developer (no need to write network protocol code!). This allows fast prototyping and lets a lot more people code such things instead of just an elite few ;) My hope is that eventually a lot of people will try a lot of creative ideas that way, and some of them will turn out to be great ideas.

As I said, the project is open source. I'm still deciding about the license, but separately of that, if there are parts of my codebase that people would want in Sauerbraten itself, I'm open to discussing that, my firm belief is that the strength of open source is in sharing (speaking of open source, the 0.1 release runs on both Linux and Windows, in fact Linux is my primary development environment).

   Board Index   

#4: ..

by kripken on 11/23/2008 07:30

geartrooper: Thanks :)

Hirato Kirata: Yeah, I have been told the same by eihrul on IRC, you're right that this is a big flaw.

However, even if it is somewhat slower, it might be worthwhile because of the benefits (more extensible/generic, option for DirectX and other output systems). So I'm not sure yet.

Meanwhile I'm doing an initial test, rendering some cube geometry using Ogre (basically taking the output of Sauerbraten's pipeline and feeding it to Ogre). I don't have performance figures, but it doesn't seem *much* slower. On the other hand, this is more complex than I expected, so I may leave it aside for now because of that.

Code is here if anyone is curious: https://code.launchpad.net/~kripkenstein/intensityengine/ogre

reply to this message

#5: Re: ..

by kripken on 11/23/2008 10:24, refers to #3

JadeMatrix:

I'd like to backport stuff, but actually the Python scripting is not the easiest thing to do - it's very much integrated with the new entity model I use, which is Python-based (and that, in turn, is a large part of my project, many thousands of lines of code).

But maybe we can collaborate on this in some other way than backporting - something to think about.

reply to this message

#6: 0.2 Release + Now Hiring ;)

by kripken on 12/10/2008 19:46

Version 0.2 of the Intensity Engine has been released. You can get it here:

http://www.intensityengine.com/download

Some new screenshots and videos can be seen at

http://www.intensityengine.com/screenshots-and-video

Changes include:
===============
- Procedural generation of scenery, scriptable from Python. Includes
basic smoothing of the raw data
- 'Manage Entities' window in edit mode, lets you see all the entities
by categories (in a tree), and clicking on one focuses you on it
- NPC steering now has core portions in C++ for speed
- Porting to CEGUI 0.6.2, which includes our patches to them, letting us
now use an unpatched CEGUI
- Port eihrul's smooth stair movement patch
- Settings window with sliders for sound volume

Bugfixes:
- New entities aren't placed halfway in the floor (which made lights
not work until moved)
- Login errors appear (disconnect is done after them)
- Removed CEGUI errors and warnings
- Various other small bugs
===============



At this point, the engine is close to feature-complete for the humble goal of creating simple FPS-type games. I am now going to focus on creating a concrete game using the engine.

I'm looking for a 3D modeler and a (C++) coder to work with on creating this game. The general idea is an FPS, but no specifics are yet decided upon - as the actual game logic is done in Python, we can rapidly playtest a lot of ideas :) If you might be interested in collaborating on this, let me know, either here, on IRC (I'm at #sauerbraten, #intensityengine, etc.), or at kripken -at- intensityengine dot com.

reply to this message

#7: ..

by kripken on 12/11/2008 07:26

Oops, it has been pointed out to me by quin that I forgot to say #intensityengine is on FreeNode (unlike #sauerbraten). Sorry for my mistake.

reply to this message

#8: ..

by SSG on 12/14/2008 11:03

Looks like a good engine. Pity about the license though, otherwise I'd consider evaluating it.

reply to this message

#9: Re: ..

by kripken on 12/14/2008 13:52, refers to #8

SSG: The license is probably going to change to a more permissive one. When and to what will depend on what people want.

So, can you please elaborate on why you disapprove of this license, and what license you would be happy with? Thanks.

reply to this message

#10: ..

by SSG on 12/15/2008 12:13

Hi Kripken.

Thanks for being so receptive to feedback. I would prefer something more permissive (perhaps zlib just to keep it simple), however if you prefer to dual license, the other license is reasonably priced and the site states up-front what the deal is, then I would also be open to that. Most people would prefer a free lunch, but a reasonable deal will attract the more serious developers.

Cheers.
- Steve

reply to this message

#11: Re: ..

by kripken on 12/16/2008 15:18, refers to #10

SSG: Thanks for the feedback. Let me ask you another question, what would your position be regarding the LGPL (not GPL) license?

Hopefully I'll be making a decision soon about licensing. But as there are many factors to consider, and this decision is in a sense irrevocable, I'm being careful about it.

reply to this message

#12: Re: ..

by Hirato Kirata on 12/16/2008 23:22, refers to #11

I'd suggest that you do what all the other mod projects did (to my knowledge...), and keep the code under the zlib license, and generally avoid any potential licensing headaches.

in the end it's still your decision, just make the right one (and which one that is, is debatable) :P

reply to this message

#13: ..

by SSG on 12/19/2008 02:35

Hi kripken.

LGPL is quite a good license because in this case it would require changes to the engine to be open sourced while allowing games that merely use the engine to be distributed without the game-specific source. This is especially important for online games to add one more layer of protection against cheating. And of course there are other commercial considerations. Hirato also has a valid point about the other mods. However if you want to make a bit of cash out of this, it's up to you. Dual licensing with the AGPL is certainly a good (strategically) way to go about that. However, you should let everyone know what the deal is up front. When I get some time, i'll evaluate the engine and come up with what i think is a fair price range.

reply to this message

#14: Re: ..

by kripken on 12/19/2008 09:00, refers to #13

SSG: That's a good point regarding preventing cheating. Also I agree that the LGPL license is useful; a good example is that Ogre dual-licenses with it successfully.

Ok, I clarified the licensing better on the website. I added that (1) I'll give unrestricted licenses for free for the time being, (2) the project will always remain open source, and (3) if/when I feel that an unrestricted license is worth paying for, the price would be much less than other stuff in the same field.

Hopefully these will make licensing a non-issue for the time being.

reply to this message

#15: ..

by SSG on 12/22/2008 05:47

Hi kripken. It took me a while to realise that this had actually happened. I'm still uncertain about something though: Will the unrestricted license be valid for future updates? Although you've made a concession, there is still some uncertainty about the future. Perhaps at this point you might want to think about the price of version 1.0 and when you have, tell us, and start selling early adopter licenses at a discount price. Or if you decide otherwise, it would be best to pick a license and use only that. My preference for that would be zlib or LGPL.

reply to this message

#16: Re: ..

by kripken on 12/22/2008 19:01, refers to #15

SSG: To make things simple, I'd be happy to give unrestricted licenses for a very long period of time - over a year, say - that would include all updates during that period.

Years are an eternity in this business, so committing to anything after that is probably meaningless anyhow ;)

But more seriously, this project is basically a fun experiment of mine at this point. It is likely I will never see a cent off of it, and I'm fine with that, so I'm not thinking about possible future pricing right now.

The best speculation I can give you at the moment is to compare it to existing products. For example, Multiverse takes 10% of your revenue. This is considered low in the industry, but I see this as *high*, and IMO it is high mainly because their development model is the outdated closed-source one. So if I were to ever charge anything for an unrestricted license, it would be significantly less than even Multiverse's 10%.

Regarding licensing, I am leaning towards the LGPL. This is waiting on some options I am currently checking out, regarding adding people to my team and/or merging with another project. Hopefully this will get sorted out in the near future.

reply to this message

#17: ..

by SSG2 on 12/24/2008 07:47

I guess your willingness to go down one path or the other depends on how much you want the engine to be used in commercial projects. If you don't care one way or the other, then i apologise for being pushy. However if you're keen to see some commercial products use it, then i hope you can understand my argument about certainty.

I think LGPL strikes the right balance because it requires any distributed enhancements to be made available in source form, yet places a boundary of obligation between the engine and the derived product, recognising that they aren't one and the same.

reply to this message

#18: Re: ..

by kripken on 12/24/2008 17:29, refers to #17

I do want it to be used in commercial projects. And I see your point about certainty, thanks for making that case, it's an important issue.

I hope to clarify this very soon, as I said earlier, I am currently evaluating some options regarding adding people to my team and/or merging with another project. Both scenarios would influence licensing, so I don't want to make a decision beforehand.

reply to this message

#19: ..

by SSG2 on 12/27/2008 04:20

Fair enough. I'll stop talking about it.

By the way, you mentioned using the Ogre renderer. Have you tried Irrlicht lately? Finally a version has been released that doesn't have that annoying performance issue where all the visible vertices are pushed to the GPU every frame. It's a lot easier to use than Ogre as well.

reply to this message

#20: Re: ..

by kripken on 12/27/2008 14:06, refers to #19

I haven't tried Irrlicht recently. My problems with it when I did try it (slightly less than a year ago) were

1. It had less features than Ogre. They are catching up, but then Ogre is also moving forward.
2. Irrlicht had some minor rendering glitches, noticeable even in their demo apps.
3. While Irrlicht is zlib, unlike Ogre the ecosystem around it is non-open source (IrrKlang and IrrEdit, in particular).

I'm curious how much of this is still true, maybe I'll download the recent Irrlicht release and give it a shot.

Do you use Irrlicht? If so, what are your impressions, besides it being easier to use than Ogre?

reply to this message

#21: ..

by jzman2 on 12/29/2008 22:35

Ive used both, and i like ogre much better than Irrlicht.

reply to this message

#22: ..

by SSG2 on 12/30/2008 02:56

My limited experience with both of them is that Irrlicht is easier to use while Ogre has more features and better performance. This latest release of Irrlicht is supposed to close the performance gap by addressing the main performance issues. As for the ecosystem, there's no need to use IrrEdit and IrrKlang. Irrlicht loads many different map formats. You could argue that Ogre is more open source than Irrlicht because it has a stricter licence, but you could also argue that Ogre uses the stricter license to raise money.

My impression of Ogre is that it has more shiny stuff bundled in the demo programs so that it appears it has more features than Irrlicht. I don't know whether Ogre does in fact have more features, but my guess is that it doesn't have as much over Irrlicht as most people think.

reply to this message

#23: ..

by kripken on 12/30/2008 22:14

jzman2: Can you specify the reasons why you find Ogre better?

SSG2: Hmm, come to think of it, the issues of IrrKlang and IrrEdit wouldn't matter for purposes of Sauer anyhow - editing is done using the Sauer system, and sound is already done using SDL. So I think I will have to take a better look at Irrlicht before I spend any more time porting to Ogre, based on your recommendation.

reply to this message

   Board Index