Forum adverts like this one are shown to any user who is not logged in. Join us by filling out a tiny 3 field form and you will get your own, free, dakka user account which gives a good range of benefits to you: No adverts like this in the forums anymore. Times and dates in your local timezone. Full tracking of what you have read so you can skip to your first unread post, easily see what has changed since you last logged in, and easily see what is new at a glance. Email notifications for threads you want to watch closely. Being a part of the oldest wargaming community on the net. If you are already a member then feel free to login now.

Automatically Appended Next Post:
that info box is just mad i want one...

Would begin to breakdown in a minor fashion with non-6" movement models. Necron Destroyers, jetbikes, bikes, jump troops, jump packs. A lot of those can't always be precisely identified by the base size; there would always be some overlap. Positively IDing each model solves this handily as well. Admittedly, it will also drive costs UP, but hey this is a mental exercise not a R&D lab, lol!

Right, but what I was trying to get at was, the system would know where everything is initially, as you told it when you deployed. Once you move something, it can know where it is now because it knew where it was originally.
Here's another thought that I didn't put down, but that would make what I was saying a little more clear (hopefully):

When you pick up more than one model with identical bases, let's say, a terminator and a terminator chaplin, the system can complain asking you to replace one of them where it was, with a handy indicator for each model's location, or to identify the models when they reach their destination. There would be some context to this as the system would know which models were off the board, and only let you select from those models. Of course it relies
on the users to do so in an honest fashion, but the same is true for gaming now. Besides, it's one of the first principles of computing: garbage in, garbage out.

Sure, we could talk 3D laser scanners, but that is just taking things out of the realm of reality I think. Might as well start talking about adding a V-8 for power, lol.

Ah the joys of working in a university environment, there's a guy down the hall with one. He uses it to scan spiders, when I was helping him set it up all I could think was "Man I'd love to use this thing on some minis!"

Also, I think that this idea would kick ASS for vehicles, especially custom jobs. However, TLOS in general would make things a HUGE PITA, as you would damn near need a full 3D scan of each model in order to determine what kind of TLOS it has to target and from a shooter. Ditto for terrain. Unless we leave that interaction completely to the humans (possible, the system should be a value-add to the game, but does it really need to wipe your butt for you as well? Cmon, we can still do SOME things with it!! lol

Assuming you had the 3d models you could load them into a game engine and then let it handle figuring out LOS, letting each model shoot lasers from it's eyes/gun-ports/whatever and then doing a collision detection. Then
tell you if you give off a cover save and so on. I agree that it shouldn't wipe, but could it at least make coffee? And sandwiches, that would be good. OHH! OHH! And get beer from the fridge! must start hacking roomba...

This is so awesome!

iPwned wrote:Assuming you had the 3d models you could load them into a game engine and then let it handle figuring out LOS, letting each model shoot lasers from it's eyes/gun-ports/whatever and then doing a collision detection.

But how do you handle if you can shoot under a Wave Serpent?

*ducks*

iPwned wrote:
Right, but what I was trying to get at was, the system would know where everything is initially, as you told it when you deployed. Once you move something, it can know where it is now because it knew where it was originally.

Which is still going to require a manual upload of the ID for each fig as deployed. Even if it has the stats stored in a database, you will still have to tell the computer the model, where in the list, and all options. Sorry, I think the RFID idea wins out here. Your method is more efficient for physical tracking, but I was trying to address a couple of different problems at once.

daedalus wrote:

iPwned wrote:Assuming you had the 3d models you could load them into a game engine and then let it handle figuring out LOS, letting each model shoot lasers from it's eyes/gun-ports/whatever and then doing a collision detection.

But how do you handle if you can shoot under a Wave Serpent?

*ducks*

I see what you did there. Yeah, TLOS is going to make this a bitch kitty.

I know it was just a project and they did some amazing stuff but I thought it was funny when they manually rolled dice at the end. It's like using a Star Trek transporter beam to land somewhere and strike a match to light a candle

No-one has any trouble putting their models on a table, moving them around, and working out ranges and combat results using a tape measure and their brain.

The key problems the game faces are unpainted armies and crappy looking terrain. (Let's not get into the rules.)

If you had a couple of thousand dollars to spend on the table and computer, you would be much better advised to spend them on figures and terrain.

That said, as a student project it was obviously a good way of learning about interface design and coding.

That's one opinion, KK. It's valid. It's also an opinion. I think that this table would be, while in every respect that I can see hideously over-costed, also a time saver in game.

2 examples:

1. pick up a model, and a bulls-eye comes up where it was demarking the 6" movement area it can move in, with circles marked out every inch.

2. Verbal interface: tell it to fire squad Humptysquat at your opponents squad Cornhole. It rolls to hit, to wound, and saves in less than a second and spits out the number of casualties.

Multiply timesavers like this over the course of a game and it could really shorten things up some.

It's not a matter of making the computer do things that people have "trouble" with, as you were discussing. It's a matter of making a computer do what it is good at, calculations at a ridiculous rate of speed.

Now, you do make an inferred point that it's not really worth it to seriously build (for a laundry list of reasons), but you never know what kind of ideas people will figure out in an exercise like this.

I have three solutions!

1. Buy the university for full use of the board.
2. Become principal of the university.
3. Get one of the students to throw a brick at you while you walk below a window, then sue the uni for faulty building, have a 'change of heart' and get the board.

And for the slow people, that was a joke. A bad joke, yes.

Was that a joke?!?! Was that actually meant to be funny? lol

Kilkrazy wrote:No-one has any trouble putting their models on a table, moving them around, and working out ranges and combat results using a tape measure and their brain.

The key problems the game faces are unpainted armies and crappy looking terrain. (Let's not get into the rules.)

If you had a couple of thousand dollars to spend on the table and computer, you would be much better advised to spend them on figures and terrain.

That said, as a student project it was obviously a good way of learning about interface design and coding.

Maybe. Maybe. But then there's always the gadget junkies like me that would buy the thing (assuming I could afford it, of course) just because.



grizgrin- Thank you. Thank you so much. Forever more, my new Dire Avengers squad shall be known as "Squad Humptysquat".



Ghidorah

this is pretty coolll

Thank me not. Thank the United States Navy. For verily THEY provided the name for your squad.

Kilkrazy wrote:No-one has any trouble putting their models on a table, moving them around, and working out ranges and combat results using a tape measure and their brain.

The key problems the game faces are unpainted armies and crappy looking terrain. (Let's not get into the rules.)

If you had a couple of thousand dollars to spend on the table and computer, you would be much better advised to spend them on figures and terrain.

That said, as a student project it was obviously a good way of learning about interface design and coding.

But you're forgetting that when not playing 40k, you'll be enjoying the best game of Supreme Commander you've ever played!

and really, a 6x4 touch screen has got to have a ridiculous number of uses. Beyond completely breaking your finances, that is!

Which is still going to require a manual upload of the ID for each fig as deployed.

Right, I understand what you're getting at now.

and really, a 6x4 touch screen has got to have a ridiculous number of uses. Beyond completely breaking your finances, that is!

Data visualization anyone?

I'm still curious to see if someone could pull this off in a workable - consumer made - not ridiculously overpriced way...

If someone actually did this, and tied in something like Vassal 40k (for the processes) - i would pay.

And as far as LOS goes, I would just run it as 'size 1 barricade, provides size 2 model w/ cover'. changes existing rules - but I think a PC might just have an easier time with it.

Just sayin'

Why not let the players deal with LOS, and let the computer deal with what it does best, which is the math, data, computations, what ever you want to call it?

64mas wrote:Why not let the players deal with LOS, and let the computer deal with what it does best, which is the math, data, computations, what ever you want to call it?

I'd guess because LoS is a common source of arguments.

Good point.

LordRavurion wrote:With a microsoft surface and a bit of keen programmaing it should be possible to make...

...a blue table of death.

JonnyDelta wrote:I'm still curious to see if someone could pull this off in a workable - consumer made - not ridiculously overpriced way...

If someone actually did this, and tied in something like Vassal 40k (for the processes) - i would pay.

And as far as LOS goes, I would just run it as 'size 1 barricade, provides size 2 model w/ cover'. changes existing rules - but I think a PC might just have an easier time with it.

Just sayin'

I think mebbe the 4rth Ed terrain rules would work well here. As far as making it wallet friendly, we are talking about 24 square feet of touch screen. That's better than (9) 22" touchscreens. Looking at Newegg, you are talking about mebbe 650 bucks for a 19" touchscreen monitor. Not knowing the actual l x w of the screen in question, I roughly estimate you would need the equivalent of about 30 of these screens to make up this tabletop. That's 20 grand right there boys and girls. yep, $20,000.00 USD. Let that sink in for a minute. Now, 3D laser scanner? Someone else care ot dig that one up? lol

64mas wrote:Why not let the players deal with LOS, and let the computer deal with what it does best, which is the math, data, computations, what ever you want to call it?

I think I would agree with this. It would come down to how the actual engineering would go.

hat's better than (9) 22" touchscreens. Looking at Newegg, you are talking about mebbe 650 bucks for a 19" touchscreen monitor. Not knowing the actual l x w of the screen in question, I roughly estimate you would need the equivalent of about 30 of these screens to make up this tabletop. That's 20 grand right there boys and girls. yep, $20,000.00 USD.

Well, if you went for the kind of system demoed here: http://cs.nyu.edu/~jhan/ftirtouch/ you could get a little cheaper on the materials. A sheet of acrylic that size will set you back less than $100, maybe another $300 for electronics (IR LEDs, and some driver circuits), a projector $700 for some models on newegg, and a camera $112 on newegg for high quality unit. For a ball-park total of $1200. Now, I would budget more than that, but you can still do an order of magnitude better than 20 grand.

And as far as LOS goes, I would just run it as 'size 1 barricade, provides size 2 model w/ cover'. changes existing rules - but I think a PC might just have an easier time with it.

With the right representation, it wouldn't be any harder to do true los with a computer than it would to run a FPS. Granted, I wouldn't want to have to build the 3d models, but it could be done.

If the pricing can be done that cheap, this could really be doable. The problem with the TLOS isnt programming it in, it is coordinating all your terrain pieces, with the TLOS models in the software, WITH a touchscreen. You aren't going to be able to just throw down that styrofoam hill you made for that table at the FLGS onto the touchscreen, and have the computer 1)sense your models on the touchscreen as they will be at that point on the hill you made! 2) determine any TLOS with it unless you RFID it twice (for heading) and have a 3D model linked ot that RFID ID. I suppose you would be able to get around the models not touching the screen, but it would take active, real-time 3D scanning............ no it wouldnt. It wouldn't at all, and if we are using my previous idea of using 2 RFID chips to track each model we could do it from there. The multiple RFID readers could be used to determine the models position in 3 dimensions (4 if the refresh rate can be coaxed high enough, but I dunno enough about RFIDs). You lose the benefits of auto-measure and whatever screen-based tools end up being installed to enhance/speed gameplay around the models poition on the board, but a secondary data screen could be used to display that.

Really, if you can track the models in real time, you don't NEED touchscreens for the table surface itself unless there are software tools to be displayed under the model that you are set on. You could use one or more data screens around the table top to display whatever data you wanted about whatever piece is in motion, verbally requested, whatever. As system like THAT could be run from a laptop, and be installed in a matter of minutes on pretty much any table you decide to play on anywhere. You would still either need to play with pre-built terrain or have a method to scan in terrain very quickly, but really thats only if you are dying for portability.

What that idea DOES do, however, is begin to call into question what you are designing, and what problems you are attempting to solve. If you want a portable system to speed/enhance play, or if the touchscreen is an integral part of the device. But depending on what you want/need, there's some very cool, and financially doable, ideas there.

Let's see what you do with them, dakka. I have faith, there is some great stuff in this thread.

Oh, and KillKrazy: We are now talking ideas that would require a hell of a lot of work, BUT are in the below 2,000 USD range, or so it would seem. THAT is why we do silly things like dream, and collaborate on our dreams. Love ya. Mean it.


Automatically Appended Next Post:
I tell you what, dakka. I will issue you a challenge. It is inspired by all the participants in the thread so far, and is open to all of dakka.

If Dakka meets certain criteria in designing a tabletop in this thread, I will build it. Here are your criteria:

1) Clearly stated set of issues the table is designed to address/overcome.
2) Faster, slicker data interface than the current model (plain tabletop).
3) Coolness factor. If it is useful but has some suckitude factor, I ain't havin it. Vast power requirements are not considered a down side, neither is carbon footprint, lol.
4) Overall cost of 1,000.00. I can possibly sway on this a little bit, but dont expect construction to commence until 2010.
5) grizgrin retains ultimate judgement of go/no-go with the project. I have to want it

I think we are looking at this differently, my interpretation was thatt all of the hills and other terrain would be part of the projected image.

The only thing going on the table would be the models themselves (thus my previous statement about LOS interpretations).

My vision of this is similar to Vassal 40k but now I'm actually my Orks/Marines/Guard onto the table.

The buildings/hills/templates, even the rulers are all part of tables (read: PC powering the table) domain.

In return, I will draw up engineering manuals for the table, and everyone will get an electronic copy that they may use for their own table or as a basis for an even cooler table. Everyone who contributes will get a credit and a mention. Once I get the bits purchased, I will be willing to accept donations to replace monies spent on the project, but that is optional for all. i will accept nothing before I make te purchases. We can find ways to reward donaters that would be cool; naming components after individuals who have donated might be funny and cool. "The IPwned data display unit, or IDiDU", for example. Just a thought, I take suggestions. If we get some donations coming in, that will up our budget on a 1:1 basis.

grizgrin wrote:
What that idea DOES do, however, is begin to call into question what you are designing, and what problems you are attempting to solve. If you want a portable system to speed/enhance play, or if the touchscreen is an integral part of the device. But depending on what you want/need, there's some very cool, and financially doable, ideas there.

Exactly

grizgrin wrote:
1) Clearly stated set of issues the table is designed to address/overcome.
2) Faster, slicker data interface than the current model (plain tabletop).
3) Coolness factor. If it is useful but has some suckitude factor, I ain't havin it. Vast power requirements are not considered a down side, neither is carbon footprint, lol.
4) Overall cost of 1,000.00. I can possibly sway on this a little bit, but dont expect construction to commence until 2010.
5) grizgrin retains ultimate judgement of go/no-go with the project. I have to want it

1> Objective, I want to play with my toy soldiers versus YOUR toy soldiers without having to go to your state. I want this to remain GW legal (so you have to own the unit I'm playing against (no Vassal)).

We'll skip on the interface for a minute;

Assume:
Internet connection
Hardware
Camera (of sufficient resolution mounted "above" the table) think webcam.
Projector (of sufficient resolution mounted "above" the table).
Microphone and speakers
PC.
Software
Image recognition (with some kind of "this is a terminator", this is a "terminator with a Chainfist" setup process)

- meeting -

The camera is to provide the "touch screen" capability
the projector allows you to see what is going on on the other side of the world.

Bonus: really cool battle reports.






Automatically Appended Next Post:
I've got camera above table and projector as well; but you could do it with camera/projector below. you would have to be more deliberate about movement of units, etc, but still doable. see (http://www.instructables.com/id/Interactive-Multitouch-Display/) for a multi-touch example.

there are different ways to do this, so we'll leave the "multi-touch" implementation open to research for a minute.

Assuming you want to get this up and running quickly (because that's really the point); It could be done with a pair of tables, a pair of cameras, and a pair of projectors. we setup, take pictures at key moments, your projector projects what my camera sees... etc. and we use a 3rd party die-rolling site on the internet to generate random numbers.





Automatically Appended Next Post:
future features: terrain, movement distance, shooting distance / tLOS determination, unit statistics. fancy "pew-pew" noises and laser zaps. combined feeds uploaded to u-tube. Internet Gaming League.

Total World Domination.

you know, the regular stuff.

@skipcne: That's a great link! Not so much for the original target, but for the stuff you can get to off of that. Wound up here: http://wiki.nuigroup.com/Main_Page

Having read some of the info on the links, I think they used a rear diffused illumination screen (http://nuigroup.com/forums/viewthread/1982/), it lets you do touch tracking and object tracking. In particular, it let's
you use tags on objects to identify them uniquely, and tell how they are oriented. But it identifies the tags optically, so print the labels, slap them on your bases, and
start going.

I like the idea of networking real world 40k, but I have the following issue with it:
*Terrain: Having both physical terrain and virtual models presents challenges consider this - My friend in another part of the world and I set up for 40k, I own some
cod terrain that we'll use, and he has a sky shield that we also use. How do I place my models on/under his landing pad, and how does he place his models in my
ruins. Strictly speaking, we could have identical terrain at both locations, but how do we display model location in 3-space? If your projector is above, we can place
the virtual models on top surfaces, or under terrain if the projector is below. To do both would require 2 projectors, and that kills the budget there.
I would propose that the first implementation use only area terrain to avoid these issues, adding in support for real terrain in a later iteration.

The interface would likely have to be developed ourselves. I would propose using either Java, or a set of open source interface libraries (Qt/GTK) so that it can run
on windows/mac/linux. Any other programmers in the house?

edited to balance parens

DAAAAAMMMMMNNN, and the creative juices flow. Great ideas. i like how skipmcne is willing to go outside the constraints of the original project idea. Good work.Clear, concise definitions of what you intend are essential. I love it!

So, we have ideas for:
1) networked real time 40k.
2) touchscreen irlVassal. irlVassal because you are using physical models to play in the Vassal (or similar) virtual environment. To head of IP/legal issues, I will refer to this method as "e40k Unloaded". e is for electronic. 40k because we are using GW models. Unloaded because the virtual tools are provided, but no additional tools like we have discussed here (auto-measuring circles, RFID model tracking, etc...)
3) touchscreen e40k Loaded. This means that, unlike Vassal where the virtual tools are provided, the software/hardware handles measuring, rules display, rolling, ANY kind of gaming processing that can be foisted off onto the processor for time savings/ease of play.

I'll go further later, but I gotta get. Damnation, keep it coming!