Show HN: Lumix Engine – Open source C++ 3D game engine | Hacker News Reader

Show HN: Lumix Engine – Open source C++ 3D game engine

github.com

260 pointsmikulas_florek117 comments

Maybe I'm just now getting aware of it but I just recently learned of Godot[1] and now this as well. Seems like we have the chance to replace Unity as the "Community" game engine with a free open source version.

[1] https://godotengine.org/

See also http://atomicgameengine.com/ it's quite mature too.

Will add it to my personal list of things to look at. Thanks.

Banshee3D is pretty cool too - https://github.com/BearishSun/BansheeEngine. The vast majority of the work is done by a single person.

There's also Urho3D: https://urho3d.github.io/ "a free lightweight, cross-platform 2D and 3D game engine implemented in C++ and released under the MIT license."

It has an impressive feature list, including: "Cross-platform support using SDL 2.0 (currently runs on Windows, Linux, Mac OS X, Android, iOS, Raspberry Piv1.3 including other generic ARM boardsv1.6, and Webv1.4 with Emscripten toolchain)"

There's also OpenMW https://openmw.org/en/ which, of course, works best for creating Morrowind-like games :) But you can make completely new games with it.

http://polycode.org/ looks like a possible contender too.

A lot of work still needs to go into those engines to achieve feature parity, specially in regards to GUI tooling.

Just check Unreal's 2017 roadmap.

Are you claiming that Unreal still needs a lot of work to achieve parity with Unity?? No.

https://www.youtube.com/watch?v=WC6Xx_jLXmg

Edit: BTW there's a very insightful feature comparison from UE developer here: https://www.reddit.com/r/gamedev/comments/5wouuw/2017_featur...

No, if you read properly you will see I am claiming these community engines have a lot of road to travel and tires to burn, before they can compete with Unity,Unreal,CryEngine and Cocos2D-x features and tooling.

I consider that an advantage, simple things have their appeal. Unity without any 3rd party plugins is very basic, and a lot of these community engines are at the same level.

I was arguing from the point of view of those that think "engine == code" and disregard these engines without everything else that surrounds the eco-system or understanding of how many studios work, which is quite common in the HN Web & FOSS culture.

Good luck with your project.

Yup, back when I was in games our ~70 person team was about 10 developers and the rest were artists/animators/designers.

Tooling cannot be understated and most of our goal was to be a force multiplier on the majority of the team who actually do the creative work. That's what these engines bring and while hobby engines are nifty they're not going to be making strides into that space until they have a compelling tooling story.

It is said that restrictions boost creativity and I've seen artists do amazing things even though their tools were complete crap. Question is how important tools really are. I would argue that vanilla Unity tools are nothing special and yet it's the most used engine in the world and people make amazing games with it.

Oh please, that's the lamest excuse I've seen to skimp on tooling. Abusing your users with poor tools doesn't win you anything.

Self imposed constraints can (and has in many cases) achieved the same thing.

From a technical perspective unity's tools are nothing special, however they work well for non technical users. In the same way UI/UxD for Linux has been a disaster understanding production needs is a complete different space that few engines get right.

It's all just subjective, nothing of this is proven by any research. From my experience from several game studios (I admit the sample is too small to be relevant) quality of their games was inverse to quality of the tools. Stuff like http://www.geek.com/games/a-train-you-ride-in-fallout-3-is-a... is extremely common.

> From a technical perspective unity's tools are nothing special, however they work well for non technical users.

They are nothing special even from non-technical perspective. I'm not saying they are complete crap or that they do not work reasonably, in fact I think they are so successful because they are so simple/average. Of course constantly crashing tool is not boosting your productivity. But simple tools are.

Look at old Unity UI - it was even worse than most open source UI. The new UI is a bit better but still there are open source projects at least equally good. Or animation graphs in Unity. They are quite simple and they have many issues, yet they enable users to do more creative stuff than UE.

With my former career as a creative in games dev, I say that's complete crap. I had access to good and bad tools. With the good tools I could experiment and test ideas quickly. With the bad tools I spent too much time just trying to get stuff to work. I would want tools that boost my creativity by giving me freedom, not boosting creativity to be able to finish my tasks.

Maybe you are thinking boosting creativity to work within the limits of the hardware? That's a different topic.

In my experience, vanilla Unity has better tools for creative out-of-the-box then many engines before it.

Whoever thinks that all these random 3D engines are worth anything to anyone but hobbyist programmers is delusional to say the least. "gui tooling" (or as I like to call it: "the engine") represents maybe 80 to 90% of value of an engine like Unity or Unreal. I'm sure that anyone who's actually done some project in one of these can confirm what I'm saying. The amount of money and time spent on the tools of UE is simply insane.

Tooling is a big chunk but it is not the main benefit of an engine in my opinion. There are so many optimizations and abstractions (think build, platform, gl, LOD handling, skeletal anim, memory handling for things such as landscape) done in your game to make sure it runs super smooth and beautiful at the same time that if you decided to do it yourself you would be working countless of hours to get to the first abstractions.

I think importance of tooling is highly subjective, depends on your habits and workflow. Some people need to have an editor like Unity, others just want to create their whole game in code, e.g. www.randygaul.net/2017/02/24/writing-a-game-engine-in-2017/

I suspect WebAssembly is going to create a niche for very lightweight engines optimized for download footprint, too.

And as you say, UE and Unity seem to be optimized for artist-driven projects rather than coder-driven projects. Which, realistically, are always going to be the majority of commercial efforts, but coders often prefer code. I've written a (basic) 3D object modeller app, and I still can't work out how to use Blender.

> I suspect WebAssembly is going to create a niche for very lightweight engines optimized for download footprint, too.

I wanted to create a simple 2D game once, aiming for lot of platforms, including mobile and web. Most engines (I looked into Unity and Godot) produced just too heavy results for web. I ended up using Haxe/Flixel.

That guy says his must-have feature of c++ is operator/function overloading. That seems an odd choice to me. I have been a c++ developer for over a decade. I would have leaned more towards it being a necessary evil.

Must-have necessary evil :)

Anyway, I do not agree with all the stuff in the linked article. He was just used as an example for need of programmer-focused engines.

It isn't even necessary. Its just convenient, maybe sometimes =)

It's a must-have for 3D programming, for working with vectors and matrices. OpenGL's shader language is basically C with (hard coded) operator overloading for this reason.

Could you explain a little more about how the operator overloading is used in this context? Is it just that arithmetic operators are made to work in their linear algebra sense on objects representing matrices, so M*N will return a new object representing the matrix product M×N?

That's exactly how it would be used. Game programming involves a pretty enormous amount of geometry and vector arithmetic, so it's a domain where being able to write s*(u+v) is an advantage over scaleVec(s, addVec(u, v)). Same logic applies to matrices, as you described.

Personally, I think there are more important advantages of C++ over C, and operator overloading can get ugly FAST if you're not careful.

That makes sense. Thanks for the explanation!

There is a lot of custom 3d game engines used even for commercial projects, I remember reading a survey where it was about 20-30%. Although companies do not opensource them since they see no value in it.

The proprietary, closed, vertically integrated tooling in Unity and Unreal are what make them such terrible tools for use in a professional development environment. All of the best programming tools are free, open source software. Yet somehow we're meant to believe game programming is "special" in some way that it shouldn't use the same ecosystem as every other area of software development. Yeah, right.

Because the values of the game industry are rooted in the demoscene, commercialization of game related IP assets and consulting work related specific hardware and design knowledge, without any religion about freedom of tooling, this is what most FOSS advocates fail to understand about the industry.

My opinion is quite similar to yours. I have never worked in videogames but my, uninformed, opinion has always been that open source videogames lag so much behind other types of open source programs because they require a lot of non-programmers to work. I don't think the complexity of the engines is the main problem, after all operating systems or compilers are also quite complex and critical software. So, what is so special about programming that makes people want to share their work for free? The only other field I think that has a similar collaboration culture would be academic research.

> So, what is so special about programming that makes people want to share their work for free?

I created my engine for myself, I guess a lot of open source projects start with one person solving his problem/having fun. I open source it because:

* money is not everything, it might bring value to some people, but I doubt people would be willing to pay for it * even if it's open source it does not prevent me to earn money with it * I benefit from people using it - submitting patches, reporting problems, testing on different hardware * it can bring money in different ways * if I share my property (e.g. car, flat, computer) with somebody else, it limits my use "rights", if I share software, it limits me in no way

Given that every other industry has moved to FOSS software for their tooling, it's the game industry that has a "religion" about proprietary software being necessary to make money.

I am not sure that game industry has a religion about proprietary software, they use a lot of open source libraries. But you need a lot of tools to make a game - GUI editor, animation graph editor, audio editor, cutscene editor, AI editor ... and it makes harder to create games if all of these editors are from different 3rd party providers with different controls, settings, installers, .... What is more some of these tools need to be taylored to the specific game or integrated too tightly with other editors. E.g. cutscene editor must be tightly integrated with scene editor, or AI editor must be taylored to specific game, since they use extremely different AIs.

What is more thare are not really FOSS tools for game industry. There is GIMP or Blender, but most artists prefer commercial alternatives because they are arguably better. Tiled editor is pretty popular for 2D. But other than there is almost nothing. I would love to avoid implementing an editor/debugger for my behaviour trees, or visual editor for shaders, but there is simply no good FOSS for that.

The claim that "every other industry has moved to FOSS software for their tooling" is demonstrably false.

Has the graphic design industry moved off Photoshop and Illustrator? Has video editing moved off Avid, Premiere, et. al.? Have Windows devs abandoned Visual Studio?

What other industry?

Many of the tools I use daily on our customer projects are proprietary.

I wish it were true but major parts of my time are not using FOSS; iOS app dev & embedded dev notably.

Unity is opening more and more of the engine up.

And as for Unreal...

https://www.unrealengine.com/ue4-on-github

I wish Unity make their code public, they might be publishing a bit of code but most of it is still hidden.

Unity had no GUI tooling until very recently, yet was already very popular.

Indeed, and even the new GUI is very limited. Also other tools are not really great, e.g. animation graphs. But I consider this Unity's way the cause of it's success. To make good tools you have to taylor it to specific use case, making it more complicated and limiting users with different use cases.

I think they're referring to the GUI of the actual tools you're using within the engine, not the ability to create a GUI for your project in the engine.

I mean... just look at the screenshot of the OP. That needs some pretty serious work. :-/

But a game ships with a runtime, not an SDK. If you can build the game's content using proprietary tools, but ship that content backed by a FOSS engine compatible with the output of those tools, I think that gets you 90% of the way to being able to claim that your game itself is FOSS. Sure, people might not be able to alter and "recompile" the art assets from source without proprietary tooling, but they can alter the game mechanics, the scripting, the levels, etc. freely; and also introduce their own assets using whatever tooling they like.

Have you actually used godot? It has "read" 2d mode, that makes it interesting enough - and there are multiple commercial titles built in it.

In general I agree with you - but saying that "you should use Unreal/Unity" on every project is not the right answer in my opinion.

Actually I tried it a few weekend ago, just downloaded and executed a few demos.

It looks nice.

i found unreal very big. slow to compile and change. and a very old source code base. lots of code before C++11 and STL standardization. which is a bit weird with when one is used to code using C++14/11.

I sure hope so. I think one of the barriers may be the compatibility with a lot of the devices coming out in VR. For example, to build something for the Hololens, Unity3D is the only option. IIRC, for Oculus, the only OSS game engine that targets it is Torque3D. I'm not sure how much cooperation these engines need from the manufacturers to begin targeting them, but that can be hard for OSS projects to do.

VR is so minor market at the moment that it's just not worth to support in general engine with limited resources.

That makes sense. Just out of curiosity, to my point above, how much cooperation from the manufacturer of different systems (Hololens/Xbox/Playstation) do you need to be able to target builds for them?

From experience (old gen and next gen consoles) there is 0 cooperation from manufacturer that you really need, other than available SDK and docs. Yes there are bugs in compilers and the consoles themselves (firmware, HW) but you can usually work around them.

Interesting, thanks for the insight.

On the other hand, adoption is usually easier in niche markets.

Indeed, you might have a point. VR seems to be extremely popular amongst developers at the moment, and they are users of game engines.

So... Unreal Engine is already open source and cross platform. I understand they want royalty for revenues > $3000 but that seems ultra reasonable to me considering you get reliable large team to put out release after release.

Does any of the engines mentioned in this thread come close to feature set in Unreal? What's the value here other than creating basic 2D/3D games?

A correction: UE is not open source. It's source is accessible, but does not qualify either as open source, or free software.

Given a sibling comment states that UR is open source (while not free software), could you explain your take on it? Just looking for clarification—not assuming you're mistaken.

https://opensource.org/osd

Correct, open source has a strict definition in the tech community (and OSI), and UE does not meet it.

The OSI has their definition but that doesn't make it the one true definition.

Since they invented the term, I think it pretty much does.

It's nice that "open source" is now so commonplace that people think it's a natural term to use, but if you think about it, it really isn't (something like "source available" would be more normal).

You are right that UE/Unity/Lumberyard? is the way to go for 95% of users, but:

* UE may have it's source code publicly available, but it's definitely not free (as freedom to do anything with it)

* UE is very resource heavy

* You can not use it to create gambling or military stuff

* 2D possible, but not very nice

* Complicated code

None of the open source engines come very close to UE, but you pay the price for it. Even Unity (without any 3rd party plugins) is not close, but I argue Unity is still very useful.

UE4 is only as resource heavy as you want it to be, just as Unity can be resource heavy if you follow certain patterns. Unity and UE4 and many others can achieve quite a bit of parity in performance nowadays. There are scenarios that either one has potential to win out in.

Epic has made great strides in so many areas that if you haven't tried it in a few releases(6ish months?), there is quite a bit of stuff that is better (both in cleanliness/precision but also in performance and overhead)

I just tried to open UE 4.14.2 (no scene) - it took 140seconds, how is that not resource heavy? Opening some basic project - 15 seconds. Making a small change in my plugin and compiling it ~2minutes. Intellisense are quite slow, VisualAssist even slower. Donwloading UE - several GBs.

I can recompile my whole engine in 20 seconds (and I am not using precompiled headers), editor launches in ~1 second, basic scene load ~1 second. Small change in source code - compile & link in 3 seconds. Intellisense brokes from time to time when using FBX SDK, but it's fine otherwise and without FBX SDK there is no problem. Engine size with some necessary data - a few tens of MB.

When I am doing something in my game and I have to change something, turn off engine + make change + compile it + start engine + load the scene = few seconds. It's so fast I did not even bother to implement hotreload for native code.

When I'm working on my UE plugin - the same cycle is several minutes.

the 140 seconds seems like something is wrong or some weird bottleneck is happening especially for a empty scene. I feel like opening a scene for me is about 10 seconds at most.

I thought you were talking about it being resource heavy relative to unity, not to your own home grown one, which is likely (and obviously) much lighter. I have no doubt in that comparison all the larger game engines have quite resource heavy editor. But the tradeoff is supposed to be that few extra seconds loading it up and few GB downloading it, saves you potentially months of work you don't need to do yourself in a more custom engine.

the 2 minute plugin change also seems really off. I can tweak my plugins and recompile in a few seconds.

Intellisense is much better than it used to, at least on my own machine, but I will admit it was finicky for me for a while. Its usually instant for me nowadays, though I will admit at one point it was ridiculously slow(5-10 seconds). I have no idea what I've changed and I am on the same computer.

no getting around UE4 being quite big, several GB, to download.

Unreal Engine is open source but not free software. A perfect example why "open source" is a bad term.

People do sometimes say "open source" to mean "source available", but I think most programmers usually mean something more than that although they don't assume Open Source. It's neither "open source" nor Open Source nor Free Software.

In my experience, what programmers don't see when they start on an engine but which they will harshly run into when they feel it is done is the asset pipeline.

When your game engine is done, how do you get assets into the game? How will your artists test out things, how will you get models you bought on the internet into your game?

For any game engine I'd check out I would first see how well it deals with game assets. It's more important than fancy rendering features or even clean API's and developer tools.

This is very true. Two hardest things which I implemented in Lumix Engine are prefabs and asset import and I'm not still 100% with any of it. But I guess there is not an ideal solution.

UE4 is 'source available' but not Free or Open Source. You certainly can't use a snippet of their code in another project. It is basically the same as the Mathworks giving almost free licences to universities to build mind share, knowing that anything serious requires big cash outlays for licencing.

What the big difference between the OpenGL and D3D renderer? Are they performing and look the same across Windows and Linux? What about MacOS? I guess if it run on Linux I can fiddle with the source and make it run on it?

Look awesome! Always good to have diversity in 3D engine.

Generally Direct3D is for Windows and OpenGL is for all other platforms. Sometimes the OpenGL renderer works on Windows as well for easier testing and development.

Indeed, I only implemented OGL on Windows so I do not have to switch to Linux to implement some rendering feature/new shader. I do that mostly on Windows, because I am the most efficient there, and only test the result on Linux.

When "all other platforms" does not include gaming consoles, as there is this urban myth of OpenGL support on them.

Only partially true on the PS3 (GL ES 1.0 with Cg), which was largely ignored.

The other myth is that graphics drivers from different manufacturers - heck even the same manufacturer - are all created equal because they have standards name on the box :)

Yes, consoles have their own rendering libraries, well for the XBoxOne it's DirectX, but for the PS4 it's a proprietary library (Source: currently working at a AAA studio).

But that is a technicality, because most developers that are making an engine (especially indie or hobby developers) don't have access to development hardware and SDK's.

So it's valid to say that OpenGL runs on all other platforms (that the developer is targeting).

I'm using https://github.com/bkaradzic/bgfx for low-level rendering abstraction. IIRC in the engine there is no difference between opengl and d3d other than a projection matrix. On the outside there can be a difference, e.g. if opengl does not support some operation d3d does (because of drivers). On my computer D3D a tiny bit faster than OGL on windows.

I've not tried Linux for a long time, so it's possible there are some issues. But it's definitely compilable and it used to run few months ago.

MacOS port should be easy, there once was a branch with a lot of stuff already ported, but it was done by other programmer and he did not finish it.

Came across this one too the other day - Xenko http://xenko.com/

Xenko looks very professional, pity it's GPL.

Apparently they allow you to keep your game's source closed. From their FAQ:

> Yes, you can sell your game without any constraints as long as you use the binary version distributed on the website. If you modify and recompile the engine yourself, you can still sell your product, but you have to open the source code of your game and the modifications made to Xenko as stated in the GPL license.

Yes, binary release is not GPL. However the main advantage of open source engines for game developer is their source being opened so you can change it. I wished so many times I have access to Unity source in my dayjob. But in case of Xenko, if you modify it you have to publish the source code of your game - which is a no-go for most game companies.

> I wished so many times I have access to Unity source in my dayjob.

Wouldn't that be trap though in practice? Everytime a new Unity version comes around you would have to patch/test your changes back in.

Yes, it might be a trap. However you could at least:

* submit a patch

* find out that it's specific behaviour causing the bug and avoid it

* now how to optimized your code

* know how things work - Unity's docs misses a lot of details.

That alone makes it impossible to use on sandboxed app stores like iOS, UWP and the consoles.

I'm not so sure. If you're the sole developer, you can offer the binary on iOS and UWP with a standard license, while having the code on GitHub under e.g. BSD license with a note "Game contains code from GameCore licensed under the BSD license". Basically you license the source code under BSD to yourself and you create a derivative that includes all assets that you retain all rights to.

I spoke to a Xenko rep at GDC yesterday. They are having their commercial release "very soon" --which will feature more useful licensing options.

Hey, this looks really good. Thanks for the good work.

A question. Please don't get it wrong.

How you going to maintain that? Recently more than anything I'm more afraid of investing my time in some tool will go away in the near future. While UE and Unity 3D are not perfect, neither free (or even cheap). But those teams have all the money to support next releases, and I have some guarantee that they will exist next year.

Perfectly valid question. You are right, while there is a high chance that UE and Unity will be maintained, there is no guarantee. In any single person project, especially noncommercial, the chance it will not be maintained is much higher and Lumix Engine is not an exception. The only "proof" that it will be maintained is that I already worked on this 4+ years (as you can see on github) and that I'm making a commercial game with the engine.

If someone is not prevented by something (personal preference, license issue, features) there is no reason to use Lumix Engine rather than UE/Unity. UE/Unity should be the right option for 95% of developers.

Thanks for the reply. I will have look and try to test it.

But if you think this is something ready to use in commercial projects, ask for money. I usually feel personally better to if I can pay for things, also paying for things opens a window for to have quality requirements.

It's hard to monetize projects like this, donate button is useless, maybe patreon.

I do not wish to appear overly cynical (and apologies if this does), but what is stopping me investing all my time/effort into this, and finding out the licensing terms have changed such that it becomes more on par with commercial offerings?

Seems like the only benefit would be short lived, whilst I would take on a lot of the disadvantages of not going to a more commercial offering immediately. I'm genuinely interested. I can imagine this putting a lot of people off "committing".

You/I/Anybody can not change the license retrocatively. It means that current source code is MIT and it always will be. I/Anybody might fork the engine under different license or even close source it, but that won't change the fact that current source code is still MIT licensed. Me close-sourcing it is the same as me abandoning it - you can still continue using/developing it under any license you wish.

Appreciate the answer, thanks. I guess that would rule out the people who definitely do not even want the possibility of the prospect of maintaining their own engine. I would be curious to know what kind of percentage we would be talking about...

No engine is guaranteed to be maintained, not even the UE/Unity. Look at CryEngine, once a big, popular engine. Now with all the CryTek's problems, I would not bet it won't get dumped.

Maybe you could help make sure the engine doesn't die on the vine by contributing.

Just so sick of this mentality that single-contributor projects aren't worth spending time on. This is how we get the problem of "open source" send to only happen if it's big companies like Google, Mozilla, or Facebook doing it. It's not like they haven't killed many a project just because it wasn't the gigantic, multi-million dollar success they needed it to be to justify spending their effort.

Indeed, I'm using several open source libraries in the engine and I am not afraid they would die. Because even if they did, I would just continue changing them on my own. I think it's less risky than using e.g. CryEngine, since recently there is a high chance Crytek going bankrupt and there is no way single person can handle something as big and complicated as CryEngine.

What became of ogre3d? http://www.ogre3d.org/

They rewrote it a lot. However Ogre3D is just a rendering framework, not a full game engine.

OGRE is a rendering engine not a game engine. You still have to add networking, physics, sound and other features like that to create a game.

It has been through a long, long overhaul towards the 2.0 version. I guess it's a fine engine, but rendering API have evolved a lot and I don't know if ogre3d is still relevant today... Its founder left some years ago...

There's Urho3D (https://urho3d.github.io) which seems to be mostly a clone of OGRE. I don't know if any of the same people work on it.

Xamarin have a C# wrapper for it, UrhoSharp (https://developer.xamarin.com/guides/cross-platform/urho/). I'm working with it now and I like it a lot better than Unity so far; but I strongly prefer to work in code rather than doing everything in Unity's IDE.

Urho is so much much more than Ogre3D and it's definitely not a clone of Ogre3D. It's full game engine with a lot of features - audio, physics, navigation, ... while Ogre is basically just rendering library. And Urho's rendering is not closer to Ogre than any other rendering solution out there. The only thing they seem to have in common is that people are slowly losing interest in them, which is unfortunate.

Very cool technology, both the engine and studio/editor. Impressive, judging from commit stats it seems to be one person project. Kudos!

What happened to FieldsGame? Sounds interesting, but the link on readme page doesn't have any information except it's a physics sandbox of some sort.

Thanks. It's mostly one person project. There once was another programmer working on it but now it's just me and from time to time some people I do not know.

FieldsGame is made by 3rd party developer, so I do not know in what stage it is. It is possible it's abandoned.

Can it support a large, procedural open world? I tend to think such feature would require its own engine...

I do not think there is an engine which can be used to create game such as No Man's Sky without a lot of custom code. This is open source so it can be used as a base for such game.

Hey guys do you know Armory3d plus Blender integration http://armory3d.org?

I've seen it several times, however it's quite confusing what it really is. From their webpage:

> The goal of Armory is to bring real-time rendering to artists. Everything is fully integrated into Blender, turning it into a complete authoring tool for real-time content.

and

> Everything is bundled to provide the ultimate game development tool.

That's two quite different goals.

Why is are the components limited to 64 distinct types? That sounds low to me.

It's a performance optimizations at the moment, since there is much less types. However I know this is an issue for the future and I have a solution prepared.

Is there still room for another game engine?

I started Lumix Engine years ago for fun and as a test bed for new ideas, which were later implemented in my dayjob. Now I am using it to make a game. I never intended to fill some gap on the market.

What's the game?

http://www.indiedb.com/games/on-the-hunt

What a fine question to ask on HN. Jesus, who cares, this is a one man project and it's amazing what he's done. And to top it off its released under the MIT license. If this doesn't impress you, I don't know what will.

I didn't mean to offend anyone, I just wondered why anyone would build a game engine. He did it for the lulz, which is a fine reason for me.

Reply on news.ycombinator.com