Forums » Suggestions
paint station
Hi all, just an Idea I had.
Some stations would have "paint shops" which can change a players ship's color and maybe the paint style. Because right now, the taur's paint infuriates me, so I get different paint at the paint shop. The style would be made by the devs, with maybe player contests to make a new one every month or so. Ideas, Suggestions?
Some stations would have "paint shops" which can change a players ship's color and maybe the paint style. Because right now, the taur's paint infuriates me, so I get different paint at the paint shop. The style would be made by the devs, with maybe player contests to make a new one every month or so. Ideas, Suggestions?
This would be cool. But beyond the "dynamic color" aspect of the ship, it has a couple of stumbling blocks. We can either:
a) Do more dynamic overlay patterns on the ships. This would effectively work as more texture layers, perhaps allowing additional color configurations and so on. It would take quite a bit of work to probably get this into the game, and it might not be trivial to make layer-on "color" maps that actually look good when mixed with other colors. Plus, it would be a performance hit for some players (the more layered maps, the more for the videocard to do).. unless we did some "render to texture" type stuff, like we do for the nebula backgrounds. The issue there being.. someone warps into your sector with a new color config, and all of a sudden your game stutters while your videocard is doing a bunch of dynamic "render to texture".
b) We construct more static maps, with various styles, for different ships. This is the easiest to do in the short term. It has the downside of wasting space, since the maps are actually static within the game client (media.rlb), increasing the download size of the game. The maps aren't huge (512x512, jpeg) so we aren't talking a massive size increase, but if there were a large number, it would add up. It would also increase the "possible" footprint of the game in video memory, as these textures might not be loaded by default, but if you were in a busy locale with a diverse selection of configured ships, you might end up with all of them being loaded. For more modern computers, this is not a problem, it could mostly be an issue for 128MB and smaller cards (mostly smaller).
I lean towards "b" for the moment, but it's not that elegant of a solution, and has long-term scalability issues. For dynamic "painting" and such to really work in an MMO, you need it all to be realtime and on-the-fly (like "a").. but that also takes a lot more time to develop.
a) Do more dynamic overlay patterns on the ships. This would effectively work as more texture layers, perhaps allowing additional color configurations and so on. It would take quite a bit of work to probably get this into the game, and it might not be trivial to make layer-on "color" maps that actually look good when mixed with other colors. Plus, it would be a performance hit for some players (the more layered maps, the more for the videocard to do).. unless we did some "render to texture" type stuff, like we do for the nebula backgrounds. The issue there being.. someone warps into your sector with a new color config, and all of a sudden your game stutters while your videocard is doing a bunch of dynamic "render to texture".
b) We construct more static maps, with various styles, for different ships. This is the easiest to do in the short term. It has the downside of wasting space, since the maps are actually static within the game client (media.rlb), increasing the download size of the game. The maps aren't huge (512x512, jpeg) so we aren't talking a massive size increase, but if there were a large number, it would add up. It would also increase the "possible" footprint of the game in video memory, as these textures might not be loaded by default, but if you were in a busy locale with a diverse selection of configured ships, you might end up with all of them being loaded. For more modern computers, this is not a problem, it could mostly be an issue for 128MB and smaller cards (mostly smaller).
I lean towards "b" for the moment, but it's not that elegant of a solution, and has long-term scalability issues. For dynamic "painting" and such to really work in an MMO, you need it all to be realtime and on-the-fly (like "a").. but that also takes a lot more time to develop.
Why wouldn't each unique configuration just have it's own file on the server, (made when it is painted, deleted when the ship is dead/repainted) and when said ship warps into the sector, the server distributes the file to the players.
In fact, it could distribute the file as the said ship starts to warp into the sector, giving even more time for the server to complete the operation.
Heck, it could even be a system-by-system thing.
It sounds kinda server-heavy, but I guess it could work...
In fact, it could distribute the file as the said ship starts to warp into the sector, giving even more time for the server to complete the operation.
Heck, it could even be a system-by-system thing.
It sounds kinda server-heavy, but I guess it could work...
The problem is then you have the people all downloading stuff on the fly. So, say you're in the midst of a PvP battle with someone, and Random Guy X flies into the sector, do you want your battle to be lagged briefly while your client downloads his elaborate texture?
Our whole.. architecture is built around avoiding that. Only transferring large blocks of information during specific times (like, say, jumps/warps, etc). Otherwise everyone "pauses" to get Bob's new ship mods. It doesn't scale well unless the data is really lightweight.
And that, we can do, it's part "a" in my previous post. But that's more "realtime" type stuff, rather than static textures. And that takes quite a bit of development time to make something both lightweight and aesthetically pleasing.
Our whole.. architecture is built around avoiding that. Only transferring large blocks of information during specific times (like, say, jumps/warps, etc). Otherwise everyone "pauses" to get Bob's new ship mods. It doesn't scale well unless the data is really lightweight.
And that, we can do, it's part "a" in my previous post. But that's more "realtime" type stuff, rather than static textures. And that takes quite a bit of development time to make something both lightweight and aesthetically pleasing.
What I meant was there are, say, 3 different textures, one for each pattern(the antique bus must have hippie flowers as one of them!!!) each patter will let you chose a color.(the hippie bus will paint the flowers!!!) yes, I know that you need 3 times the textures, but really, you could only load them on demand. since they are so small, you could still make it work probably EG: take the cent. one paint will be the standard one. another will have , say, hot rod flames. the last one will be racing stripes and a number on it for racing. If this won't work, then atleast let us change our color after we buy the ship, and make us pay a price proportional to the size. as always, different stations=different prices.
I really don't think this is worth it.
I may be biased because I run VO on an Eee PC, but why alienate players just so some people can have configurable ships? Honestly, you barely even see the ships, and even during a dogfight it is sometimes hard to get the colors of your enemy's ship.
With the advent of subnotebooks I am sure a lot of people will be playing with integrated video cards, which would *definitely* stutter and take a performance hit with this.
I may be biased because I run VO on an Eee PC, but why alienate players just so some people can have configurable ships? Honestly, you barely even see the ships, and even during a dogfight it is sometimes hard to get the colors of your enemy's ship.
With the advent of subnotebooks I am sure a lot of people will be playing with integrated video cards, which would *definitely* stutter and take a performance hit with this.
Wow, you seriously run the game on an Eee PC? That's impressive. I imagine the station interface doesn't work too well on the built-in screen, unless you have the newer 900 or better.
Not meaning to go off-topic. Pobega's use-case is a scenario where more overhead is a problem. On the other hand, for machine with really limited capabilities, we could offer a setting that forces the "first" configurable texture to be used for any given ship type. Basically, letting the user opt-out of seeing specially configured textures on other ships.
Of course, this would effectively mandate that the "alternate" textures not have any game relevance, beyond players "showing off" their different texture options to one another.
Not meaning to go off-topic. Pobega's use-case is a scenario where more overhead is a problem. On the other hand, for machine with really limited capabilities, we could offer a setting that forces the "first" configurable texture to be used for any given ship type. Basically, letting the user opt-out of seeing specially configured textures on other ships.
Of course, this would effectively mandate that the "alternate" textures not have any game relevance, beyond players "showing off" their different texture options to one another.
Kind of like gamer points, no actual importance but to say, "Ha ha! I have more!"
Actually, I'm running the Linux client on a completely customized Debian install. The station interface looks fine, and I even get a good 15 FPS there, as well as 12 FPS in combat. It's highly playable for NW and CtC, the only thing I can't do is Border Skirmish.
And it's an Eee 900, 16G model.
Also, an option to turn this off would DEFINITELY be needed. I'm sure in the next year you may see an influx on players running on subnotebooks, with the popularity beginning to sky rocket now.
And it's an Eee 900, 16G model.
Also, an option to turn this off would DEFINITELY be needed. I'm sure in the next year you may see an influx on players running on subnotebooks, with the popularity beginning to sky rocket now.
Ah yeah, the 900s all have the 1024x600 display, I think. The 700s with 800x480 would be a little more challenging (the minimum for our station interface is 800x600).
How does the game run in Latos M7, or Sol I13? We are going to be increasing asteroid densities in a lot of sectors, but as long as there's a variety of different sectors to choose from, I imagine it'll still be viable for sub-notebook players.
How does the game run in Latos M7, or Sol I13? We are going to be increasing asteroid densities in a lot of sectors, but as long as there's a variety of different sectors to choose from, I imagine it'll still be viable for sub-notebook players.
The game gets kinda jumpy in sectors with asteroids, but there are usually enough sectors to compensate. If you want to discuss playing VO on a low spec machine feel free to email me, I wouldn't mind testing all upcoming updates with my Eee to see how it runs on low specs.