Media of what you're doing

[Kaz]

Working on putting some different motion planning algorithms into Q3 - here Sarge randomly hops around...

inolen: Should do D3 in browser next!

[lvlshot]http://cs.unc.edu/~freeman/junk/naiveplanning.jpg[/lvlshot]

[Eraser]

Heh, so what's your goal here? Are you talking about implementing different movement physics or client side prediction thereof or bot movement?

[Eraser]

Oh so this game I was talking about in this thread in June, I've picked it up again. Had kind of lost interest in it, but I've wrapped some things up, fixed a few lingering bugs and implemented IndieCity's achievements system and global leaderboards, which kind of means I'll be distributing it via IndieCity (although I'm keeping a non-IndieCity branch around as well).

I expect the game to up available for download somewhere before the end of the year.

[Kaz]

Eraser: doesn't Steam have similar functionality to IndieCity? why not use that?

I want to be able to approximate the time it takes a player to move between pairs of locations in a level. That way, you can report timings for pairs of items, or even display the "time reachable set" for a given location, which would be useful for placing items (and potentially other things). Computing the timings requires solving a robot motion planning problem, where you're trying to minimize time. You can't hope to compute "the" minimal time, but you can come reasonably close in practice using various heuristics to guide the bot toward the goal.

I just finished implementing a first version of Rapidly Exploring Random Trees. The plasma bubbles represent recent states from which the algorithm chooses to move the bot one frame. I'm coming up with a better way of visualizing this because really the bot has explored much more than is shown (the local entities are being sucked away by CGame).

The bot starts out planning from an initial state:

[lvlshot]http://cs.unc.edu/~freeman/junk/q3plan/shot0005.jpg[/lvlshot]

Over time, more and more space is covered by selecting random vertices from which to expand:

[lvlshot]http://cs.unc.edu/~freeman/junk/q3plan/shot0006.jpg[/lvlshot]

Finding narrow passages is a problem for naive sampling based planners, so I was excited to see this happen:

[lvlshot]http://cs.unc.edu/~freeman/junk/q3plan/shot0008.jpg[/lvlshot]

Once it gets through the passage everything works great!:

[lvlshot]http://cs.unc.edu/~freeman/junk/q3plan/shot0011.jpg[/lvlshot]

[Kaz]

Actually here's a better shot of what's happening - unfortunately I hit the entity limit almost immediately . Is there any easy way of upping the max entities, or is that going to be the pain in the ass I think it is? Edit: I think I just just add polygons directly to the scene instead of creating a bunch of entities...

[lvlshot]http://cs.unc.edu/~freeman/junk/q3plan/shot0015.jpg[/lvlshot]

[inolen]

The localents are stored in one big pre-alloced linked list, the max is defined at the top of cg_localents.c - pretty easy to up it seems. I don't think there is a restriction on their resulting refents.

[Kaz]

The localents are stored in one big pre-alloced linked list, the max is defined at the top of cg_localents.c - pretty easy to up it seems. I don't think there is a restriction on their resulting refents.

I upped the localent limit to 4096, but then I hit the overall entity limit and get an error message stemming from the engine. The comment mentions something about if you want to increase it you have to re-order bit packing...

http://wiki.ioquake3.org/Entities

[inolen]

Ahh, yes, the engine uses the entity number as part of the int32 sort key for the draw surfaces.

You could fiddle with removing some bits used by the shader number (SHADERNUM_BITS is 14) and adding them to ENTITYNUM_BITS (which is 10). 16384 shaders sounds rather generous.

[Kaz]

Ahh, yes, the engine uses the entity number as part of the int32 sort key for the draw surfaces.

You could fiddle with removing some bits used by the shader number (SHADERNUM_BITS is 14) and adding them to ENTITYNUM_BITS (which is 10). 16384 shaders sounds rather generous.

Thx for the suggestion... I'll look into that if MAX_POLYVERTS isn't any easier to increase, but it sounds like they should be:

Code: Select all

// these are sort of arbitrary limits.
// the limits apply to the sum of all scenes in a frame --
// the main view, all the 3D icons, etc
#define	MAX_POLYS		600
#define	MAX_POLYVERTS	3000

[^misantropia^]

inolen, how's the project coming along? I confess to being a teensy weensy intrigued.

Kaz, is https://github.com/freemancw/Q3Plan your project? I'm guessing yes.

[Kaz]

inolen, how's the project coming along? I confess to being a teensy weensy intrigued.

Kaz, is https://github.com/freemancw/Q3Plan your project? I'm guessing yes.

Yessir

edit: don't judge potentially crap code

[inolen]

inolen, how's the project coming along? I confess to being a teensy weensy intrigued.

Kaz, is https://github.com/freemancw/Q3Plan your project? I'm guessing yes.

You can take a peek of the latest at:

http://quakejs.com/

I'm right now working on scrambling things together to get a solid demo out. Positional audio was implemented last week, lots of cgame/game functionality is being ported rapidly (localents, weapons, etc.) and I've been solidifying the network layer and predicted movement / events.

While we're still on TCP/IP now, the network code for the most part is ported besides the actual endpoints sending the data / handling connections, in hopes of when the WebRTC DataChannel APIs land we can try out UDP (but to be honest, WebSockets haven't been terrible doing WAN tests on a Linode VPS).

I need to drum up a quick master server this week so the multiplayer is demoable and add some sort of remote control functionality to the server so it can be administered (it just launches and you pray for the best atm). The roadmap is kind of spastic - this is the largest thing I've ever ported.

As a quick braindump regarding its current state:

* clicking the canvas requests a mouse lock. However, if you're on Firefox you must be running fullscreen (alt + enter) for the mouse lock to take affect.

* ` brings up the UI where you can set key bindings (this code is relatively fragile, if it blows up it's not too unusual)

* machine gun, rocket launcher and railgun are the only implemented weapons

* if you're running in firefox, expect poor performance on Mac / Linux as the 64-bit FF's JS engine runs pretty bad in comparison to the 32-bit build distributed on WIndows.

[Kaz]

[^misantropia^]

* if you're running in firefox, expect poor performance on Mac / Linux as the 64-bit FF's JS engine runs pretty bad in comparison to the 32-bit build distributed on WIndows.

Very awesome and performance isn't even that bad in FF 17 on x86_64 Linux. You rock.

[^misantropia^]

As a FYI, I showed it to the people in #node.js and they were very much impressed. But there was lots of clamoring for mouselook. :-)

[inolen]

As a FYI, I showed it to the people in #node.js and they were very much impressed. But there was lots of clamoring for mouselook. :-)

Awesome

Unfortunately, the mouse lock notifications in Chrome that you have to click "Accept" on are really easy to dismiss as some other useless notification, unlike Firefox's which are really big and obvious.

[Eraser]

Nowhere nearly as cool as inolen's stuff but here. It looks a bit different from how it did in my previous video.

[Eraser]

Eraser: doesn't Steam have similar functionality to IndieCity? why not use that?

Just noticed this comment

Steam is less open in allowing stuff on there and it costs money. Steam is now using the Greenlight system, where your put up videos and screenshots of your game and it basically competes for a place in the Steam store with other games. This means that a lot of other, far more popular titles will probably push my game away. Also, getting your game on Greenlight will cost you a one time $100 fee. It's cool that they give all this money away to the Child's Play charity, but it's an investment of a proportion that I'm not willing to make just yet.

IndieCity however, allows anyone to put up games for free and if they pass the community validation (which basically is as much as checking if there aren't any obvious technical faults with the game) they're made available for purchase and download. They're also more open in the revenue sharing model they use. Steam doesn't say anything about what percentage of the revenue take, while IndieCity simply states that they take 30% if the IndieCity SDK isn't implemented and 15% for games that do have the SDK implemented.

So the threshold of getting games available on IndieCity is far lower than Steam. I'm also going to have a look at Desura though. That might be another option. If anyone knows of any other platforms that allow me to distribute my game, then I'm interested.

[inolen]

Doing some local net tests:
[lvlshot]http://i.imgur.com/8aDPm.jpg[/lvlshot]

Cobbling together a UI:
[lvlshot]http://i.imgur.com/YE5hl.jpg[/lvlshot]

Things are really starting to come together

[D-Meat]

now this looks very very neat =D

[Kaz]

Forgot to post this here. Comes with an overview of what I'm doing at the beginning - note you should watch it in 720p for more legible text.

I'd like to actually turn this thing into something that can be included with Radiant and produce a demo map showing how to use it, but the amount of engineering it will take to get it where it needs to be makes that sort of questionable. (who knows, though... )

[obsidian]

For future reference, you should type all that into the video description, so people watching your video don't have to watch 8 minutes of you typing with 1 minute of actual demo.

Interesting concept, though I think you also need to keep in mind that real players often will use other devices like trick-jumps to move around a map far faster than a bot can.

[Eraser]

How come the bot takes 14 seconds to move towards the goal while simply walking along the plotted path should take no more than half that time?

[Kaz]

For future reference, you should type all that into the video description, so people watching your video don't have to watch 8 minutes of you typing with 1 minute of actual demo.

Sorry, that is pretty derpy...

Interesting concept, though I think you also need to keep in mind that real players often will use other devices like trick-jumps to move around a map far faster than a bot can.

How come the bot takes 14 seconds to move towards the goal while simply walking along the plotted path should take no more than half that time?

Maybe I should write something to explain this better. The idea is that if you let this process keep going and don't stop it when it finds the first path, then it will over time find faster and faster paths and reduce the time it takes to reach the goal (i.e. it will find those trick jumps that allow it to move to the goal like a player would). The bot isn't using the standard bot movement Q3 provides already, it's just randomly choosing how to move at each time step (you can come up with better strategies than this). I assume that I can find better paths than the standard Q3 planner, it's just a matter of running enough iterations. The reason it takes so long to find even that first path is because I'm running everything in real-time so that I can visualize what's going on. If I want to make this into an actual tool you need to run a dedicated server without a client, and try to make it produce new states as fast as it can. That should allow it to converge on fast paths in just a couple of minutes since it doesn't have to do any rendering.

This is a more illustrative video of what I'm talking about. This is a slightly different algorithm than what I'm using, but the idea and the results are the same. Watch how the red line converges to the shortest path over time. Imagine the same thing happening, only with a Q3 player inside a 3D level.

[obsidian]

So does this mean you will soon post a new record time for Quake Done Quick, one in which your computer does all the work?