I'm only going to make a small stub here, the Liero3D project is rebooted and the full story can be found here, I will continue to use the old liero blog for that project, it is to messy to mix random content on random topics in this blog, and to be franc... i don't think people care about the random programming ranting i posted here.
Sorry for messing around, pointing people at different blogs, at the time it seemd like a good idea to orgenize things more and use more blogs. but i will simplify things by sticking mostly to the Liero3D blog.
I will probably only have time for that blog anyway, so if you like to follow my work, that is the blog to check out :)
but now i will go back to work on Lier3D!
Finally got back the spark i was missing for ages :D
lördag 5 februari 2011
lördag 6 november 2010
Works like a charm, more or less :D
Alrighty, this post is just like the previous one, not so much for average Joey, and a bit more for people interesting in programming and the problems we are faced with :)
well, the idea i had about a VBManager seems to work just like i was hoping it would (atleast in small scale tests), i am rather impressed with how clever it is(if i may say so my self) ;-)
I did notice a rather interesting phenomena however.
When i search for new blocks, I always need to find the smallest possible block, or it will split big blocks and create smaller ones witch is harder to recycle.
consider the following example:
|XXXX|FFFFF|XXXX|X|FF|
If the game engine needed to change the 4th chunk, and convert it from a single X block to a XX (size 2), then it would find the first empty one (chunk number 2, with a size 5) and split it into 2 smaller objects, like the following:
|XXXX|XX|FFF|XXXX|F|FF|
This is not good!, because small objects are less useful than big objects most of the time.
we want our engine to cycle the VB data as effective as possible, and the next time need a 5 sized block, it would not find one, instead it would add a new block at the end of the line, and our use of resources has increased:
|XXXX|XX|FFF|XXXX|F|FF|XXXXX
Of course, one other thing changes now, the engine notice there is two small empty block(F and FF) next to each other, and convert them into one FFF block.
|XXXX|XX|FFF|XXXX|FFF|XXXXX
and that is what we end up with when everything is done.
Now lets compare the previus end result with how things could look if the engine prioritized small objekts in searches:
|XXXX|XXXXX|XXXX|F|XX|
This is not a very serious problem, it should be fine to try and find the smallest object possible with correct size and use that one, still... this is one of those things you don't consider when you start planning something :)
However, this is all a rather extreme scenario, but it shows how the technique currently would make bad choices and make it harder for it self to be effective later, but this i will fix soon.
still, i really like this way of handling my VB, and i think it will work out just fine in the end :)
well, the idea i had about a VBManager seems to work just like i was hoping it would (atleast in small scale tests), i am rather impressed with how clever it is(if i may say so my self) ;-)
I did notice a rather interesting phenomena however.
When i search for new blocks, I always need to find the smallest possible block, or it will split big blocks and create smaller ones witch is harder to recycle.
consider the following example:
|XXXX|FFFFF|XXXX|X|FF|
If the game engine needed to change the 4th chunk, and convert it from a single X block to a XX (size 2), then it would find the first empty one (chunk number 2, with a size 5) and split it into 2 smaller objects, like the following:
|XXXX|XX|FFF|XXXX|F|FF|
This is not good!, because small objects are less useful than big objects most of the time.
we want our engine to cycle the VB data as effective as possible, and the next time need a 5 sized block, it would not find one, instead it would add a new block at the end of the line, and our use of resources has increased:
|XXXX|XX|FFF|XXXX|F|FF|XXXXX
Of course, one other thing changes now, the engine notice there is two small empty block(F and FF) next to each other, and convert them into one FFF block.
|XXXX|XX|FFF|XXXX|FFF|XXXXX
and that is what we end up with when everything is done.
Now lets compare the previus end result with how things could look if the engine prioritized small objekts in searches:
|XXXX|XXXXX|XXXX|F|XX|
This is not a very serious problem, it should be fine to try and find the smallest object possible with correct size and use that one, still... this is one of those things you don't consider when you start planning something :)
However, this is all a rather extreme scenario, but it shows how the technique currently would make bad choices and make it harder for it self to be effective later, but this i will fix soon.
still, i really like this way of handling my VB, and i think it will work out just fine in the end :)
fredag 5 november 2010
A few problems, and solutions :)
Okay, so like every other project, there are always a few problems along the way one have to solve, some bigger than others.
One of those is probably the issues surrounding the VertexBuffer(From now on called only VB) and the nature of games like Minecraft(games with destructible world).
The problem is that every chunk in the world can have(and are likley to) have different amount of vertices's in them, and whenever a chunk is changed, the amount of vertices's will increase.
This means that it can be complicated to dedicate areas of the VB for something that can change in size.
So, i had to figure out a way to dynamically request storage in the VB for the size i needed.
And i did had an idea that i think should do it, at a slight performance hit however.
The solution:
I create an VBManager, and it internally stores both the VB, and a list of objects that keep track of every chunk, how much it stores, from where to where.
When my engine decides it don't need a block anymore(moves out of view-range for example) it marks the block as FREE, and can then be used to save other smaller chunks to the VB.
When i need a new chunk of data in my VB, i check every item in my list for an FREE object that is equal or bigger than the size i need to store.
If the block i find is bigger then the one i need to store, I simply subtract the difference into a new block and mark it as FREE, while using the other section to store my data in the VB.
if i didn't find a single object marked as FREE, i simply create a new object in the end of the list in the correct size and store my data.
to Finnish things off, every now and then, i check blocks who are FREE, to find other FREE block's that are next to it, if there are any, i make one big block of all those.
This removes small left-overs and creates more usable blocks.
The problems of this solution:
Well, its not entirely flaw-less i guess, especially in the beginning, it would probably generate allot of blocks before it starts to cycle old blocks as much as i want it to, but i think it should not be a problem after a while.
There is also a performance hit, if we have 200 chunks, we search more than 200 block for every change made in the world.
This however could possibly be solved with some form of Binary search tree, but that is a later problem, for now.. i believe this solution should work(still in the process of writing it).
Not sure how interesting this information is for the average joey, but there you have it :P
[edit] made some changes in the text.
One of those is probably the issues surrounding the VertexBuffer(From now on called only VB) and the nature of games like Minecraft(games with destructible world).
The problem is that every chunk in the world can have(and are likley to) have different amount of vertices's in them, and whenever a chunk is changed, the amount of vertices's will increase.
This means that it can be complicated to dedicate areas of the VB for something that can change in size.
So, i had to figure out a way to dynamically request storage in the VB for the size i needed.
And i did had an idea that i think should do it, at a slight performance hit however.
The solution:
I create an VBManager, and it internally stores both the VB, and a list of objects that keep track of every chunk, how much it stores, from where to where.
When my engine decides it don't need a block anymore(moves out of view-range for example) it marks the block as FREE, and can then be used to save other smaller chunks to the VB.
When i need a new chunk of data in my VB, i check every item in my list for an FREE object that is equal or bigger than the size i need to store.
If the block i find is bigger then the one i need to store, I simply subtract the difference into a new block and mark it as FREE, while using the other section to store my data in the VB.
if i didn't find a single object marked as FREE, i simply create a new object in the end of the list in the correct size and store my data.
to Finnish things off, every now and then, i check blocks who are FREE, to find other FREE block's that are next to it, if there are any, i make one big block of all those.
This removes small left-overs and creates more usable blocks.
The problems of this solution:
Well, its not entirely flaw-less i guess, especially in the beginning, it would probably generate allot of blocks before it starts to cycle old blocks as much as i want it to, but i think it should not be a problem after a while.
There is also a performance hit, if we have 200 chunks, we search more than 200 block for every change made in the world.
This however could possibly be solved with some form of Binary search tree, but that is a later problem, for now.. i believe this solution should work(still in the process of writing it).
Not sure how interesting this information is for the average joey, but there you have it :P
[edit] made some changes in the text.
torsdag 28 oktober 2010
Sweet progress!
I was forced to take a few step back after getting stuck on a few things in proceduall terrain generation(temporary I'm sure), and instead i started working on the other side of the project (Queuing->Threading->Chunks) and as it turns out, it now works very smooth and effective after only a few days work :)
This of course are perhaps one of the most important things to make effective and robust, it is the very heart of the engine, and it feels very solid right now:)
I feel very tempted to implement multi-thread support as well(for computers with more than 2 cores), but i guess it is not where my priority's should be atm, so I'll do that later :)
I must say I'm very happy with the results!, and the threading in C# gave me less problems than i expected(used to things being a bit more messy in Delphi)
I am also considering adding my project to http://www.kickstarter.com/ to get some well needed sponsoring, but it will have to wait until i can make some pretty renders with most of the fancy Shaders active, or nobody will take the project very seriously.
But it would help this project allot of i did manage to collect 25.000+$ or more, i have a serius chicken&the Egg issue with all the licenses, i need to sell the game to get the money i need to pay for the PRO license i need to sell the game.... uhm... hense the problem.
on top of this, i have to struggle to survive on minimal wellfare "income", and at the same time being forced to do part-time tasks to keep my income, making this project loosing valuable time it needs to get finished.
I'm also considering starting my own company, and for that i would get "start your own company money" for 6 months, however... to get those money i need to "sell my idea" to some random "jury" people.
however, to convince those people to get me the money i need... I basically need to have a finished project that can sustain me within 6 months.
so however i turn things around, it seems that a decent chunk of money from Kickstarter would be a life saver.
On a side note, it hit me a while back that i might be able to use the Minertopia engine to power the Liero3D game as well, with only a few miner tweaks.
I also believe that the Minertopia engine Should work on XBox aswell(but i wont promise anything since xbox is famous for giving developers gray hair) and if that is the case, then perhaps my original goal for L3D would be possible as well!
so there are still hope for everyone who wish to see L3D released :)
This of course are perhaps one of the most important things to make effective and robust, it is the very heart of the engine, and it feels very solid right now:)
I feel very tempted to implement multi-thread support as well(for computers with more than 2 cores), but i guess it is not where my priority's should be atm, so I'll do that later :)
I must say I'm very happy with the results!, and the threading in C# gave me less problems than i expected(used to things being a bit more messy in Delphi)
I am also considering adding my project to http://www.kickstarter.com/ to get some well needed sponsoring, but it will have to wait until i can make some pretty renders with most of the fancy Shaders active, or nobody will take the project very seriously.
But it would help this project allot of i did manage to collect 25.000+$ or more, i have a serius chicken&the Egg issue with all the licenses, i need to sell the game to get the money i need to pay for the PRO license i need to sell the game.... uhm... hense the problem.
on top of this, i have to struggle to survive on minimal wellfare "income", and at the same time being forced to do part-time tasks to keep my income, making this project loosing valuable time it needs to get finished.
I'm also considering starting my own company, and for that i would get "start your own company money" for 6 months, however... to get those money i need to "sell my idea" to some random "jury" people.
however, to convince those people to get me the money i need... I basically need to have a finished project that can sustain me within 6 months.
so however i turn things around, it seems that a decent chunk of money from Kickstarter would be a life saver.
On a side note, it hit me a while back that i might be able to use the Minertopia engine to power the Liero3D game as well, with only a few miner tweaks.
I also believe that the Minertopia engine Should work on XBox aswell(but i wont promise anything since xbox is famous for giving developers gray hair) and if that is the case, then perhaps my original goal for L3D would be possible as well!
so there are still hope for everyone who wish to see L3D released :)
torsdag 21 oktober 2010
news about minecraft remake?
Alrighty, time for some news about my latest project :)
Last few days have been very productive, And things have gone allot faster than i first expected. After only about 2 days of coding, i have a few "pretty" chunks rendering a procedually generated terrain(wohoow) :)
I do have some screen-shots but i don't feel that it is worth showing off atm, since I'm not even using textures, and only drawing single-Colored vertices with normals.
But as soon as i have threading working correctly and an infinitive terrain, i will implement textures and real-time shadows... THEN i will have some awesome eye-candy to show :)
In the original Minecraft game, there was only one type of stone, one sand, one wood, grass and so on, this works very well with Notch choice of pixel graphics, BUT this wont look good at all when we are using higher quality textures and a more realistic texture style, you would clearly see where the repetitive patterns are... so i have decided to have 5 different materials for every type of block that can be placed(including Ores).
At this time, it is unsure if i will pick a random texture to use, or Procedurally generate that variation.
The first alternative would mean that the game looks slightly different every time you load your world, it could also mean that you get a different texture pattern if you place a block, instantly remove the same one, and place it again.... now the new block could have different textures.
this don't bother me at all, but it might bother others?
I have yet to deside if its worth the extra CPU spent on Proceduall generation.
Personally it seems more important for me to load chunks as fast as possible so the game can run on as slow machines as possible.
I do have some VERY awesome and(do i dare to say: EPIC features) things i want to implement, that would make the whole world much more dynamic with the things the player can create, and i think i have exactly the thing that will drive people crazy of happiness! :D
but time will tell, im keeping it a secret for now(i would kick my self if i mentioned it here, and some other clone implemented my ideas before i did... stealing many of my future customers)
so, back to the Salt mine ... ha ha *some gentle minecraft comedy*
Last few days have been very productive, And things have gone allot faster than i first expected. After only about 2 days of coding, i have a few "pretty" chunks rendering a procedually generated terrain(wohoow) :)
I do have some screen-shots but i don't feel that it is worth showing off atm, since I'm not even using textures, and only drawing single-Colored vertices with normals.
But as soon as i have threading working correctly and an infinitive terrain, i will implement textures and real-time shadows... THEN i will have some awesome eye-candy to show :)
In the original Minecraft game, there was only one type of stone, one sand, one wood, grass and so on, this works very well with Notch choice of pixel graphics, BUT this wont look good at all when we are using higher quality textures and a more realistic texture style, you would clearly see where the repetitive patterns are... so i have decided to have 5 different materials for every type of block that can be placed(including Ores).
At this time, it is unsure if i will pick a random texture to use, or Procedurally generate that variation.
The first alternative would mean that the game looks slightly different every time you load your world, it could also mean that you get a different texture pattern if you place a block, instantly remove the same one, and place it again.... now the new block could have different textures.
this don't bother me at all, but it might bother others?
I have yet to deside if its worth the extra CPU spent on Proceduall generation.
Personally it seems more important for me to load chunks as fast as possible so the game can run on as slow machines as possible.
I do have some VERY awesome and(do i dare to say: EPIC features) things i want to implement, that would make the whole world much more dynamic with the things the player can create, and i think i have exactly the thing that will drive people crazy of happiness! :D
but time will tell, im keeping it a secret for now(i would kick my self if i mentioned it here, and some other clone implemented my ideas before i did... stealing many of my future customers)
so, back to the Salt mine ... ha ha *some gentle minecraft comedy*
onsdag 6 oktober 2010
Manic digger and what not?
A few days ago i mentioned that i was considering doing a minecraft game, no big surprise there... i have been doing both procedural generated content and 100% destructible game worlds over the last few years, so minecraft is right up my alley.
however, as i already mentioned... i don't want to create something that is exactly the same thing as minecraft, not only would the minecraft community send me death threats and pinky fingers from family members(presumably mine?), but it would not feel right for me... nor would it be very respectful against Notch.
In my previews post i almost made it sound like All i was going to add some texture quality, shaders and some security measures for online building, this of course is not true... i have tons of ideas i would like to have in a sandbox game, the problem is to filter out what fits and what people wants(i do care about the people).
So, about the whole Manic digger issue
I don't really have a problem with the manic digger client as an idea(exect for a few points), in fact... from a pure development aspect, it will be immensely useful for me so i can avoid some of those first time mistakes programmers tend to do on new projects.
but the problems i see with the project are as following:
- The graphics is so look-alike that it almost looks like you copy'd it straight over, but less accurate, this of course will turn minecrafter fans red of furry.
- The fact that it is free, and let you connect to Notch official servers makes it possible to take advantage of Notch hospitality... but not give him any money for it, not nice.
- Some people (not sure how official they are) made statements about how fast the manic digger client is growing and trowing some dirt on notch and his development, this is bad PR the project could do with out.
On the other hand, the minecraft community responded by a total "shit-trowing-duel" and displayed the maturity of a 12yr old youtube flamer, immature... but expected i guess.
The question is, can i avoid the same fate as Manic digger? well i hope so.
So... let me just make this very clear:
we shall all bow to our all mighty god Notch, may his power and divine wisdom shine upon us while we explore his glorious world! amen! ;-)
That said, i don't think i can create anything that can beat his game(but i will of course try), as far as i am concerned it is a master peace! (still don't think its totally original, but that don't make it any less awesome)
I will create a seperate post about some of the features i wanted to add, to make it a little bit more easy to overview and read :)
however, as i already mentioned... i don't want to create something that is exactly the same thing as minecraft, not only would the minecraft community send me death threats and pinky fingers from family members(presumably mine?), but it would not feel right for me... nor would it be very respectful against Notch.
In my previews post i almost made it sound like All i was going to add some texture quality, shaders and some security measures for online building, this of course is not true... i have tons of ideas i would like to have in a sandbox game, the problem is to filter out what fits and what people wants(i do care about the people).
So, about the whole Manic digger issue
I don't really have a problem with the manic digger client as an idea(exect for a few points), in fact... from a pure development aspect, it will be immensely useful for me so i can avoid some of those first time mistakes programmers tend to do on new projects.
but the problems i see with the project are as following:
- The graphics is so look-alike that it almost looks like you copy'd it straight over, but less accurate, this of course will turn minecrafter fans red of furry.
- The fact that it is free, and let you connect to Notch official servers makes it possible to take advantage of Notch hospitality... but not give him any money for it, not nice.
- Some people (not sure how official they are) made statements about how fast the manic digger client is growing and trowing some dirt on notch and his development, this is bad PR the project could do with out.
On the other hand, the minecraft community responded by a total "shit-trowing-duel" and displayed the maturity of a 12yr old youtube flamer, immature... but expected i guess.
The question is, can i avoid the same fate as Manic digger? well i hope so.
So... let me just make this very clear:
we shall all bow to our all mighty god Notch, may his power and divine wisdom shine upon us while we explore his glorious world! amen! ;-)
That said, i don't think i can create anything that can beat his game(but i will of course try), as far as i am concerned it is a master peace! (still don't think its totally original, but that don't make it any less awesome)
I will create a seperate post about some of the features i wanted to add, to make it a little bit more easy to overview and read :)
söndag 3 oktober 2010
Is the world ready for a Minecraft clone?
I have spent a few days playing minecraft, and i must say i really love this game, so i take my hat of for you Markus Persson akka 'Notch' :) *Bows*
Of course, its not totally unique as far as games go(in my opinion), it is more the way it is all put together, and just like Will wright(creator of SimCity,The Sims and Spore) found out years ago: people love user created stuff, and people love to be creative.
And its not only the gamer in me who feel inspired by minecraft, the programmer in me cant help feeling a bit excited about Minecraft as well, and it don't really help that i always have had a soft spot for destructible game worlds and user created content.
So now the questions pops up, is the world ready for a "remake" already?
after watching some of the Minecraft community going crazy and flaming the creator of "Manic Digger" I'm sure allot of people would go nuts on me for making any form of remake as well.
Still, i cant help feeling a strong urge to create something similar to the Minecraft classic online mode, but with some very important differences.
So what would i do different?
well, no doubt that people love the retro style on the graphics, and i don't think it was a mistake to make it like that and not modern, it make the game stand out more and it really do fit the style.
however, if i did a game like minecraft that worked like minecraft and looked like minecraft, it would feel like a total rip off, I want to go my own way, and since i have seen allot of people who wanted Minecraft in HD, i am considering doing exactly that, or at least... making it more "perty".
except for using shaders and nicer looking textures, i would also implement strict building control to ensure all creations are safe.
From what i have seen so far, the biggest problems with Minecraft classic online is "Greifing"( people who destroy what you build and then pretend to be innocent, or if possible blame others who then get banned)
There are however some things that can be done against this, and it would be my highest priority to solve this problem, having an online service with no control of the users using it is a very bad idea for any community.
So how do we solve it then? well here is what i have been thinking :)
i have considered 1 very strict security measure, and one help-full cleanup tool:
#1. Bubble Zone:
The idea is that a player declare a area where he will be building, the bubble is very much like a buffer zone from witch nothing can escape or enter(lava, water and so on), and from start, only the player who created the zone can build in it.
however, the player can manually chose to give a player building access to his bubble.
players are free to visit any bubble unless manually blocked from the owner.
#2. Block tracers (or layers)
I am considering some form of 'block tracing' or "layers" By making the engine/server mark a block with a player id, we can always tell who placed a block in your bubble, and hence, we can simply Undo any changes made from that player.
what a player has created, modified or destroyed, can then later be fixed very much the same way you can toggle layers in Photoshop.
As a nice side effect, no player can ever claim to be innocent, and nobody can ever be accused of being a Greifer wrongfully, admins and OPs will always know.
This later security measure lose allot of its strength from the Bubble zone, the bubble should solve most of the problems, but just in case you manage to screw up(invite someone with ill intension's) it can be a helpful tool to cleanup the mess.
admittedly, the Bubble zone might seem Harsh, and i can understand if people find it to limiting, but i am afraid that it might be a necessary limitation for an online game like this, and it would very much protect you 99% from any possible problem a player can give you.
I do have allot of other ideas i would like to implement, mostly graphical enchantments, but more about that in a later blogg post :)
Of course, there is a chance that Notch will add some form of security measures as well(seems very likely), his game is only in Beta, and if he do solve it like i do it, i guess my version would be more pointless... still, my fingers are itching... will i be able to resist?
time will tell ;)
Of course, its not totally unique as far as games go(in my opinion), it is more the way it is all put together, and just like Will wright(creator of SimCity,The Sims and Spore) found out years ago: people love user created stuff, and people love to be creative.
And its not only the gamer in me who feel inspired by minecraft, the programmer in me cant help feeling a bit excited about Minecraft as well, and it don't really help that i always have had a soft spot for destructible game worlds and user created content.
So now the questions pops up, is the world ready for a "remake" already?
after watching some of the Minecraft community going crazy and flaming the creator of "Manic Digger" I'm sure allot of people would go nuts on me for making any form of remake as well.
Still, i cant help feeling a strong urge to create something similar to the Minecraft classic online mode, but with some very important differences.
So what would i do different?
well, no doubt that people love the retro style on the graphics, and i don't think it was a mistake to make it like that and not modern, it make the game stand out more and it really do fit the style.
however, if i did a game like minecraft that worked like minecraft and looked like minecraft, it would feel like a total rip off, I want to go my own way, and since i have seen allot of people who wanted Minecraft in HD, i am considering doing exactly that, or at least... making it more "perty".
except for using shaders and nicer looking textures, i would also implement strict building control to ensure all creations are safe.
From what i have seen so far, the biggest problems with Minecraft classic online is "Greifing"( people who destroy what you build and then pretend to be innocent, or if possible blame others who then get banned)
There are however some things that can be done against this, and it would be my highest priority to solve this problem, having an online service with no control of the users using it is a very bad idea for any community.
So how do we solve it then? well here is what i have been thinking :)
i have considered 1 very strict security measure, and one help-full cleanup tool:
#1. Bubble Zone:
The idea is that a player declare a area where he will be building, the bubble is very much like a buffer zone from witch nothing can escape or enter(lava, water and so on), and from start, only the player who created the zone can build in it.
however, the player can manually chose to give a player building access to his bubble.
players are free to visit any bubble unless manually blocked from the owner.
#2. Block tracers (or layers)
I am considering some form of 'block tracing' or "layers" By making the engine/server mark a block with a player id, we can always tell who placed a block in your bubble, and hence, we can simply Undo any changes made from that player.
what a player has created, modified or destroyed, can then later be fixed very much the same way you can toggle layers in Photoshop.
As a nice side effect, no player can ever claim to be innocent, and nobody can ever be accused of being a Greifer wrongfully, admins and OPs will always know.
This later security measure lose allot of its strength from the Bubble zone, the bubble should solve most of the problems, but just in case you manage to screw up(invite someone with ill intension's) it can be a helpful tool to cleanup the mess.
admittedly, the Bubble zone might seem Harsh, and i can understand if people find it to limiting, but i am afraid that it might be a necessary limitation for an online game like this, and it would very much protect you 99% from any possible problem a player can give you.
I do have allot of other ideas i would like to implement, mostly graphical enchantments, but more about that in a later blogg post :)
Of course, there is a chance that Notch will add some form of security measures as well(seems very likely), his game is only in Beta, and if he do solve it like i do it, i guess my version would be more pointless... still, my fingers are itching... will i be able to resist?
time will tell ;)
Prenumerera på:
Inlägg (Atom)