No announcement yet.

List of Linux friendly Kickstarter projects

  • Filter
  • Time
  • Show
Clear All
new posts

  • ~ Strech goal at $140K but they have only 4 more days and they just got $82K out of the needed $90K ~ Already funded, Linux version from the start





        I don't particularly care about minecraft clones, but perhaps some here do.


        • Build a WORLD FUNDING ENDS 20 April

          Hey guys, we are doing poorly with publicity right now

          so even if you dont pledge, please share the link to our kickstarter EVERYWHERE
          (most of our youtube page views and kickstarter pledges come from denmark, so we are having problem with reaching the world wide audience with a marketing budget of 0$ for the kickstarter)

          Funding ends on 4/20 (Phoronix is american right?)

          Our game is called Build A World, that we have been developing over the past 18 months. We welcome any questions, comments or suggestions on our facebook page (see below), where you can also follow our progress.

          Its aiming for very high quality graphics and sound .

          Build A World is an indie-game, and everybody involved are pitching in with a specific set of skills. We are at the moment seeking alternative finance via the funding platform, in order to speed up the development - including a Linux version of the game. You can follow and/or donate to our project there.

          You can see our game here:

          Our YouTube channel:

          Our Facebook page:


          AND A Little sidenote from me as the lead graphics programmer

          Remember all the rendering tech makes it through the linux build first and then is approved and merged into the general build. So there is a guarantee and the Linux version of Build a World will never be behind on graphics compared to other platforms.

          Minimum System Requirements
          OS: 32bit Linux with Kernel 2.6 or greater, 32bit Windows XP or greater, Mac OSX subject to manpower
          Dual Core 2.1Ghz CPU
          1GB of RAM Linux, 1.5GB of RAM on Windows
          256mb Graphics Card with OpenGL 3.0 capability
          (with exception of Intel HD Graphics from Arrandale generation of core-i CPUs)
          Internet Connection for a few seconds to login
          Constant 56kb/s internet connection for Cloud Servers

          The numbers next to headings correspond to bibliography:

          And also here is a list of all the rendering tech in the game

          Tessendorf GPU-FFT based water (1)

          Using the same technique as Crysis 1 and 2 for simulating the waves on an ocean surface, but accelerated by the GPU (and the displacement map is 4x larger)
          Radix-2 FFT is running in SM 3.0
          Complex Water Shaders
          Water has many settings, micro detail normal maps are used to augment resolution. Water supports dynamic reflections and refraction. There is a choice of adaptive software or hardware tessellation for actual vertex displacement
          Simple DLAA
          To provide Anti-Aliasing despite the Off-Screen Rendering pipeline, we use DLAA as a post process
          HDR seems to be a requirement in modern games, what would be lights without the glow around them??
          Dynamic Resolution Rendering (2)
          Standard approach on consoles, we dynamically scale the viewport so resolution varies in order to ensure smooth gameplay. This comes especially handy in large forest fires when you're walking through the burning forest because how much of the screen is occupied by particles causing a bottleneck in fillrate. The resolution adjustment system makes sure that the resolution is only dropped as much as necessary in order to achieve 24 FPS while moving.
          The GUI is rendered at native resolution at all times
          Occlusion Queries Culling (3)
          The polycount for the entire world while looking out over the ocean can be as high as 5 million.
          This was optimized by a complex hardware occlusion query system which determined which regions of the map are visible, it works so well that the rendered polycount inside houses is around 80 thousand
          It also makes sure reflections are not rendered if no water surface is visible
          Very Large Simulated Fires (3500 simultaneous blocks on fire)
          Our fires spread from flammable block to flammable block (one of the greatest sights is oil floating on water while burning), this enables you to burn down entire forests. Burning blocks emit huge smoke stacks which will soon be collision simulated through sampling or cone tracing mip mapped fluid flow resistance fields (like opacity) to provide realistic interaction with obstacles. 100k+ Particles run in realtime even on the old 8800M Nvidia card with only 196mb of dedicated memory.
          Superfast SSE3 Optimized Particle System -- going to be offloaded to a separate thread with enough HH:MM:SS and $$
          In the beginning the framerate was struggling because the rendering thread had to do weightlifting with animating loads of particles, the performance of the C++ code was improved 3 times over by using SSE3 ASM instructions to enhance FLOPS throughput.
          We use SSE radix sorting to sort the particles when needed (certain types of OIT allow us not to do so)
          This CPU cost will stop affecting the framerate once the particle animation is offloaded to a separate thread.
          Radiant Flux Volumes
          We store the lighting for many possible empty points (light probes in the new lighting system) in space so dynamic objects are lit accordingly to the lights and obstacles in their surroundings.
          Particle Lighting
          This Radiant Flux Volume also makes the smoke pickup the lighting appropriately, sometimes this results in shafts of shadows through the smoke or smoke lit by surrounding lights (the fire itself)
          Soft Particles Forced On At All Times
          Building on the research in the work using the Z-Buffer to feather out the hard Z-fail edges by assuming a volumetric billboard, most of the Z-clipping is not visible. I use a cosine based, (like tukey windowing function) function which has a smooth differential without any violent breaks. It is even enabled for the Intel Cards, because in this completely destructable world there is no way to prevent particles from intersecting geometry like in standard video game productions.
          GPU billboards
          The particle camera-alignment and rotation due to rolling motion are not carried out on the CPU, this makes sorting a lot faster because each particle is represented by 1-vertex with a fat-attribute buffer. The billboards/quads are extruded and transformed in the vertex and geomet
          High Quality animated particles
          The particles are not just images, they are video sequences which are stored in 2D texture arrays. This enabled PERFECT mip mapping (3d texture does not, mip maps blend separate animation frames together) and inter-frame interpolation. The flames are actually dancing, and the smoke is rolling.
          Simple Indirect Lighting
          Søren's intial light engine which enables you to have shadows, indirect light shining into caves and COUNTLESS light blocks. Light blocks have ranges of up to 20 blocks and the light transfer is shadowed. This means that if you build a house and place a light in one room, it does not leak through the wall into the next one.
          Anisotropic Opacity and Fluid Flow Volumes (8)
          Building on the basis of pre-integrated hierarchical opacity, I derived a encoded representation of the world which is dynamically updated. The Fluid Flow volumes are not only used to determine the soft collisions of smoke puffs with geometry, but will also be used for accelerating path-finding, AI, collision detection, free space detection, various optimizations and visibility checking (could be used instead of occlusion queries).
          Order Independent Transparency as Weighted Average
          Because of the availability of alpha-blended glass blocks, aquariums, etc. it seemed very important to explore ways to render transparency which did not require sorting every triangle. Weighted average has its shortcomings in fillrate and brighter objects showing through. This is why we need more developer time to explore two more alleys of OIT. Note: OIT was always limited to tech-demos, never featured in a full fledged game (with exception of depth peeling)
          Joystick/Gamepad Rumble (Linux only right now)
          Since you're running around with a drill, and the game is supposed to be ported to PS4 sometime, I thought it would be useful to provide consistent experience across both. So why shouldnt a PC player enjoy the knowledge of which drill they are using from the magnitude of virbrations in his hands or navigating through the world with something more comfortable than WASD keys.
          Intelligent Renewable Energy Electricity Generation Simulation
          Part of a bigger, AND MORE EPIC power system which is core to the game, there is the physical and graphical response of the game logic to the actual inputs. In no other game did the render output affect the game logic, here if the solar panels are in shadow they do not generate electricity and if there is no free room for the air to move in front of the wind turbine then there must be no wind and therefore no electricity! (should stop cheaters from hiding their fragile wind-farms in caves)

          FUTURE TECH

          Realtime Atmospheric Scattering (7) -- Development Taking Place
          The game has a night-day cycle, and also will feature a realistic skydome with amazing sunsets and sunrises. Furthermore, the output of the skydome synthesis is the main driver behind the new rendering system which will light the world based on the luminosity of the sky.
          Spherical Harmonics Irradiance Transfer for support of insane amounts of lights and global illumination (4,5,6) -- Development Taking Place
          This is the most meaty piece of Next-Gen technology in the game. After months of research and design, a vision for a system has been consolidated which is a hybrid of the approaches towards Global Illumination used by CryEngine 3 and Unreal Engine 4.
          This puts the renderer almost on par with CryEngine 2 and Unreal Engine 4

          CryEngine 3 uses Light Propagation Volumes where a camera frustum volume is subdivided much into more detailed and cascaded subregions which contain light probes which contain the lighting distribution from all directions encoded as Spherical Harmonics.
          We have need for a similar Volume of Light Probes to provide lighting information to any dynamic object which may move through it. The VRAM requirement for significant detail for the actual blocks was prohibitive

          Also we wanted faint possibility of specular indirect lighting, having seen the Cryril Crassin paper "Sparse Voxel Octree Cone Tracing for Realtime Indirect Illumination" and it amazed me.
          Obviously we cannot require the hardware necessary to perform the cone-tracing necessary to calculate lighting for every pixel, every frame. Also OpenGL 4.2 would be required to handle the Sparse Voxel Octree structure

          Hence I designed a new system which would take the best of both worlds, use the GPU for the intial cone tracing but use it for the primary light (rejecting the need for shadowmaps) and to actually use the environment map to provide lighting which matches the atmospheric conditions. It uses the GPU to precompute lightmaps for the intial light, downloads the data to CPU and performs injection and gathering of indirect light for 2 BOUNCES of indirect providing INSANE global illumination. The light distributions are stored as spherical harmonics instead of gaussian lobes.

          A lot of the work is actually complete, cone distributions and SH synthesis, the deriviation of math for Triple Product Integration and Double Projection (so I can have normal mapping, enviornment skylight being multiplied with Ambient Occlusion).
          Main pains is the non-blocking fast transfer of data like the opacity volumes and direct lighting results to CPU for refining with Indirect Lighting and back to GPU. Also the fact that the SH coefficient between vertices in a quad is completely flawed so that one can see the individual triangles, forced me to sidetrack to develop a DYNAMIC LIGHTMAP SPACE ALLOCATOR which adds complexity to the system be requiring me to manage allocated rows in a lightmap and provide the meshes with another set of texture coordinates.
          There are already some test images generated with the new AO and shadowing technique.

          Sparse Voxel Octrees are really turning out to be THE DATA STRUCTURE, so will most probably be used in a ton of different places to reduce memory consumption and improve performance.

          Realtime-Raytraced Shadows for Dynamic Lights (Head lamps, rockets) -- Development Taking Place

          Using the left-over Opacity field and cone tracing functionality, one can trace a cone in order to produce perfectly anti-aliased soft shadows
          Low Frequency Realtime Glass Reflections (reflections true to surroundings)
          We have a spherical harmonic describing the ambient occlusion at every vertex, this is basically the same as having a reflection map at every point. the AO can be used to mask out the skydome reflections.
          Spherical Harmonic Based Radiance Volumes
          A great improvement (and the cause of the VRAM requirement) to the original Radiant Flux Volume which is being used to light our dynamic objects, only this time the AO*Skydome+LocalAndIndirectLighting are encoded as a spherical harmonic which "saves" the directions of lights. This enables very good lighting (insanely good lighting) and the use of Normal Maps.
          Fluid Flow Particle Simulation -- Development Taking Place
          Not ACTUAL Navier-Stokes simulation, but takes into account the resistance to smoke flow through forests and will prevent smoke going out of caves THROUGH their roofs.
          Normal Mapping, Parallax Mapping, Parallax Displacement Mapping and Tessellation Displacement Mapping
          Insanely detailed blocks:
          Geometry through the Parallax and Displacement Effects (containers don't look like plastered on photos, tons of detail)
          Lighting through the Spherical Harmonics (able to use the stored light directions to convolve against the normal map)
          OpenCL and offloading Indirect Lighting
          Uses all the spare computing power you have (no other game or game middleware does this) independent of Hardware manufacturer (i.e. no NVIDIA dependent CUDA implementations) in order to not burden your CPU with the indirect Lighting Pass. The Indirect Lighting will be spread to all other OpenCL and C++ computing devices before the application will resort to using the rendering GPU (if OpenCL capable)
          REAL boost to Nvidia Optimus Laptops
          Phong Tessellation to smooth characters and animal geometry
          We save on polycount and CPU/GPU time spent skinning the animated mesh by reducing vertex count and reconstructing a smoothed high-poly version on the fly in the GPU shader from already crunched animation algorithms... also dependant on the model's size on screen - fully adaptive
          Hybrid Sunlight Shadow techniques (shadowmapping or conetracing)
          I already find myself having to add a large bright spot into the sky to simulate the sun being a lot brighter than ambient light, there is a possibility that this can be factored out and we can have very HQ shadows and spend less memory on the spherical harmonic for omnidirectional-per-vertex and per-probe AO
          Mixed Resolution Particle Rendering (11)
          In order to make the fires run faster (they are magnificent, spectacular and awesome) the fillrate bottleneck needs to be reduced. Rendering the sufficiently close fire particles which take up a lot of the screen at lower resolution could save a lot of fillrate and improve FPS in heavy particle rendering scenarios even by factors of up to 2x
          Order Independent Transparency as Depth Peeling
          The almost perfect solution for machines with extra 40mb of VRAM spare. The blending equation is totally satisfied, objects of varying transparency appear to be in correct order. This method is compatible with ALL GPUs which clear the current minimum requirements to play the game.
          Order Independent Transparency as Linked List Alpha Buffer (OpenGL 4.1)
          The ideal way to render transparent geometry, pixel perfect and close to the ideal solution. Only downside? Compute shaders required!
          Volumetric Light Shafts Godrays (9,10)
          For the extra bling, I want lightshafts as I am walking through the forest. This has been purposely put off until the violent evolution of the particle system, emitters and rendering has stopped, so that once implemented the smoke stacks from burning trees and glass will produce their own shafts.
          Bicubically Interpolated geometry for Waterfalls -- Code Awaiting Resurrection
          We already had nice shaders for waterfalls which had animated water rushing down them, but the generation of the meshes was overlooked (devs are crazy overworked 24/7) and fell down the priority list. In the future they will be smooth meshes (waterfalls will not be blocky) that can have tessellation shaders doing the heavy adaptive work and displacement mapping to break the illusion the waterfall is a smooth marble sculpture, an animated texture so it doesn't look like its just an image scrolling down. Parallax mapping to break the smoothness and make things stick out, normal mapping to light the thing to give it more depth.
          Compute Shader based image Blur
          Blur has always been very slow, because it was implemented as a gather operation. Large blur kernels with lots of samples caused cache trashing in the pixel shader crippling the performance. I would love very large halos around lights like in Crysis 2 Ultra at cost not related to the radius of the blur.
          GPU Skinning
          Using the CPU to move around thousands of points in relation to tens of bones for multiple mobs every frame is a waste. Vertex skinning has proven to be a very cheap solution to such a problem AND allows to store the mesh as a VBO in VRAM resulting in less memory transfer between CPU<->GPU every frame and improves the FPS by a lot.
          Replacement of DLAA with SMAA
          DLAA has not worked as great as expected due to a lot of high frequencies in the textures (very detailed). Also it was one of the first things implemented when we did not know whether using the depth buffer is necessary (due to water rendering and particles we use it anyway). Naturally an Anti-Aliasing approach based solely on color analysis is inferior to one supplemented with the depth information. It would be nice to use an AA method which uses the depth info.
          Better Tone-Mapping Operator
          The equation that we use to adapt the camera exposure is not perfect, there is a lot of research into colorimetry and auto-exposure that needs to be taken advantage of


          • What is the status on Mac and Linux?

            Linux and Mac is something that was planned from the start. This is our engine, so we can do with it what we want. It had build targets for OpenGL (the graphics renderer on Mac and Linux) that actually worked at some point, but along the way we decided to postpone that support and focus on gameplay. We are still going to do this, but probably after the Windows version is finished. All the owners of Divinity: Original Sin, however, will receive these versions for free.




              • First, I never use CAPS, but you really REALLY are screwing up here and I feel the emphasis is essential.

                Marketing lesson #1 GET THE FUCKING LINK RIGHT. I cannot stress this enough. The link to your Kickstarter page is I know you're busy bees making this game but you have two other links that are broken that I'm not going to fix for you.

                Marketing lesson #2 in regards to Kickstarter. Not everyone will like your project, but that doesn't mean they won't support. $25 Euro is the minimum for me to get something?! You don't have a full product yet, I may be interested by the video demo that I cannot play myself (actually not really, this is like Sim City but harder, and I sucked donkey balls at Sim City), however I'de totally chip in $10 if I got a copy. But YOU DONT HAVE A REAL PRODUCT. Don't charge FULL PRICE for something that doesn't exist. Oh, AND YOU ARE TAKING IT AWAY FROM ME AFTER 6 MONTHS. We're going out on a limb to support someone who doesn't have something that really exists, be grateful!! Be VERY grateful! When you take something away from someone after charging them LOTS, that's being an ass. Most Kickstarter games give me a FULL copy for $10 that is mine FOREVER and I can usually download it as many times as I need at no extra cost.

                Even though I wouldn't really play this game, the fact that it looks like something my partner would like and is supported on Linux makes me want to give you money. But I don't know what our life will be like when you release. I don't know if either of us will have time in those 6 months to play at all. I could be spending $25 and get nothing out of it, then have to spend it AGAIN just to see what I funded. When someone does a kickstarter for funding and then gives away the product, you can get away with higher prices a little more (but still probably won't work well).

                #3 After people are GIVING you money, DONATING you your funding, you are MAKING MORE MONEY and NOT GIVING A PENNY back to the original funders. That's real douche behavior. Most kickstarters are supposed to FULLY FUND your project from start finish, INCLUDING SALARIES. You're not really doing that, but that's kinda the purpose of giving someone money before the product exists. On top of that, YOU'RE CHARGING THE BACKERS AGAIN AFTER SIX MONTHS!!!! AFTER THEY WENT OUT ON A LIMB AND GAVE YOU MONEY WELL BEFORE YOU GAVE THEM ANYTHING!!!!!!

                In short, I'm not an idiot and there are other projects that won't try to squeeze me for every penny. Good luck, I sincerely mean that, and I hope you learn some lessons from this. Apologies for the yelling, you're not the only Kickstarter project to do this kind of thing, but it reeks of a lack of understanding on how Kickstarter works. It's also really miser behavior and that gets my goat.

                Originally posted by DevSH View Post
                Hey guys, we are doing poorly with publicity right now

                so even if you dont pledge, please share the link to our kickstarter EVERYWHERE
                (most of our youtube page views and kickstarter pledges come from denmark, so we are having problem with reaching the world wide audience with a marketing budget of 0$ for the kickstarter)

                Funding ends on 4/20 (Phoronix is american right?)

                Our game is called Build A World, that we have been developing over the past 18 months. We welcome any questions, comments or suggestions on our facebook page (see below), where you can also follow our progress.


                • Confirmed: Coming to Linux & Mac!

                  It's about time, but we are extremely happy to announce that Divinity: Original Sin will now definitely be coming to Mac & Linux. We will do everything we can to ensure that the release dates are going to coincide with the Windows PC release, but if that doesn't happen, it will be shortly after.




                    • Originally posted by Licaon View Post
                      Wow, yeah, this looks amazing.


                      • Why are you linking to something that is trending toward 11% of its goal and hence has no chance of making it?


                        • Originally posted by Kristian Joensen View Post
                          Why are you linking to something that is trending toward 11% of its goal and hence has no chance of making it?
                          Then more reasons to link it and advertise it, right? It needs all the help it can get!


                          • Originally posted by Licaon View Post
                            Then more reasons to link it and advertise it, right? It needs all the help it can get!
                            You could say that if it was trending towards say 75% or something. But this is trending towards 11% it has no chance at all to make it. Even if your efforts could increase the trend to 5 fold its current level it would still be a long shot and ofcourse your efforts can't make even a fraction of the difference needed to even get there. All linking to such projects does is disappoint people who actually expect to see more games coming to Linux.

                            Much better to link to Kickstarter projects that will actually make it such as Road Redemption which is trending towards 168% and will actually have its source code and art assets released for modders to play with(presumably without Unity's source code which they can't re-distribute).


                            Sanguine Nights' trend is actually down to 8% now. Which is why we shouldn't waste our time, energy and resources and projects like it.


                            For people wondering were I have my numbers from, they are from Kicktraq. In fact I have the Chrome addon so I don't even need to go to the Kicktraq website to see these things. I never back projects that are looking to fail. For game projects I only back them if they are looking to be successful(or on the cusp of being successful) AND have Linux support AND are going to be DRM-Free AND have interesting concepts and/or by development studios I want to support.
                            Last edited by Kristian Joensen; 04-13-2013, 06:07 AM.


                            • Originally posted by Kristian Joensen View Post
                              Why are you linking to something that is trending toward 11% of its goal and hence has no chance of making it?
                              The better question is why is he linking to a game that has no chance of being released for the amount they are asking?

                              Shadowrun: Returns will be Steam only to non-backers and they made horrible compromises in game mechanics just to be able to afford to send out the physical rewards.

                              Expeditions: Conquistador is now over a month late, but rather than fixing the massive amount of bugs from their beta they are working on multiplayer.

                              Legends of Eisenwald took a loan out from a Russian loan shark, sorry, producer and will be delayed until September.

                              All three of these kickstarters asked for more money than "TeamRavenous" and are now clearly out of money, either due to rank amateurism in not knowing how to budget properly or simply over selling what they could possibly deliver.