Jump to content

Mondoid 16/09/13

Headshotkill

By Headshotkill
in General Discussions

 Share

Recommended Posts

Headshotkill

Headshotkill

Posted
Posted

Hello everyone, it's monday again which means a brand new Mondoid to absorb soon into our empty souls... :???:

But anyway, the game is getting closer and closer to perfection as theindiestone is hard at work. I don't know what we may expect from this one but we can hope!

After all, hope is all we have left in these dark days...

The links! (NOTE: if you do not find the new Mondoid yet then this means it hasn't been released yet, come back in 30 minutes or so...)

Main/official blog: http://projectzomboid.com/blog/category/news-development/

alternative link for those with limited internet-acces (NOTE: This can take a bit longer then the official blog so be patient if it ain't uploaded here yet.) : http://theindiestone.com/forums/index.php/topic/3-mondoid-reposts/page-4

And as always, happy MONDOID everyone! (fedora)

Link to comment
Share on other sites
Roach

Roach

Posted
Posted

I hope that they finally tell us more about the dragons.

 

ykq1RTP.jpg

If you look closely you will see that the zombies are not interacting with the nearby dragon,

from this we can conclude the existence of upcoming zombie dragons leading their hordes.

 

 

 

Also note the zombies standing in a perfect line, 3 of them yeah.. half life 3 confirmed guys.

Link to comment
Share on other sites
Roach

Roach

Posted
Posted

Not running, just staring the other direction as if they're embarrassed.

Everyone has a cousin who always makes a fool of himself at family parties.

Yeah exactly, they thought they were gona be the main stars in this game and now this guy walks screwing them.

Link to comment
Share on other sites
RobertJohnson

RobertJohnson

Posted
Posted

 

If you look closely you will see that the zombies are not interacting with the nearby dragon,

from this we can conclude the existence of upcoming zombie dragons leading their hordes.

 

 

 

Also note the zombies standing in a perfect line, 3 of them yeah.. half life 3 confirmed guys.

 

 

Haha, made my day :D

Link to comment
Share on other sites
lemmy101

lemmy101

Posted
Posted

Would be interesting to hear exactly which 1% that C++ reimplementation would cover, as in where the engine currently spends too much time. Drawing the scene perhaps?

 

lighting, actually building the scene, and drawing the scene

 

the last is (if enabled) happening on another thread, but the lighting and building the scene is still slow and we're finding few ways to significantly speed it up any further, due to the (I'd liek to think) high graphic fidelity / isometric combo. Isometric makes some very restrictive limitations on how you can build and draw a map, and the smooth lighting on a 3D game or any other perspective could be made much faster just by tinting the verts of the wall poly's. We're having to draw over the wall tiles with another poly, with a ton of slow state changes between each one instead of batching them all up in a super sexy long buffer to the card. Isometric has certain demands that cannot be avoided, and doing the lighting on the walls requires a lot of extra stuff that wouldn't be necessary with a 3D game for example. I think it would much surprise people quite how much is going on under the bonnet to make that smooth lighting work. A crap ton is how much.

 

Another potential optimization we've considered is drawing all the walls as poly's instead of iso tiles, but the amount of upheaval and work both art and code at this stage would be immense, so it's difficult to imagine when we could implement that. Hindsight is 20/20, we had no godly idea what graphics level we'd be shooting for when we started and were a bit greener when it came to java and opengl.

 

Add to that that everything in modern graphics cards is tailored to rendering 3D stuff, not 2D, and a lot of the assumptions they make about how data is sent becomes incompatible or nowhere as effective with 2D, especially layering on the slightly unorthodox way we had to do the lighting to work on 2D tiles, which isn't a problem generally for 2D games since their graphical requirements are quite low, but the fact that our draw poly count is a ton higher than any 2D game I can think of, with no possibility of z buffering or texture sorting, batching etc due to iso cuts out 99% of the most common ways to vastly optimize an engine. (lets not forget 100s of pathfinding zombies that need to collide with each other and the environment in real time :D)

 

As an analogy. Imagine moving 30,000 files from one directory to another, with the requirement of sending emails announcing the next files you are going to move. Most 3D games could just drag select the files in 1,000 file chunks (perhaps organized by file type), Ctrl-X, go to target directory, Ctrl-V. Then send an email about the next 1,000. We have to drag each file across individually, and send an email sabout the next file between each single one. One by one, each with an accompanying email. We can't even sort the directory by file type to make it easier, as each file has to be copied over in a strict order. Perhaps if we're lucky we may occasionally find we can copy 2 or 3 files in one go, but it really is that sucky.

 

Add onto that the fact java isn't the fastest, and our low spec target audience, and it ends up being frustrating to read people's very very frequent comments essentially saying 'why doesn't this in development java game with a single engine programmer made in a couple of years run as well as this full released AAA C++ 3D game with custom nVidia/ATI optimizations built into the drivers that had 30 people working on the engine alone for 10 years ' :D

 

Of course there would have been one way to massively speed up the game in practically every regard, but sadly it wasn't suitable to our needs.... I was going to draw a diagram but Paint is a bag of sickening shit and its way too much effort to find another app and install it. In summary, another of the biggest CPU and memory hog generally is the fact that walls aren't a full tile in width..It's possible for you to have two adjacent tiles that cannot be traveled between, next to two adjacent tiles where you can. In fact all 8 directions for each tile need to be considered independently, and there are a myriad of different types of tile that affect these differently (windows can be pathfinded through but have collision, trees cannot be seen through but can be walked through, etc etc etc) instead of just being able to say 'that blocks full, that one's empty, that one's full, that one's empty'. This makes both collision, line of sight, data storage for collision, and pathfinding all have to do way more work and store way more stuff than we would otherwise (as well as rule out a lot of great A* optimizations into the bargain)

 

It also means either much more data to be loaded/saved, or (as it is now) much more data to be processed post-load. Then how fast do you process that data? too many per frame and low end PCs will suffer (FPS). Too few per frame and high end PCs will suffer. (those dark square chunks as you run, anyone?) 

 

IF we started again, completely from scratch, would we be able to make the game run better? For sure. Sadly it's not really possible to know exactly every challenge you'll face in advance of making a game. Especially your first isometric game engine, first time using java, and first time using opengl, We have to be creative at this stage to get the most we can out of it, until we've got the moneys to help finance more wide sweeping rewrites of stuff without dragging releases to a stand still again.

 

that's not a rant, per se, I don't really think customers really care why, or that they should, as it's just the end result that matters, I just wanted to get this down as it's a common thing people say that can be a tad frustrating  :D like Crytek engine  and a small low budget java indie game's engine as comparable equivalents :D if your computer runs CoD Ghosts in highest settings, that's a strong indication that you'll have better performance on zomboid than someone who can't, but there is little else of relevance in the comparison of FPS and graphical fidelity as so so so much else could be going on.

Link to comment
Share on other sites
Calzila

Calzila

Posted
Posted

I demand in my new petition, that we all help together and make the town zombie proof. Nasko should be the mayor and K is banned from it forever.

KOS K!

Thank you very much. And now to the next point,

Zombies ruining our lawn as we all know.........

well you can caunt me in ;) i for one would love to live in this quant sounding little town. who thinks that one day far FAR in the future when multiplayer is implemented we should all get together on a server and make this dream a reality. whos in? say i :D

Link to comment
Share on other sites
harakka

harakka

Posted
Posted

 

Would be interesting to hear exactly which 1% that C++ reimplementation would cover, as in where the engine currently spends too much time. Drawing the scene perhaps?

 

<snip>all the stuff</snip>

Thank you Lemmy. I couldn't have imagined to get as in-depth answer as this. I have no further questions.

 

As an aside, I loved the old articles you did about issues with isometric development. If you ever have free time in your life again, I'm sure tons of people would love to read an article on your blog or Gamasutra or whever on all the challenges and solutions you guys have come across in developing an isometric game with your tech and skills.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share
Go to topic listing
×
×
  • Create New...