I spend most of my time on my computer playing video games, coding or watching youtube videos about rockets.
As you can see web dev is not my favorite thing, however I did have to make a website for school so if you are interested, here is a link to my github. Here are some of projects I have worked on the course of the past few years:
In september of 2020, I started my most ambitious project so far, to sum it up in a few words, it's a mix between outer wilds and no man's sky.
The idea is to have real size LOD planets that you can walk on and take off from in real time.
This is a very tricky problem i did came up with some solutions but they were to expansive for the computer but now i should be very close from finishing the LOD system.
Here are some screen shots of the planet:
The first screen shot shows my LOD system with the terrain generation turned on it's ugly(for now), but it's fast, once I get the LOD right i'll tune the noise generator to get a more pleasing result.
The second one is the same scene with the terrainGen with the "settings at zero" so we can see the LOD more clearly.
To give an idea of the scale of the scene know that the purple sphere is 40m across,
the planet could be scaled up but I haven't worked on the problem of floating origin yet.
You can see in the above videos the updating of the mesh of the planet.
On the left is the video of the wireframe of the planet updating as the viewPoint(in green) passes by at 450m/s.
On the right is the video of viewPoint looking towards the planet.
Here the planet is 20 km wide.
The planet can now be updated itself in real time correctly.(in the previous "log" the new edges weren't fixed to there adjacents).
Here are the remaining problems:
-there are STILL differences of recusrion between levels quads higher than one
-the system is a bit slow when passing by at high speed an low altitude
-the LOD sometimes crashes for very unknown reasons
Even though these issues could be fixed i don't want to spend anymore time on the quadTree
simply because this project should be about generating the planet rather than taking care of this "complex" structure.
So I have decideed to abandon the quadTree LOD to focus on my own LOD:
during april (when I started this project) i made an LOD that was very slow and very unoptimized let's call it "fluid LOD"(you'll see why).
Instead of creating a quadTree and having to resolve ALL the side problems that comes with it (wich seemed too solve for me at the time),
I made one big grid around the player where the vertices are pulled toward the player depending on their position this way the transition between levels of details is seamless(literally).
When the player moves the entire mesh gets regenerated.
While it did work on bodys the size of an asteroid it wasnt good enough for a planet.
Here are the problems that the LOD was facing:
-LOW frame rate: the way the height of each vertex was calculated was very slow
-the code was TERRIBLE(thankfully, I have become a "better programmer")
-most importantly, when moving the player could see the vertices moving along if the terrain was a little bit to rough.
I am seriously thinking about remaking a similar LOD I am pretty confident that i could make it work in a much shorter time than the quadTree LOD.
A sceond way of generating the planet would be to not make an LOD: I've been thinking about using shaders to render the planet without even using a mesh!
However it has become clear very quickly that my level in maths is WAAYYY to low for this second option.
Meanwhile, I'll remake this LOD of mine and keep you up to date!
suprisingly enough there are 391 views on this page, at the time of writing, so maybe out of those ~400 viewers there is actually someone checking for updates, who knows...
As you can guess, I haven't worked on the project since the last update, but i did work on something very intersting.
After the last log I basically had three choices:
-Make the quadtree faster with multi threading or GPU processing
-remake my "fluid LOD" with GPU processing
-make a terrain impostor by raycastin and evantually raycasting the terrain
I went for the third option unfortunatly it wasn't as straight foward as i expected.
the idea was simple:
-undearstand how simplex noise works and
-make a function that gives the value of the noise along a ray
-get the intersection of the ray and the curve of the function
The biggest problem turned out to be the simplex noise itself, since it uses quintic functions to smooth out its output,
we can't really determine the intersections quickly as the maths behind it involves quite a lot of cos, sins and sqrt.
So I made my "own" simplex noise while taking into account these constraints and I came up with a noise that had the same visual quality, or almost(more on that later).
The function that defined it's height along a ray was a rational one with a cubic on top and a quadratic bellow making the intersection of a ray a simple cubic.
The real probem was that there were some artefacts in the way each vertex of the lattice influecend the noise. Here is a link if you want to help or want to know more.
So I am taking a break from that project, I'm currently making an RTS inspired from one of my favourite games, Starcraft2.
When this is done I'll come back on this project and remake my "fluid LOD" now that i've learned how to write shaders, I'm very confindent that I'll be able to pull it off once and for all.
This is the first day of the project so I don't have a lot of exciting stuff to show.
For now the player can select units like in sc2 and target other entities in the game, depending on the entity units will execute a certain job.
Tommorow I'll finish the worker class so i can show you the first working prototype of a small game where buildings and units are created and destroyed and resources mined.
So see you tomorrow!
Unfortunatly I did not have the time to implement the building mechanic but the mining mechanic does work.
There are resources (in blue) that can be minned only by, you guessed it, the blue agents.
Every resource can be minned only by two agents (like in sc2 for the minerals).
While this is great for game mechanic, it does require to add some lines of codes to make sure that when, lets say 6 workers, are selected,
they mine a different resources even though the player selected only one resource.
When a worker gets to the mineral, he waits for 0.3 seconds and then if the resource has not been minned out while he was waiting,
he takes a fraction of that resource and brings it back to a collector(in yellow).
Here is a little footage.
Btw I haven't added any shader(yet) I just changed settings of the recordings, i thought it looked better this way.
I'm really happy about the resut even though it is a little bit over engineered it works very well.
Now to be honnest, there are some bugs (just two).
One is that sometimes two workers would try to go to the same place and bump into each other without never arriving to their destination.
The other one is somewhat mysterious, when asking the workers to mine, one of them will sometimes go straight to the collector without taking a fragment first idk why.
I've been working on this pretty much all day so I'll keep working tommorow.
-agents not taking into account eah other on the navMesh
-nav mesh not updating when a resource disapears
-creation of building from workers
-creation of units from buildings
See you tommorow!
I could not write code for the game the last few days but meanwhile i did think some solutions to fix what needed to be fixed(new functionalities will have to wait for tomorrow).
The main problem I had, was the agents not working together.
As you can see in the first gif, when asked to get to a location, the agents all try to get on top of it so they would turn around it.
To prevent this, i make the agents that are still going to their destination check if they are close enough to any other agent that has arrived.
(the check is represented by the red line)
If this is the case, they add themself to the "isArrived" list(agents with the green box).
Unfortunately I realised too late that the problem was mainly comming from the fact the stopping distance of the agents was too low.
By making the stopping distance bigger the drunk like behaviour persists, only three or so agents keep spinning instead of all the group, so I'm keeping these checks.
Those checks are made unexpensive by checking the squared distance between two agents instead of checking the actual distance, wich allow us to skeep the sqrt wich is a bit expensive.
The second problem was that, when asked to mine a resource, the agents would all try to go the same location because the resource was outside the nav mesh.
I solved this problem by adding the obstacle component to them instead of having them influence the navMesh.
When an agent wants to mine a resource it will try to get as close as possible to the resource.
Because of the added obstacle component, this is will never happen so to check if the agent is arrived to its destination, i check if it has collided wit the given resource.
This way we are sure that when multiple agents are trying to get to a static entity(building, resource, ...) they will get all around it.(I hope this sentence made sense to you)
Since the static entitys(buidings, resources, ...) won't change the navMesh directly anymore, we don't need to update it every time a resource or building disappears as the obstacle doesn't carve it.
To sum it up, this solution is kind of a two birds one stone thingy.
Now that the agents are acting properly, for tommorow:
-creation of building by units
-creation of units by building
I decided not to add the (previously)desired functionalities.
Instead I decided to refactor the code of the agent class.
Now that I feel like I have the right base for the rest of the developement, lets talk a little bit about the "architecture" of the game.
Every objects(at the exeption of walls) has a entity script attached to them.
This class is the base of every, well, entity in the game.
The entity doesn't do anything on itself but it contains important information about itself such as:
-the remaining health
-the party it belongs to: enum that can either be terrain(just means that other entities can walk on it), player1(is a unit controlled by the first player), player2, neutral(other objects like ressources or watch towers)
-the type: enum, static or unit
-the followers: list of entity whose actions depends on this entity(for example the followers may try to get to this entity)
-a remove Health function calls the die function if the health gets to or bellow zero
-die function calls the reiceveDeathSignal function of every follower and destroys the entity
-reiceveDeathSig: meant to be overried by children classes
This system of followers allows for smart behaviours, for example if unit wants to attack a target and the target dies before it will rest.
The agentclass(attached to every moving unit) is the most complexe one as a unit must be capable of doing a LOT of different things.
(EDIT)Here is how it works:
Since an agent is supposed to perform a lot of different tasks the naïve way of wrinting his update function
would be to do a serie of if elses to determine whar the agent should do.
The problem is that the script would be veeeeery long and hard to read.
The second naïve way of writing the script would be to use a large switch case but that would cause the same problem.
So the idea I came up with is to use the a variable holding a function which in C# is called a delegate.
To do this we first need to declare a type of delegate which in this case is void job().
And then declare the jbo currentJobe.
Now we can simply change current job when needed compressing our source code form an endless serie of if else to just one line: currentJob();
When changing job some variables need to be updated so to start a job I use another function and since we dont even know how many job an agent have,
we declare another delegate void jobStarter(starterKit sk).
(starterKit is a small struct containing the necessary data to start a job: a vector3 and a gameObject).
Since we want the player to be able to queue up orders an agent must have a List of instrucitons
(struct containing a starterKit, a jobStarter and an agent group).
We now need a conditon to check whether or not the agent must execute the next Job.
So, again, we decalre a delegate bool condition() and condition isJobDone;
In the end the Update function looks like this:
And now we have a working agent!
Well, not really we still need to make player able to command his units by a relativly simple interface.
A player can select agents and then rigth click, depending on what he clicks on the the agents must execute different job.
The job depends on the type and party of the targeted unit which gives us eight different cases to deal with.
Again, we could use a serie of if else or switch cases but that we make a total mess.
Instead, I use a 2D array(table) of jobStarter, this way the player simply calls the jobStarter[(int)target.type][(int)taget.party]
The capacity for the player to queue orders up by pressing shift!
-creation of building by units
-creation of units by building
I could not write much these last three days.
Unfortunately, I can't develop the game right now, the computer at my second house is, for some very unknown reasons, not working.
And I had to help my friend on his video game for school.
So I used his computer for a few hours and changed the way entities die in the game, previouslyu they would set themselves inactive
and if another entity had to perform a task depending on their presence it would check if the target was active.
While this made the code pretty simple, this means that, as the party continues the unit count might get too large.
This change highlighted some issues in the code wich to took me a bit of time to fix.
Now when a unit dies it uses the follower system and warns every unit that had an interst in it.
I also added the Amove command in the game.
THis is a very usefull command that tells to the selected units to attack the targeted unit/building
while attacking any other encoutered enemmy unit along the way.
This also forces them to attack allied entities wich is actually more usefull than it may sound.
I don't know when I'll have acccess to a korking computer(the one I'm currently writting on isdoes not have unity installed on it).
It has been almost two weeks since i haven't posted a log so lets sum up what happened since then.
I refactored the code in (almost) its entirety, some scripts were too long and others just didn't work as well as desired(in particular the worker class).
change1: The jobSTarters dont take starterKits anymore(wich are now just called sKit) instead, the starter kit is being handled before the execution of the jobStarter of an instruction(wich have been renamed to directive).
This changed has been made because the jobStarter where all doing the same thing at their begining(updating the destination, updating the target and its followers, ...).
change2: there is now a selectionGroup class wich job is to manage a group of activeEntity.
Here is how it works:
The slectionGroup contains:- a List of activeEntity that receive direct orders, meaning that they react to the right click of the player(agents and produciton buiuldings).
- a Dictionarry that uses activeEntityScriptableObjects as keys and a List of the corresponding activeEntities.(yes you heard that rgiht)
This is used when casting a spell.
change3: But the main reason why i had to refactor the code is because of the very needed feature: spell.
A spell can be casted by any activeEntity and here is the way i found to make them work:
the spell is an abstract class that contains two abstract functions: canBecasted(activeEntity ae, starterKit sk) and getJobStarter(activeEntity ae, starterKit sk).
for the record, starterKit is a small struct containing the necessary data to start a job: a vector3 and a gameObject.
getJobstarter returns, given an activeEntity the corresponding jobStarter
change4: UI, now let me get this straight before I go any further, I HATE WORKING ON UIs.Whether its on html or in Unity it just kills my soul.
I'm kind of ashamed to say that it took me 4 days to make the UI(and its not even finished). The UI is litterallly copied from Starcraft2.
Here is a comparaioson between sc2's UI and mine.
Strangely enough starcraft's UI looks way better than mine... strange.
Next up is the addition of a fog of war system, at first I didn't wanted to add it to the game because it seemed like it would take me a while to make it work.
But the more I thought about it and the less it made sense to not use one in an RTS so I've decided buy one from the asset store.
Hopping to make it work tommorow(haven't bought it yet).
bought the asset just to realise that it's actually an extension of another asset-_- hopping to get a refund.
I've been working on multiplayer functionalities.
Hopping to finsh in two days. Custom fog of war is next.
23/06/21 I've (kind of) finished the multiplayer, but I haven't test it correctly yet.I'll i've to try with a friend.
I've also rewok on the mining mexhaninbc wich is waaaaaaay more complicated to implemant than it may seem.(or I'm just a bad coder).
But I know that i'll have to rework th UI(i fucking hate working on UI, it just kills my soul).
I'm back on the project, I was gone for a month for vacations and did a month of exam to get in the 42 school. Finishing the fog of war.
This is a robot I made during my second year of high school (just for me it wasn't for a class project).
It moves it legs thanks to twelve servomotors
They're Powered by a power Bank so heavy that I had to carry the battery my self(but I still consider this project as a succes).
the robot is controlled by an arduino UNO.
The code of this project wasn't very complicated as the robot is totally unaware of its environement, it just walks straight forward.
Here is how it worked:
The idea was to make a machine capable of melting pasitc and inject it into molds.
Plastic comes in at the top of the tube gets melted by the silvery heaters,
and then forced into a mold by pushing it manually thanks to a metal stick.
The white parts are 3D printed, the box on top contains the electronics to power and control the machine.
Here are some results of this project:
On the picture on the left the grey pieces are molten flecks of milk bottles(which are actually dark grey in the inside)
The green pieces are molten caps of apple sauce
The green stick is the most succeful attempt i had , the quality of the picture isn't very good so you can't see the reflects but,
it is so smooth(smoother than the caps it is made of) that it reflects light.