It definitely runs better on hardware with decent OpenGL shader support.  At a default clip of 128m, my nVidia GTX460 runs it close to 200 FPS except around spawn town on the server... that's pretty overbuilt and so slows to 100 FPS or so.  If I increase clip (F12) to 192, that drops to around 60 in town, 120 or so away from town.

My old GeForce 9800 ran most of the regular world at around 72 FPS.

Mostly it seems like the two year old cards get less than 20 right now if they run at all.... newer beefier cards do better.  On board RAM may also be a factor.

It's tough to say what the final specs will be.  On the one hand, I haven't really optimized anything yet.  On the other, there are a few more things I plan to cram in as well.

Every time I seem to promise something then life takes a good strong whack at my free time.

There will be a release tonight or tomorrow that gives server admins some tools to help clean up griefing.  Also the foundation is then in place for general scripting of admin tools as well as player tools.

Then the plan is to finish up the property user interface and roll that out.  I'd like to say it would be another week... I'll keep my fingers crossed.  The custom tool ability above actually may help out with this since there is no player inventory yet.

Next I go back to trying to get physics stable enough to include (turned on) in a release.  There may be a few iterations of that as I add big objects and ropes, hinges, etc..

Then the plan is to get to Mobs... to include animation, AI, etc..  I may do AI first with no animation and the swing back around for animation.  Somewhere during this process, I will add NPCs that the player can interact with.  It's possible that player inventory gets rolled in with these changes, too... depending on how well things go.

Somewhere in the midst of all of that there will be enhancements to the world generator, too to finally include caves, dungeons, towns, and cities.

My super-extra-aggressive schedule is to try to get all major systems implemented by December... but life has a way of making me eat those kinds of plans.  Especially since that's already a lot later than I originally wanted anyway.  (For example, physics was supposed to be done in July and I'd be almost done with AI by now.)  Oh, well.

Sorry for the pun.

I'm adding some pictures here for posterity though they are also at:
http://www.facebook.com/#!/media/set/?set=a.255248927830966.60189.204533646235828&type=1

This is a new block type I'm playing with.  There is still some tweaking to do and I'm not really happy with the animation... but it may have to do for now.  I'll probably end up playing with the effect and the animation 50 more times before I'm through but at least the infrastructure will be in place.

Just a bunch of big flame blocks:


I added a few different flame blocks to a firewood object and then also put a big flame block on top of the whole thing:


A bunch of different flame blocks in a tree:

Great!  Thanks for following up.

What was the old graphics card that had the funny lighting issues?

The current plan is to do this stuff without scripts but with the "magic electronics".

I also hate visible redstone... so don't worry, it won't be like that at all.  Besides, the electronics will be small components that could plug right into the door or lock or whatever.

Players should be able to make all of this stuff in game... and scripting in game is a real pain.  I used to play old text MUDs that supported that kind of thing and they were a real pain.  And that was already a text-based interface.

I will go ahead and add my public server information here until there is a better place.

I have a host mythruna on game-host.org (put them together as usual) on port 4234.

This same host also has a status web page where you can see recent server activity, most active players, etc...
http://<same host as above>/status

Too many things to address in one response so I'll probably forget some...

I didn't take your post as Minecraft hate but it's hard to convince people that this will be a completely different game when all they see is the test engine and no real distinguishing features.  So I'm concentrating on the "different".

Any game that has a dynamic lighting direction will have occasion where two faces of a cube are lit exactly the same.  Minecraft's lighting direction never changes so it's possible he has it pointing in such a way that two faces never get the same light.  In my case, I've carefully engineered the angle of the sun that it should never happen as the sun and the moon never directly point at a 45 degree angle to a face though it is possible for it to happen briefly with a top surface and a side surface.  I would note that in real leaf this happens all the time.  There are certain buildings for example that in full sun from the right angle completely blend for a while.  Anyway, the player placed light sources can create this situation pretty trivially and that light is based on where the camera is.  Smooth lighting will help but if you look on a lonely brick from a 45 degree angle then two of its faces will be lit similarly.  There's really no way around it without other artifacts... because I originally tried a fixed lighting direction for the non-sunlight and it looked bad.  Minecraft doesn't have to deal with this issue because it's lighting is way simpler.

I'd do smooth terrain if I could.  In fact, my last attempt at a flexible engine 6 years ago was trying to do that.  It's really hard and I spend all of my time trying to make it work instead of making a game.  This engine is 1000 times simpler and lets me develop all of the other systems.  If I ever figure out the other way then I will happily remove block terrain.  There's a chance that the design I have in mind for flowing water helps also make terrain flow better but I think it will kill the geometry generation performance.  It's one thing to smooth a few water blocks and another thing entirely to smooth the whole world.

Sand in real life is very bright... white marble even brighter.  Look up some pictures of tropical coastlines and the sand will be glowing.

It's also a very subjective thing... for every person that hates that they get blinded I get a complement from someone else.  There is some tweaking and balancing left to do but I've taken hundreds of "wow" photos as I walk around the Mythruna world where I catch some cool view that looks perfect.  So right now I like it more than I dislike it.

I should put a post together about the history for those who are interested enough to read it.  I started coding this at the beginning of February... so 6.5 months now.  The networked version was released at the beginning of April and since then I spend a lot of time in the game, too because it's fun.   So development slowed down a bit after that.  Sometimes I just wander around and find the cool and crazy stuff people have built over the months.

Thanks for the feedback.

Per vertex lighting was moved down on my to-do list as soon as Minecraft added it.  It's on the to do list with a bunch of other things like weather, etc. that don't differentiate my game but just bring more MC hate.  Actually, the lighting that is baked into the geometry is already per vertex but it's only in the calculations that its done per face.

There is still a bunch of tweaking to be done to the lighting, for sure... but some of it is intentional and some of it is not exactly what people think.  For example, a good deal of the time where I see a super shining face at sunrise I go there to find a light placed right by it.  Since sunlight and local light is cumulative in sort of an unnatural way it makes these areas super-bright (and note: minecraft only has one kind of light to deal with).  For example, on the server some people like to pepper the face of the castle with light blocks and then during the day these always look like these areas are super-shiny stacked rock... which is a little silly.  There are a few ways out of that problem but they will take days of tweaking lighting equations... and ultimately in the real game most outdoor lights will turn on and off with the day change anyway.

I like the shine and I will keep it.  I spent a long time trying to make it look like the photos I used to take when I did that sort of thing.  At certain times of day, if you want good color on the rest of the picture then anything in direct sun is super brilliant, almost magical.  Without dynamic HDR there really isn't much I can do but match that.

There are literally hours and hours of tweaking left to do on this stuff and especially if I figure out a decent way to calculate the per-vertex lighting for the half blocks and non-square blocks.  But none of that makes me anything but a better looking minecraft clone and since I'm not trying to be minecraft I will work on different things first... there are plenty of huge projects left undone.  Also, the complexity that I've allowed blocks to take gives me some additional issues with lighting and flowing water.  So it also pays to wait until I've explored a few more block shapes.

Thanks again... and I hope you are enjoying Mythruna otherwise.

Single player would actually have an easier time except... there is no way to add them.

The server already had an event system for hooking scripts in every time the player connects or disconnects.  So it was easy for me to add some scripts that configured some new commands for them and then open a way for the clients to send commands directly to the server.  (Most commands go through local proxies first.)

Single player uses the same game code as multiplayer but doesn't have anything like connections or networking or any of that.  It goes directly to the game classes because there's no reason for the extra overhead.

Eventually there will be some support for this in single player mode but I didn't need it for anti-griefing since that's a server problem.  I don't know if single player scripting will make it into this release or not.  I still have to finish custom tools and I may turn it on for that since I'm testing that in single player first.

The interesting part is that this is exposing more modding power, slowly but surely... and from a user perspective it potentially means that I can add more features faster in some cases.

If you are running your own server and know a little groovy you can write your own commands.  Though for a while the API that the script has access to won't really be documented.

Last night I added the ability to configure custom console commands on the server.  It's entirely up to a particular server configuration which commands are setup and who gets them.  I thought some might be interested in this, though.

As a test, I've implemented a "respawn" command and a "tp" (teleport) command.

The server has had a scripting engine embedded in it for a while now and I use groovy to generate the server status page for the public server.  This is the first chance I've gotten to expand it to handle client-sent console commands.

The way the server is setup right now is that anything in the ./scripts directory that matches *.init.groovy is executed when the server starts up.  Facilities are provided for hooking into the various server events like playerConnected or playerDisconnected.  Groovy makes it kind of nice to make sort of a customized language for dealing with things.  

This latest update also adds the ability to attach console commands to a player when they login.

As an example, here is the one that gives just me the ability to respawn and teleport people:

Code:

on( [playerConnected] ) {
    type, event ->
        
    conn = event.getConnection();
    p = conn.getAttribute( "player" );

    if( !p.get("userInfo.userId").equals( "pspeed" ) )
        return;
        
    println( "Adding admin commands to " + p.get("userInfo.userId") ); 
    
    addShellCommand( conn, "respawn", "Moves you back to the starting location.", null ) {
        respawn( conn, console );       
    }
 
    addShellCommand( conn, "tp", "Teleports a player.", null ) {
    
/// Snipped code that parses the parameters for clarity... 
            console.echo( "Warping " + from + " to:" + x + ", " + y + ", " + z );
            warp( tpPlayer, x + 0.5, y + 0.5, z );                          
        }        
    }
           
}

You can see the on( [event type] ) nice customization that makes it easy to run code on one or more different event types.  The rest checks to see if it's me and then adds the commands.  This could just as easily check to see if the player object has specific permissions, etc..

The point isn't that there is a teleport command here but how easy it is to add.  (This is not a very user friendly teleport and I want to handle in-game teleporting in a different way... I added this because it helps me jump around to the parts of the world that need degriefing.)

Next will be to add a versioning module to the world and then the console backup/restore/etc. commands.  Hopefully that won't take very long and I can get an intermediate release out soon... with the property system to follow in a release 5 or 6 days later.  Then back to physics.

Note: this next version also includes scriptable client tools (you know, where you currently have block types and objects... there will be additional stuff) but that's another story.

Heheh.

Mine will be better because it's actually designed into the game.  Though I do need to get it in soon if I want to not look like a copier.  Fortunately, I already at least have my physics video out and the big objects are no different than the small ones in that case.

In Mythruna's case, it's not just for airships either... that's just a side effect.  This will be how you make draw bridges, boats, etc. too.

My scheme for detaching is going to be a point and click thing.  Select the right physics "tool", point at the object and click.  Other than that, our approaches are similar.  I was also going to prefer objects separated from the world but also attempt to determine how to separate them if the aren't.  I think that's where there's was bugging, though.  I mean in addition to their other issues trying to build this on an engine that wasn't really designed for it.  From that perspective it's pretty cool.

For me, the only difference between a big object and one of the blueprint objects is blueprint.scale = 1 or 0.25.  The physics engine already takes this scaling into account.

Lame.

And now when I get mine done everyone will say I copied these guys.

I should note that because of unreported and un-fixed mass griefing all over Atlantis, Abbysall had me roll the place back to the 8th... which was the latest ungriefed backup that I had.

So, some of the buildings are now gone even though the objects remain.  I can spot restore them from today's backup in the cases where you want me to and Abbysall has no problem with it.  I can even restore them and move them somewhere else if needed... though I have no way of moving the objects themselves that way.

There's a ton of object spam there anyway and I'm not sure which is real and which is click-trash.