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 :)
lördag 6 november 2010
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 ;)
lördag 29 maj 2010
ahhh good times
I was browsing a folder on my hard-drive, checking out some of those old things i have been working on over the years, and i thought to my self... what the hell, why not make a blog post about it here :)
after all, some of those projects was very cool :)
oooh Tetravus! my old friend.... one of the very first game concept i ever invented (with a friend named Toivo), The original game was created when we was about 13 or 14 years old(thats 16-17 years ago!), in QBasic!
I belive the graphics was 256colors and hand "pixeld"/hard-coded in Data blocks ... I still cant believe we draw graphics like that, and did it GOOD!, compared to how we work today... it seems insane!
Anyway... the picture above was an attempt at an remake 5 years ago, it was never as fun as the original QBasic version and i am yet to make a worthy one...
For many years, this was considered my main flag-ship project! it was written in Delphi and had some great potential to be huge!
BloodHound was an Torrent search engine client with a DirectConnect interface, powerful multi-threading and an open Pascal-script language to support several big torrent sites like Piratebay and mininova among others.
You could make multiple searches at the same time, in different windows and even have the .Torrent file downloaded and started automatically with your favorite torrent client.
The only reason this project failed was the fact that i constantly had to update the scripts used to parse other homepages(piratebay for example), and some of those sites constantly changed the page code, witch of course broke my software... the constant maintenance was a pain in the ....
so i had to give it up after years of working on different solutions and versions, many of my friends had completely moved over to use BloodHound for all torrent searches, and I'm sure that if i had released it to the public, and solved the issues, it would have been BIG.
also, naming the software bloodhound, same name used by a famous virus, might not be my best move ever ;)
Aahhh... An old favorite game of mine, no other than Boulder Dash on C64, one of my very first games i ever played, No wonder i had to make a remake of it... unfortunately i cant release the game due to copyright issues :(
still, it was a fun project, and it even had a nice and simple little level editor.
Ooooh another old time favorite game of mine, Hexxagon! back in the days of 386 and 486! i remember thinking "when i get a computer, all i need is Worms1 and Hexxagon!" ... hehe those where simpler times ;)
of course, I got the urge to make a hexxagon game my self, and it was designed in XNA so that i could release it for ZuneHD, witch i was planning to buy at the time... things didn't turn out as expected and i got an IPod instead, and the Hexxagon zune project got terminated, still... those bricks had an awesome hand pixel'd rotation animation.
Another project i worked on for a while was my CrayonPhysics remake(even tho it was more of a painting software with physics), and it did look very sweet... however, some very annoying bugs was plaguing the project from the start, and in the end forced me to terminate it.
There are plenty of other projects i have been working on over the years, but these are a few that comes to mind :)
after all, some of those projects was very cool :)
oooh Tetravus! my old friend.... one of the very first game concept i ever invented (with a friend named Toivo), The original game was created when we was about 13 or 14 years old(thats 16-17 years ago!), in QBasic!I belive the graphics was 256colors and hand "pixeld"/hard-coded in Data blocks ... I still cant believe we draw graphics like that, and did it GOOD!, compared to how we work today... it seems insane!
Anyway... the picture above was an attempt at an remake 5 years ago, it was never as fun as the original QBasic version and i am yet to make a worthy one...
For many years, this was considered my main flag-ship project! it was written in Delphi and had some great potential to be huge!
BloodHound was an Torrent search engine client with a DirectConnect interface, powerful multi-threading and an open Pascal-script language to support several big torrent sites like Piratebay and mininova among others.
You could make multiple searches at the same time, in different windows and even have the .Torrent file downloaded and started automatically with your favorite torrent client.
The only reason this project failed was the fact that i constantly had to update the scripts used to parse other homepages(piratebay for example), and some of those sites constantly changed the page code, witch of course broke my software... the constant maintenance was a pain in the ....
so i had to give it up after years of working on different solutions and versions, many of my friends had completely moved over to use BloodHound for all torrent searches, and I'm sure that if i had released it to the public, and solved the issues, it would have been BIG.
also, naming the software bloodhound, same name used by a famous virus, might not be my best move ever ;)
Aahhh... An old favorite game of mine, no other than Boulder Dash on C64, one of my very first games i ever played, No wonder i had to make a remake of it... unfortunately i cant release the game due to copyright issues :(still, it was a fun project, and it even had a nice and simple little level editor.
Ooooh another old time favorite game of mine, Hexxagon! back in the days of 386 and 486! i remember thinking "when i get a computer, all i need is Worms1 and Hexxagon!" ... hehe those where simpler times ;)
of course, I got the urge to make a hexxagon game my self, and it was designed in XNA so that i could release it for ZuneHD, witch i was planning to buy at the time... things didn't turn out as expected and i got an IPod instead, and the Hexxagon zune project got terminated, still... those bricks had an awesome hand pixel'd rotation animation.
Another project i worked on for a while was my CrayonPhysics remake(even tho it was more of a painting software with physics), and it did look very sweet... however, some very annoying bugs was plaguing the project from the start, and in the end forced me to terminate it.There are plenty of other projects i have been working on over the years, but these are a few that comes to mind :)
tisdag 18 maj 2010
First tec-demo video!
Finally! i have decided that i might as well show you all a little tec-demo of the engine in action.
there is a few bugs visible, the normals(lighting) is weird in some places, and a few times you can clearly see blocky areas in the walls, I'm working on this atm.
And since the texture used all over the map is the same one, it is hard to see what is what sometimes...
so the overall graphics will improve greatly when these few issues are solved.
And As long as you guys understand it is still very Work-in-progress, here goes:
http://www.youtube.com/watch?v=GE0QDfIZ8a0
hope you like it :)
there is a few bugs visible, the normals(lighting) is weird in some places, and a few times you can clearly see blocky areas in the walls, I'm working on this atm.
And since the texture used all over the map is the same one, it is hard to see what is what sometimes...
so the overall graphics will improve greatly when these few issues are solved.
And As long as you guys understand it is still very Work-in-progress, here goes:
http://www.youtube.com/watch?v=GE0QDfIZ8a0
hope you like it :)
torsdag 13 maj 2010
Light at the end of my tunnel?
There is light at the end of the tunnel!HA! funny thing... turns out i totally forget about the texture coordinates, when i moved from 24 vertices to 8 on my cubes, and that ment that it was impossible to add textures on the mud... DOH!
My first thought ofcourse was: "all this ... just to hit another dead end!?!? ..."
In pure desperation i swapped to the old rendering function (that uses 4x the graphics) and... to my big Surprise... it runs just as fast as the previous one, in fact... I'm not sure if its my mind playing tricks or not, but i can swear the lowest fps value is higher now... rendering 4x the graphics.
So i thought "well, then it must be because i use smaller holes now" and decided to try big holes again... and once again, i find my self at a steady 60+fps.
uhm... well thats just fine by me.
I can only conclude that the number of vertices was never the problem, but i must have screwed up somewhere in the Octree, or otherwise done some slow funky math.
so... no pointy triangles, and good frame rate... i guess this will be a game after all ;-)
PS: I'm not sure the lighting is 100% correct on the picture above, but that is tomorrows problem.
[edit]
It appears i had a temporary brain-fart, 4x8 don't make 24.
oh well, that is what you get for doing all-nighters.
onsdag 12 maj 2010
ooooh... look at those pretty colors 8-)
Don't worry, nobody spiked your drink... this is only a test.Since the beginning of time(for this project anyway), a constant struggle have been the "pointy triangles" issue, as most of you have seen in earlier pictures and blog posts.
Another issue have been bad performance...
well... I'm here to say both has been solved(most of it anyway), and the picture above demonstrates it more clearly than it would with normal textures.
so don't be alerted about the horrible colors, it is merely a test to more clearly show what is going on.
I am not going power-flower on this game ;)
One sacrifice i was forced to make was to make explosions a bit smaller, this means a bit more squarish holes, but as i see it:
I rather have a decent looking playable game, than a very nice looking unplayable game.
As you can see, the frame rate now shows a nice 61fps, and this seem to be the case for most normal scenarios, except when the terrain is to badly mangled.
of course, I'm sure there are still a few optimizations to do :)
From the way things are currently going, i think a tec-demo video should be able to be done very soon... of course, I have said this before to :P
söndag 9 maj 2010
G¤d d@mn!t!
You know... sometimes it can be very depressing being a programmer, and game development is no exception.
After reading up on the XBox sales market, what games sells and what don't... i had high hopes that my game would do well, and it filled me with so much energy, hope and excitement.
It started this whole damn project up again.
So i spent several days working on my engine, and ended up doing some major surgery on most things in it.
and after a "few sacrifices"... i managed to remove 3/4 of all "unnecessary" vertices rendered(as in 3/4 of all graphics)
And when i say "few sacrifices" and "unnecessary"... that means this most likely will come back and bite me in the ass later... but hey! its not a perfect world.
Now... This is about the time when i start doing some research on the -known performance issues on XBox hardware- ... just to find out that i can expect my game to run 1/3 of the speed it currently runs on a PC.
well thats just lovely... *sarkasm*
so i started reading up on alternative solutions, but the only one(VertexBuffers) apparently are insanely complex and messy to work with on an XBox360.
so that pretty much shatters my dream... we are back to poor performance on the targeted platform, GAAAAHH! *tear his hair*
Well, i guess this mean that an PC version is not totally impossible, it all depends on how fast it will run on a XBox, and this i wont know until i buy an xbox.
(would it not be fun if the game don't work on the xbox, the xbox i only bought to develop my game?)
but i guess i should look at it from the bright side, it will now run smooth like a baby's ass ... on my PC :P
After reading up on the XBox sales market, what games sells and what don't... i had high hopes that my game would do well, and it filled me with so much energy, hope and excitement.
It started this whole damn project up again.
So i spent several days working on my engine, and ended up doing some major surgery on most things in it.
and after a "few sacrifices"... i managed to remove 3/4 of all "unnecessary" vertices rendered(as in 3/4 of all graphics)
And when i say "few sacrifices" and "unnecessary"... that means this most likely will come back and bite me in the ass later... but hey! its not a perfect world.
Now... This is about the time when i start doing some research on the -known performance issues on XBox hardware- ... just to find out that i can expect my game to run 1/3 of the speed it currently runs on a PC.
well thats just lovely... *sarkasm*
so i started reading up on alternative solutions, but the only one(VertexBuffers) apparently are insanely complex and messy to work with on an XBox360.
so that pretty much shatters my dream... we are back to poor performance on the targeted platform, GAAAAHH! *tear his hair*
Well, i guess this mean that an PC version is not totally impossible, it all depends on how fast it will run on a XBox, and this i wont know until i buy an xbox.
(would it not be fun if the game don't work on the xbox, the xbox i only bought to develop my game?)
but i guess i should look at it from the bright side, it will now run smooth like a baby's ass ... on my PC :P
fredag 7 maj 2010
Back on Liero3D
It seems this project just don't want to die, and that is a good thing i guess ;)
I finally got some inspiration back for the Liero3d project.
(This means that the 'planet to surface' engine is discontinued)
but a few things has changed in the process, and in the end, i think some of you Liero fans might be unhappy with what i have decided to do with it. *sorry*
First of all, after doing some research on the Xbox360 Community games and Arcade Live games, i decided that this would be a very nice source of income for me, something i badly need in my current very troubled economy.
So the new plan is to make the project a xbox360 game primarily, and not a PC game as i originally planned.
Now, since this mean making money on the project, i might be forced to change the Theme from classic Liero to a more "soldiers bashing soldiers" style.
This is to avoid any issues with the Aurthur of Liero, and the 'worms blasting worms' from Team17.
I personally doubt that ether party would care much, Joosa Riekkinen never seem to taken his Liero project to seriously and from what i hear, he seem to look back on it as a 'bad memory'.
Whiter this is true or not, i think that the line might be drawn when i start making money on my remake, and hence, think it might be a good idea to simply swap the "skin" on the models.
And as far as Teem17 goes, i seriously doubt that you can copyright the 'Worm' Creature and prohibit it from all future games.
The other 'blast the other player' content is hardly unique in todays games ether.
however, better safe than sorry!
Everything else in the game will still be exactly like the original Liero feeling.
i don't know if i dear to use all the classical Liero names on the weapons, but this is a later problem, and i doubt the game would suffer much if i swapped the name on 'banana bomb' to some other fruit ;)
One of the new big challenges is the xbox hardware, and the big changes this means for my engine.
I also have NO fracking idea how to get my hands on a XBox360 console to test it on, after all... i barely have enough food on the table as it is.
but that is also tomorrows problem.
At least now i feel inspired to put my teeth into it again! :)
I finally got some inspiration back for the Liero3d project.
(This means that the 'planet to surface' engine is discontinued)
but a few things has changed in the process, and in the end, i think some of you Liero fans might be unhappy with what i have decided to do with it. *sorry*
First of all, after doing some research on the Xbox360 Community games and Arcade Live games, i decided that this would be a very nice source of income for me, something i badly need in my current very troubled economy.
So the new plan is to make the project a xbox360 game primarily, and not a PC game as i originally planned.
Now, since this mean making money on the project, i might be forced to change the Theme from classic Liero to a more "soldiers bashing soldiers" style.
This is to avoid any issues with the Aurthur of Liero, and the 'worms blasting worms' from Team17.
I personally doubt that ether party would care much, Joosa Riekkinen never seem to taken his Liero project to seriously and from what i hear, he seem to look back on it as a 'bad memory'.
Whiter this is true or not, i think that the line might be drawn when i start making money on my remake, and hence, think it might be a good idea to simply swap the "skin" on the models.
And as far as Teem17 goes, i seriously doubt that you can copyright the 'Worm' Creature and prohibit it from all future games.
The other 'blast the other player' content is hardly unique in todays games ether.
however, better safe than sorry!
Everything else in the game will still be exactly like the original Liero feeling.
i don't know if i dear to use all the classical Liero names on the weapons, but this is a later problem, and i doubt the game would suffer much if i swapped the name on 'banana bomb' to some other fruit ;)
One of the new big challenges is the xbox hardware, and the big changes this means for my engine.
I also have NO fracking idea how to get my hands on a XBox360 console to test it on, after all... i barely have enough food on the table as it is.
but that is also tomorrows problem.
At least now i feel inspired to put my teeth into it again! :)
tisdag 13 april 2010
A strike of ingenuity
OK, after working on the space-to-surface engine for a little while, i started to notice a few problems down the line.
One of these problems was the fact that when you render huge worlds like you do in a space-to-surface engine, you encounter problems with the horizon and the amount of distance you need to render.
In a normal terrain engine, you might divide your map into Tiles, and each tile can be ... let say 128x128 big, in each of these tiles we then store the vertex data.
Now, lets say we make a world that is 64x64 of 128x128 tiles, up close this might be OK even tho i consider 128x128 tiles a bit big to generate in realtime at max LOD quality on the CPU.
This also means that the size of the tile set the limit of how low the LOD quality can be, basically... you could render every corner of the tile as part of the ground, making it 1/128 of max quality.
But even at this big tiles, 64x128 is not a very great distance for a planet, and even if you double it to 128, its STILL far to short and you would have to fog things prematurely, and whats worse, as big as those tiles might be up close, they are very very tiny at that distance, not to mention all the 128x128 of tiles , thats over 16.000 iterations every render.
After baking my noodle for a while, i got a strike of ingenuity.
I Invent a very special type of QuadTree!
The basic idea is this, using a QuadTree, we can create HUGE world boxes from start, constantly dynamically creating them self around the player when he moves around, we can make them insanely big so they go all the way to the horizon.
When we render our world, we do it inside the QuadTree, where the upper levels(the big size nodes) are rendered as far away tiles at very Low quality, and the closer the camera is to a QuadTree box, it goes lower and lower inside the QuadTree, using the smaller more high quality nodes closer to the bottom layer.
Now, this means we don't have any max tile size limits (well, the size of the QuadTree of course, but we can make that one almost any size we want... like 65536x65536 for example, or even bigger )
and we can still render things all the way down to 32x32 and use as our chosen minimum "tile" size :)
I have found a few problems with this idea, especially since the planet surface is round and the QuadTree would have to be bent along the surface(*yikes*) but that is tomorrows problems.
I really like this idea, not only can i have "tiles" that is 2048x2048(or bigger) rendering like only 32x32 vertices in each, but i also get super high-quality nodes that can be only 32x32 big if i so wishes.
if everything goes as planned, this should be perfect for my engine :)
Then again, i have no idea how others have created there space-to-surface engines, it might very well be a common solution, but at least i figured it out by my self :P
just like the Liero3d project, i don't read much of others solutions, i invent my own. :)
One of these problems was the fact that when you render huge worlds like you do in a space-to-surface engine, you encounter problems with the horizon and the amount of distance you need to render.
In a normal terrain engine, you might divide your map into Tiles, and each tile can be ... let say 128x128 big, in each of these tiles we then store the vertex data.
Now, lets say we make a world that is 64x64 of 128x128 tiles, up close this might be OK even tho i consider 128x128 tiles a bit big to generate in realtime at max LOD quality on the CPU.
This also means that the size of the tile set the limit of how low the LOD quality can be, basically... you could render every corner of the tile as part of the ground, making it 1/128 of max quality.
But even at this big tiles, 64x128 is not a very great distance for a planet, and even if you double it to 128, its STILL far to short and you would have to fog things prematurely, and whats worse, as big as those tiles might be up close, they are very very tiny at that distance, not to mention all the 128x128 of tiles , thats over 16.000 iterations every render.
After baking my noodle for a while, i got a strike of ingenuity.
I Invent a very special type of QuadTree!
The basic idea is this, using a QuadTree, we can create HUGE world boxes from start, constantly dynamically creating them self around the player when he moves around, we can make them insanely big so they go all the way to the horizon.
When we render our world, we do it inside the QuadTree, where the upper levels(the big size nodes) are rendered as far away tiles at very Low quality, and the closer the camera is to a QuadTree box, it goes lower and lower inside the QuadTree, using the smaller more high quality nodes closer to the bottom layer.
Now, this means we don't have any max tile size limits (well, the size of the QuadTree of course, but we can make that one almost any size we want... like 65536x65536 for example, or even bigger )
and we can still render things all the way down to 32x32 and use as our chosen minimum "tile" size :)
I have found a few problems with this idea, especially since the planet surface is round and the QuadTree would have to be bent along the surface(*yikes*) but that is tomorrows problems.
I really like this idea, not only can i have "tiles" that is 2048x2048(or bigger) rendering like only 32x32 vertices in each, but i also get super high-quality nodes that can be only 32x32 big if i so wishes.
if everything goes as planned, this should be perfect for my engine :)
Then again, i have no idea how others have created there space-to-surface engines, it might very well be a common solution, but at least i figured it out by my self :P
just like the Liero3d project, i don't read much of others solutions, i invent my own. :)
söndag 4 april 2010
The new project
OK, it didn't take me long to write a new blog post, and i take the time to do it now because my code is currently messing with me... and i will go Ape if i don't take a break...
so, instead, time to reveal my new big project :)
A long time ago, in a galaxy far far away... (well almost)
I found this video on Youtube from a game engine called Infinity.
From the second I laid my eyes on it, it changed my life for ever :)
Back in those days, I was a strictly 2D & Application programmer, i had accepted my limitations with my very limited math skills and considered 3D way to overkill.
I had made my peace with the fact that i probably would never be anything more than a Application developer, and my memorizes from the old times when i was messing around with OpenGL and C/C++ was anything but pretty.
So the idea that i would ever be able to create a game engine like Infinity seemed totally ridiculous :(
But all this changed roughly 1 year ago when i found the truly awesome XNA framework from Microsoft! :D
It might have taken me some time to get into 3D, but i think i learned everything i needed from my Liero3d project... and now, finally! i feel that i have what i need to start working on the game of my dreams, a Space-to-surface engine like Infinity!
There are several other Space-to-surface projects in existence, and here are a few that i finding very inspirational for my project:
http://petrocket.blogspot.com/
http://britonia-game.com/
among others :)
I have plenty of ideas for what exactly the game-play will be like, but more about this later :)
thats all for now.
so, instead, time to reveal my new big project :)
A long time ago, in a galaxy far far away... (well almost)
I found this video on Youtube from a game engine called Infinity.
From the second I laid my eyes on it, it changed my life for ever :)
Back in those days, I was a strictly 2D & Application programmer, i had accepted my limitations with my very limited math skills and considered 3D way to overkill.
I had made my peace with the fact that i probably would never be anything more than a Application developer, and my memorizes from the old times when i was messing around with OpenGL and C/C++ was anything but pretty.
So the idea that i would ever be able to create a game engine like Infinity seemed totally ridiculous :(
But all this changed roughly 1 year ago when i found the truly awesome XNA framework from Microsoft! :D
It might have taken me some time to get into 3D, but i think i learned everything i needed from my Liero3d project... and now, finally! i feel that i have what i need to start working on the game of my dreams, a Space-to-surface engine like Infinity!
There are several other Space-to-surface projects in existence, and here are a few that i finding very inspirational for my project:
http://petrocket.blogspot.com/
http://britonia-game.com/
among others :)
I have plenty of ideas for what exactly the game-play will be like, but more about this later :)
thats all for now.
lördag 3 april 2010
A new start
Alright, This is my first blog post in a very long time, and I'm making a fresh new start on a new game project(more info later), and at the same time, making a new blog for not only the new project, but all future projects to come.
This mean that future information about liero3d.blogspot.com will be posted in this new blog instead of the old one, this is a strategic move to symbolize my future(i hope) game development company: Frantic Entertainment.
So, any news on Liero3d you ask? well, to be franc, i have not been working on it for a while, and the project is currently on ice.
however, that said, I don't want to publicly terminate the project, And I'm not saying that i wont continue on it, i still consider the project an extremely fun and unique game idea, and I'm sure it would be totally awesome as an intense multi player game.
Problem is, the whole technique used in the engine to destroy the world 100%, as possible as may be, it is also not without its issues.
and I'm a bit tired of spending every day, and every month... trying to making things work in a way that i consider accepted.
And i have come to a point where i feel a bit burned out, i even lost my programming "mojo" for a very long time as a result of the Liero3d project, basically not writing a single line of code for several months, this in turn resulted in me getting rather depressed.
Now, several months later, i have started working on a brand new project, and for the first time in a very long time, perhaps since the beginning of Liero3d, i feel excited about writing code! :)
but more about the new project in my next post (to make it more digestible)
This mean that future information about liero3d.blogspot.com will be posted in this new blog instead of the old one, this is a strategic move to symbolize my future(i hope) game development company: Frantic Entertainment.
So, any news on Liero3d you ask? well, to be franc, i have not been working on it for a while, and the project is currently on ice.
however, that said, I don't want to publicly terminate the project, And I'm not saying that i wont continue on it, i still consider the project an extremely fun and unique game idea, and I'm sure it would be totally awesome as an intense multi player game.
Problem is, the whole technique used in the engine to destroy the world 100%, as possible as may be, it is also not without its issues.
and I'm a bit tired of spending every day, and every month... trying to making things work in a way that i consider accepted.
And i have come to a point where i feel a bit burned out, i even lost my programming "mojo" for a very long time as a result of the Liero3d project, basically not writing a single line of code for several months, this in turn resulted in me getting rather depressed.
Now, several months later, i have started working on a brand new project, and for the first time in a very long time, perhaps since the beginning of Liero3d, i feel excited about writing code! :)
but more about the new project in my next post (to make it more digestible)
Prenumerera på:
Inlägg (Atom)