ALPHA RELEASED

We hit Alpha!

Right now it's Closed Alpha, but you are free to join our discord and test it yourself!

We also finally have a page for the Game Engine

The game engine is 43.0% complete.

The whole project is 26.3% complete.

Destructible Scenario & Physics 

Setting up the scenario in the engine I'm now able to do this:

That blue square "explodes" the ground every time it touches it, making a crater, the other brown ball just collides with the scenario normally.

I will also make the opposite: creating object and making them interact with the scene at play time.

We are getting close to the first alpha version of the game engine release, I will tell details in the next posts.

The game is 25.1% complete and 95.0% ready for alpha engine release.

Bioscript: The Engine's scripting language.

I'm finishing up the basics of the engine's own scripting language. I believe that it may be complete by the next update. Here is how the syntax looks like

With this language I hope to code the game live within the engine. For that the language is converted to Lua at run-time and to C++ when exporting the game, so it's fair to say that this language is a "scripting" language as fast as C++.

If you are here just to see some cool gifs, I've got you covered. Here is me punching a hole into a solid surface.

Now, this is the same thing but in the middle of it, I make the surface is now hollow inside in a flick of a second:

The game is 24.6% complete and 91.6% ready for Pre-alpha release.

Scripting

I've been busy with a module of the engine called "Class Maker" that allows me to create any entity in the game (like, enemies, camera, NPCs...). I'm creating my own scripting language to help me fully create the game in the engine itself. The reason why I'm creating mu own scripting language is to be flexible and efficient at the same time, as this language will be converted to other languages behind the curtains depending on what is the purpose of its execution call.

Now, not to kill you of boredom here is me creating a 3D House in 3 minutes using my game engine:

I said it before, but I really want this content creation to be part of the game itself :)

The game is 23.6% complete and 88.0% ready for Sandbox Pre-alpha release.

Level Editor Begins

I started working on the level editor, it's been quite massive, since the Engine has to accept any type of entity the developer (me) wants to create in future, that's why scripting will play a big role in here. I just started by adding some base classes for the level editor, and making sure they are properly managed, nothing super sparkly.

So not to leave you without anything interesting, here's a weirdly satisfying screen capture of the editor:

The game is 22.8% complete and 85.0% ready for Sandbox Pre-alpha release.

Planning & Estimation Review 4

It's time for another round of estimations review.

This time decided to change one big thing: Instead of presenting the game engine as a release, I will present the Sandbox (Demo) version of the game. This is because if I take your precious time, I'd like to make the most of it and show how the game will look like instead of how the tech behind the curtains works. The issue was that from my engineering side, 75% of all work is going to the game engine rather than the game itself, that's why I felt like releasing the game engine/editor first. However from a marketing perspective, it doesn't make any sense for me to show deep technical features for gamers prior to presenting the game itself. That doesn't mean I'm not going to publish the game engine, I surely will, that is the main mod tool for the game itself, I'll make sure to make it available for modders.

The estimations are becoming more solid each review, now here are the new estimation dates:

As always, it's important to remember that, these are quite artificial estimations, they were generated by spreadsheet calculations based on how much of my free time I can dedicate to this project. Later down the line, I plan to open it for collective funding and if all goes well, I may be able to dedicate more time to it, as I always wanted and expedite.

As a progress update, I've been working on a Class System Editor, even though very important it's unfortunately nothing visual, so no fun screen capture this time :(

After this Estimation review, the game is 22.1% complete and 82.1% ready for Sandbox Pre-alpha release.

More Design Possibilities

Sorry for taking too long to post this update, I had a lot going on in these last few weeks.

However, I haven't stopped working in this project during my free time.

So I've been adding a lot of functionalities for the 3D Editor.

I'm planning to port all these to the game itself so the player can create anything in game via this procedural editor, this will make content creation much easier and way more fun!

Here is me playing a bit with it in the editor:

The game is 22.1% complete and 84.5% ready for next editor release.

Infinity

A very important aspect of the game is the infinity. Some levels will be infinite, and for that I will need a math concept called Domain repetition:

With that I can repeat any procedural geometry in any way I want.

We are getting close to release the first alpha version of the Editor.

The game is 21.7% complete and 78.9% ready for editor alpha release.

Procedural Art Maker

As I promised, the art of the game will be 100% procedural (with the only exception being part of the characters only).

On these 3 part update I did a procedural geometry editor via coding, which is nice but not very useful as an Art tool.

So, I'm solving that by upgrading that scripting tool to work directly via 3D editing:

Now it's real time, unlike before, you can see how you can combine in lots of ways several 3D shapes into one.

In that GIF, I combine that ellipsoid with the rest of the surface smoothly creating a pleasant curvy look. There's also a"stairs-combiner" that literally create stairs in between the Ellipsoid and the other shapes.

For that I used a math concept called Signed Distance Fields. I can dive more in details about it in the next updates if you want :)

Keep in mind that this maker is not ready yet, there's more features to come. Now imagine the possibilities! And just you wait once I get into domain repetition.

(I said domain repetition, not domain expansion, but it's going to be as cool as domain expansion, I promise)

The game is 21.4% complete and 74.5% ready for editor alpha release.

I see you're making it cheaper in itch.io due to steam's 30% cut, are you making any profit out of that difference?

Because if I calculated correctly, you're either not making more in itch.io or maybe itch's share is lower than 10% on you?

(I ask because I plan to follow a similar path)

Material Editor

I'm back developing the game engine, this time I completed the first iteration of the Material Editor:

Sorry for the choppy animations, all due to the size limitation in here.

Right now you can customize color, roughness, metalness and sub-surface translucency, I'll add more options in the next iterations.

Now for the next weeks I'll be back on the 3rd and hopefully last iteration of the engine's 3D procedural geometry generation.

The game is 21.0% complete and 72.6% ready for editor alpha release.

yeah, "adult" tag should only be visible if you're logged without restriction, or at least age there should be login request before results show up.

Enforcing  to avoid explicit content in thumbnails is also a solution, but that may trigger a rage storm from nsfw devs

I talked to them over discord, they're aware of this issue, it seems this is a non-trivial problem, the way search-by-tags work is not the same as just a regular search (in which is age protected).  Hopefully this gets fixed soon.

New Physics System & Estimations/Dates

Wow, this was quite a big refactor in the game engine, we now have a brand new physics system. Faster, better and all kinds of shapes are now supported.

Gameplay mechanics are not fully upgraded yet, I'll leave this part for after Biomancer (game engine/editor) release.

I'll be back to Biomancer itself to start the level editor next!

Now...

ESTIMATIONS!

To be a bit different this time, I'll disclose some information about the release dates according to my planning calculations.

There are 10 releases planned for our roadmap.

• 2 first releases are the Game Engine release.
• 2 next releases are a sandbox version of the game, with almost all gameplay mechanics available
• 6 last releases are all related to the game itself.

I'm still considering if I'll release as 3 different projects or not.

Here is the estimation breakdown:

This are quite artificial estimations, they were generated by spreadsheet calculations based on how much of my free time I can dedicate to this project. Later down the line, after the first release, I plan to open it for collective funding and if all goes well, I may be able to dedicate more time to it, as I always wanted and expedite.

The game is 20.6% complete and 70.0% ready for editor alpha release.

tu computadora es demasiado débil para el juego, considere actualizar sus controladores de todos modos

I plan to do something similar to that in my game I'm still developing, I'll post it here once I have something concrete (I hope I don't need to necro this post :D because it may take years)

Yes there will be something like "settlement editing", and the way you create it is still open, but nothing is off the table, so yes it may be like minecraft but smooth.

Interesting, didn't know the compiler converts to C++, yes, then if you just switch away from GCC (to clang or msvc) it may be as fast as C++ itself (depending on how good this converter is, ofc)

About the video from dave's garage, it's okay-ish, but not enough, I use this site as a good reference, they are old timers, and have a lot of benchmarks from mandelbrot to reverse complement. As you can see: C, C++ and Rust are the fastest on an average of all their cases (note that unfortunately they don't use a LLVM for C and C++ which could make them even faster).

For games I do recommend C++, it's not only blazing fast but also the best in terms of content and tools produced for game development, but to be honest you can make a very good and efficient game on any language.

Java. for instance, I have a history with it and oh boy it's a painfully annoying language, specially for game dev, but still it was minecraft's first development language, it all comes to how you make it, as long as you leave the heavy lifting to the GPU you can even make hardcore games in python (that may be too much lol, Lua maybe?) 

So yes, if you're comfortable with QB64, go ahead I and finish it up in there, I know it will be just fine

Nice to see you're sticking with your project until the end, you really understand the importance of finishing something you started! Props to you!

I just noticed your attempt to benchmark QB64, and I couldn't hold myself from giving you my two cents on that matter as I worked on developing benchmarking applications for embedded devices for 4 years of my life.

Your loop only has a print command in it, which basically has the same implementation on almost every language, it's a OS interruption basically (interop), so you're not actually measuring the performance of your language but rather measuring the OS interop to print a value. The interop sometimes hold the application until it has completely executed your task, in this case printing a value, so that's why it takes minutes to finish your test.

The simplest but accurate language benchmark I can think of is maybe a MD5 solver for a very long string, or something similar, anything simpler will most likely diverge from the actual purpose of the benchmarking.

Now there's a good overall simple rule to know if a language is fast or slow: How is it converted into machine instructions?

The fastest languages out there are the LLVM compiled languages, like: C, C++, Fortran, Rust and Zig

The slowest are the interpreted languages, like: Ruby on Rails, Python and JavaScript

There are also some languages that are not exactly interpreted, but something like compiled to a intermediate stage just to be translated into machine code, they are like the "half way" between compiled and interpreted languages, like: C#, java and Lua. That's why, although very slow comparing with languages like C++ and Rust, they are still quite fast (mostly what slow them down is a system called garbage collection).

As for QB64(I never used it) but it seems like they can be either compiled (not LLVM though) or interpreted too, so yes it can be very fast, just one step behind languages C++, Rust and Zig.

Going Through a very long Tunnel

Our development train is now going through a vastly long tunnel: Refactoring the physics system.

The current physics system is old and rudimentary, it does not even support relatively basic stuff like rotational mechanics, custom mesh collision and ragdoll physics.

So we are remaking the physics module, I may use PhysX or some full physics sdk otherwise I'd take forever to remake it.

This was part of the roadmap as my current physics engine is over 10 years old, so the time has come to replace it. 

I'm basically working on transplanting this module, so nothing is building correctly right now, hopefully next update we are out of the tunnel so I'll have some cool screen captures to share.

The game is 20.3% complete and 67.7% ready for editor alpha release.

I'd also add that if you're a developer do not download games with your developer account, that's their jackpot, after all the best way for them to disguise their scams is when they steal a legit account.

Thanks! Although it was back in 2013 before the indie game boom, it was not that hard to catch youtube's attention as a indie game dev, the funny part is that I made that game to play locally with my friends taking rounds, it endded up famous in youtube thanks to my girlfriend (now my wife) idea's to publish it.

I put this in my itch page to explain why:

• Although I haven't posted most of my old games in here because they are... well... old!? They need to be updated to be minimally acceptable to my today's standard (the only exception is Cycloid, it's silly old and I really love that stupid game - I had to test publishing a game in here too, right?)

To be more specific, they are all over 10 years old, I would like to update them before reposting, but you can still download one of my ancient games in here, it sucks though, it's 16 years old and I was totally green when I made it, just published this one because I have no plans in updating it.

There's also "Missing", my stupid horror game that went viral back in 2013:

 Unfortunatelly it's currently down, I plan to remake it before re-publishing it.

I wish I had more time to show some love for these games, but my free time is fully allocated to Project Shine at the moment.

Sorry not giving you a more satisfying answer :(

1 Year of Shine

Project Shine is now officially 1 year old, at least publicly (I've been working on it a bit longer than that, and the engine work itself started even earlier).

A lot has been done this last year, we had basically a humble game engine as an API and now we have:

• A working Editor (Biomancer)
• A tool for creating procedural textures
• A tool for creating 3D procedural geometries
• The system the handles infinite procedural levels
• A really fast population rendering system
• 3D Skinning with independent partial and full animations
  
• A basic physics system
• A Procedural Character Editor
• Some Character art I adventured myself in blender

I hope to release the first public version of Biomancer at 2024-08-15 according to my current estimator.

After that we will have another public release of it (Beta) and then we will start the Game as a sandbox, to finally progress to its actual official releases.

It will take years until it's finally fully released, but I already paid Steam for a game submission -_- (how stupid I am to do it this soon, I couldn't hold myself).

This is the 10th game I'm making, all the previous games were successfully finished, and this one is the biggest project by far, that's why I'm taking estimations really seriously here, after all this is the first AAA-like indie game I've ever done.

In this next year, you can expect the Level editor to take off, as well shaders/material editor and enemy maker.

We are at 19.9% complete, so I'll round it up to 20% just for the one year party! ୧༼ಠ益ಠ༽୨

The game is 20.0% complete and 65.5% ready for editor alpha release.

Procedural Geometry Making (pt 3 of 3)

Today I finished the engine's procedural model maker and, my friend, this is huge. I wish I the had time to do some procedural art to demonstrate the sheer size of this feature (this will come once I switch to developing the game rather than the engine).

For now I can only show you the basics, this is a semi-torus, or half of a donut:

And this is a box with very soft edges:

And lastly, this are some stairs generated from a extrusion operation from a 2D stair:

Remember these are all generated with math.

Now with the engine latest functionalities, I do all sorts of combinations, like unifying all of these 3 into a single object:

How about combine the donut with the stairs but remove the box from it after:

What about unifying the box and the stairs and removing the donut instead:

Too rough? How if I "smoothly" subtract the donut:

I can also change how I generate a 3D surface, remember the stairs were generated via extrusion, this is how it looks if instead I generated it by a 3D revolution along the Y-axis:

And finally I can also apply some distortion to any 3D shape. This is me twisting the soft box a bit before unifying it with the stairs and removing that donut from the center of it, leaving a hole:

I plan to support this feature in the game itself for settlement and building creation.

This was a big one, we are getting close to a year of active non-stop development of this project, next update we will be celebrating it :)

The game is 19.4% complete and 64.0% ready for editor alpha release.

Taxes are on the money you make, if you make no money you pay no taxes.

Procedural Geometry Making (pt 2 of 3)

Biomancer (the procedural game engine I'm creating with and for this game) now can create 100% procedural surfaces via its own scripting language, I called it Biocl

The language resembles a mixture of C#, C++ and GLSL, it runs on top the Lua interpreter in the editor and gets converted to C++ automatically when exported to the game.

The purpose of this is to add static 3D procedural assets a props to the game,  keeping my promise of bringing 100% procedural environment to the game.

On the next and last stage I hope to add Marching Cubes to the table to add way more possibilities of procedural surfaces.

The game is 18.8% complete and 60.0% ready for editor alpha release.

https://jsfiddle.net/

in there you can code games directly in html + javascript without downloading anything and is for free

Having performance issues with just 400k triangles in mobile signals something is not correct, mobile can do a few million vertices smoothly if done right.

The biggest issue on a mobile's GPU is memory bandwidth, which can explain your issue depending on how you are rendering those 400k triangles.

Batching (combining those 100 objects into one) won't solve the problem here, as GPU still has to go through all those vertices because it doesn't know they are just a copy of the 1 of 100.

What you want is to tell the GPU that you have 100 copies of the same vertex buffer, that's called Geometry Instancing (or just instancing), and it's largely supported by mobile devices nowadays. Keep in mind that for this you will need its own shader, I recommend also you calculate your object position on the fly, as sending 100 matrices to the shader in mobile may not be as fast as simply procedurally positioning them yourself.

error can be quite a lot of things son, contact the developer.

Not a good idea, but here's a few things to try: 

• 1x1 pixel large image.
• png with only fully transparent pixels.
• Fill your image with colors that matches the background.
• Combine all previous into one.

Usually sites don't want you to have an invisible avatar, so the always do counter measurements, they may have a minimum image size and simply ignore transparency from your image. 

Which leaves us with the last option only, that is not useful either, because the website has themes (I use dark theme for instance) depending on your theme your avatar may be invisible to some people but not others, so it may become just a blank square in the end, not very interesting.

Yes, I can model (not professionaly, I'm a programmer), it depends on the size and level of complexity of the model it can range from 20 minutes to weeks.

Same goes to pixel art, it's not more or less complicated, it's just different, and also modeling is just one of the 3D art areas, there's sculpting, texture art, rigging, skinning, environment, lightmaps....

3D adds a lot more complexity to development and lot more ways to brake the game adding more time and resource into testing basic features.

Also 3D assets are way more scarce than 2D.

Now that said, it's not hard to make a 3D game with the current big engines out there.

Procedural Geometry Making (pt 1 of 3)

I've been working on Biomancer's Procedural Geometry Making tool. This allows you to create procedural 3D surfaces visually.

The objective here is to author 3D content that can be customized and randomized by the gameplay, it's like a simplified version of blender but for programmers and what you create can be changed during the game, like making a table with different amount of legs or different shapes or amount of edges, you can do it for the player to make his own table or for it to be randomized to make variations of it.

This is the first of 3 iterations, in the next one I will show how to make parametric surface via code. See you soon :)

The game is 18.0% complete and 57.0% ready for editor alpha release.

That's literally the idea.

I'd go further and create a camera object (even if you are in 2D) so you can track the position of your viewport. So anything you render should be positioned by it's local position + the opposite of your camera position. 

For instance, let's say you have an enemy sitting on position X = 2000, Y = 0. If you're in 1080p resolution, that enemy is offscreen if your camera is at position 0,0. Once you move your camera more than 80 pixels forward (let's say 81 on X), that enemy starts to become visible on the right side of your screen, because it's position is: EnemyPosition - CameraPosition, 2000 - 81 = 1919, so you see the enemy's first pixel.

The reason why you should create your own camera even in 2D (if your engine does not already provide one) is scalability. Maybe you want to scroll on both axis at some point? Or maybe you want to scroll to a certain part of your map and then go back to the player location just for a cutscene? For all that you will be thankful to have a dedicated module like the 2D Camera.

hum... unfortunatelly, that does not seem to work, it shows results for as if you put "Train?exclude[]=tg.horror" in the search box.

SE design is usually 50% mixing and 50% authoring. This means they literally do their own sound in a studio (they have equipament for that) or they record on the public (if that's the objective). There are exceptions like procedurally generated sounds, but there's only so much you can do in that front, unless your game is based on sine, square or saw waves.... 

Take a look on how some professional games SEs are done, in some classic fighting games they do things like hit a table with a spoon, lower the pitch, add reverb, distort a bit and you have a "punch" sound.

Do you mean sound effects or music? I use audacity for mixing CC0 sound effects I find online, and it's enough for me, now for music that's a whole different story

Haven't been into Game Maker for years, but I know their language and C# as well and my 2 cents are:

GML is a very easy, flexible and simple to use scripting language but it's not scalable , even if you go C# if the core engine can't handle advanced stuffs such as bindings and reflection, then it's like six of one, half a dozen of the other, no gain.

Unity is much more mature on C# than Game Maker and yet they don't support everything, so if you want to go that route I at least recommend you switch to Unity.

C and Python are not game engines, they are programming languages.

I recommend you use Game Maker (that's the actual name of the tool) if you have little to barely any programming knowledge. I started with that and RPG Maker 20 years ago when I was a kid trying to get into game dev.