Jump to content
SubSpace Forum Network

TurboSlug22

Member
  • Posts

    112
  • Joined

  • Last visited

Profile Information

  • Gender
    Male

TurboSlug22's Achievements

Newbie

Newbie (1/14)

  1. Hi guys, I was talking to Jowie about this earlier today... I just wanted to share my perspective on the topic... I have a lot of prior experience with a very successful MMO which used thin clients. The game was EvE online which has just one server with 30,000 - 50,000 people online (currently 47,000 people online, record max 63,000 people online) Its a space game in the same 'ballpark' as continuum - everything is commands based using buttons or commands mouse menus on screen. Combat works something like this: The 3rd person camera lets you rotate around your ship in 3d space, you double click on screen to set direction in space in xyz space and can click a throttle gauge to set your throttle % - You may then ctrl-click on an opponent in a list of radar objects and select "Target" - pressing F1,F2,F3,F4,F5,F6,F7,F8 activates gun batteries. You then can double click around in space to set your direction or select your opponent and set your preferred distance to keep at range or orbit radius to attempt to orbit your target at a certain range. Your ship responds with a very significant input lag to each instruction. Depending on the congestion, it can take anywhere from 1 second to 30 seconds+ for commands to register. In normal circumstances its on average about 1 second for commands to register. Your ship will not respond until the server does. In fleet battles (common) with 100 people per side, you can get 30 second input lag. At least, this was the case when I played, several years after eve's launch. Things may be better now... I dont know, I dont play anymore The reason for this is obviously due to there being 50,000 people online, however also consider that eve online handles their universe in chunks, there are/were several blade servers, each of which would handle a certain number of star systems. It was quite frequent that individual nodes (groups of star systems) would crash due to over-usage TLDR BOLDING: The biggest advantage an MMO using a continuum style client/server paradigm has vs a thin-client MMO is no-input lag/true real-time PVP. We'd really need to be sure that if ~450 people on a continuum server which was essentially handling the events of the game server-side would experience any slowdown due to a congestion scenario due to position/property/event updates in addition to database queries and updates from all those users concurrently In addition, for the zone we are working on, I would like to use a platform which does not impose any additional limitations on population size even if we all decide we don't need the large population ceiling that we might currently experience in player population levels. Oddly enough, I have to say I like the idea of having a council. I don't know much about how our council operates but in principal, I like the idea of having a group of people that works to maintain some generally agreed upon values in the community... a group of people that might help address major issues globally and work to resolve important issues of all kinds. I think that sort of group would promote the cohesiveness of the community and help integrate and promote aspects of the community. Id like to even see them doing PR stuff for the whole community, maybe not exclusively though.. Anyway thin clients have some great perks and I'd be willing to try it if we were sure there'd be no additional input lag - If I was playing an FPS like counterstrike, and I had even a small amount of input lag, it would really throw off my game. In a commands based game like EvE, its ok, because it takes time to use the cumbersome menu-based interface even for flying around so the input lag is less noticable but if you were playing counterstrike or subspace even, and you were trying to aim but there was 200 MS of input lag, you would line up your shot, let go of the movement and open fire, but your character would over aim due to the delay in registering that you'd let go of the key and you would be inclined to miss the target. Input delay of any amount that is perceivable by the brain (~30-50ms) will significantly affect the usability of a non-commands based interface. In my opinion, an interface suffering from even barely noticeable levels of input lag would aggravate the average user so we would need to be very careful here. What makes continuum cool is that your client tells the server where you're facing, which means the ship responds directly to your keyboard input. This is very rewarding and allows you LEVELS more control than EvE online offers, which is why dog fighting in continuum is so much more dramatic and lively
  2. ***UPDATE*** EverSpace reaches out to ModDB - Development picks up steam! http://www.moddb.com/forum/thread/devs-wanted-paid This should also put some attention on our community and bring some new players to the zone - ModDB is a very large community. Also remember that a significant portion of our community play many zones, so new players for EverSpace means new players for all our zones. Especially considering we've been making agreements to dump them on you anyway Stay tuned... We're almost there
  3. Regarding EXP- I can say that every 4 hours, (if a player has played within the last week) a player is awarded with a skill point. The player can choose what skill to allocate skill points to. Each skill has 5 levels of specialization. Each level of specialization requires a certain number of skill points to be invested in order to acquire that level. By example, lvl 1 in a certain skill may only require 1 or 2 points to achieve whereas level 5 may take 50 or 100 points. Each level in a skill gives a linear increase in capability/bonus (lvl1 5%, lvl5 25%) So, the player with the most exp is the player who has been awarded the most number of points to invest. I would say it would be easier to just allow the player with the most exp to be the freq captain who can approve/deny requests to join the frequency as well as kick players from the frequency (not to be confused with squad apps) Yes, kicked players are placed on their own freq I would say, players may only apply to one freq at once (less potential for glitches) When applying to a freq when another request is outstanding, they get a message like "you must wait X seconds to re-apply" The module should be able to sniff which squad the player is on - Jowie? Diagnostic arena messages is also something jowie or spider can answer..
  4. One of our Dev's had some questions about the way teams are controlled: ---- I have some questions about the freq manager module. The freq captain is supposed to be the player with the most exp. -How to read a player's exp? -What if 2 players have similar exp, and they keep alternating which has more as the game goes on? Should exp be checked only when a player changes freq? Kicked players are placed on their own freq? They can request to return to their original freq? Can a player try changing to multiple freqs (=N1, then =N2, etc)? Or do they have to wait for each request to be answered before trying to change to another freq? Do players need to be notified if their request / invitation expires? This would probably require using a timer? How can the module be notified if a player changes squads? How do you suggest debugging / testing? Sending diagnostic arena messages? Is there a way to get the interactive Python prompt on the server? Or is there a way to load the asss stuff in a normal python installation? I was planning to use I_CMDMAN, Ifreqman, CB_PLAYERACTION for player disconnects.
  5. I added this in another thread but it fits here too: ------ EverSpace will revitalize this community, guaranteed. We have a budget for external advertising, plus a very very well planned idea for exploding our population - more on that later... Since we expect to be drawing lots of new players from outside the community into our zone, we also have plans to take those players and spread them out among the community. Specifically, our zone will send a zone wide message similar to the following: "The top 3 players in kills in DSB after 3 hours will be awarded with 10,000 ES credits" This message is only sent to players in the EverSpace zone in an attempt to get them to play other zones. We will offer a similar service to all zones and ask nothing in return. Anyway, just trust me, EverSpace will be epic and it will revitalize this community in a BIG way
  6. Hello, What is everspace? 2 things Can we have an EverSpace section with a development subsection under zones here so we can coordinate our development? Second, EverSpace has several outstanding CASH bounties for ASSS modules as well as GFX development that we need completed. Join chat=EverSpace if you are interested. Again, we are paying via paypal for completion of several outstanding modules and gfx - we have already paid out $450 in dev bounties - hope to see you in chat=everspace
  7. While I've heard some criticisms, I really enjoy the upgrades system in HS. It really lends for some great gameplay dynamics... *Making the player feel like they can explore various item combinations. *The above increases the scarcity of money. *An exp system allows the joy of the game to unfold more steadily for the player by extending gameplay and giving the player more opportunities to spend more money in the meanwhile on other ships and etc thereby increasing player spending *Very decent items are some of the first upgrades unlocked, the rest are specialty items that typically come with a penalty players can build ships around I was talking with Spidernl - we were trying to think of a way to expand upon some of these nice aspects of upgrading and came up with some ideas that could be a lot of fun while still maintaining the desired gameplay dynamics in HS. What do you guys think about making your purchases tweaks to your ship instead of outright items? So players would be buying modules to install in their ship. The module could be a gun, or it could be an item that affects guns. Each module would be of a certain class. Modules that affect guns would be in one class, modules that affect energy would be in another class etc... Each ship would be allowed a certain number of each class of module. Here's the fun bit.. to make things interesting, each module also has an "Overhead" or an imaginary cost. So by example, we could say the warbird has "A 100 Mj powerplant" and each module would require a certain amount of power, so the player would have decide where to allocate this imaginary resource. Each ship would have a limit to the number of each class of module they could mount.. So, using the 100mj powerplant, the warbird could equip modules in each of its 3 gun slots, 3 structure slots, 2 engineering slots etc.. The beauty here is that we can achieve the same settings in HS now with much more items and variety for players to play with. Some ideas for modules: *Stock Guns (Factory grade guns like those in HS now)[Gun class item requiring high Powerplant so you cant mount 2 on small ships, mounting 2 on big ships = turret] *Gun class accessories (Heatsink for slightly increased rate of fire with penalty)(RamScoop for increased powerplant instead of gun bonus) Essentially we're taking the same upgrades, cutting them up into bits and pieces and letting players mix and match them on their ships more. We also get this whole new concept PowerPlant - and we can create a whole class of items that give bonuses to that... And again, just to be clear, that affects the quality of modules that you can fit on your ship - more powerplant, better item combos... Too many slots devoted to powerplant, ship loses in actual performance. Players can buy and sell to find the right balance. I dunno how close this is to spidernl's idea but we were talking about this earlier, hopefully he'll post his thoughts too but as far as manpower is concerned, spider says he'd like to make this idea happen. What do you guys think?
  8. Well, you wouldnt actually need a new client to allow the player to use bricks to tell the bot what they want for a base... The bot would just update the map file .. seems doable to me I'm glad you think my suggestions are cool anyway, I said lets leave manpower out of the equation because thats a whole other aspect of the discussion.. for now I just want to focus on the quality of the ideas...
  9. One thing I really like about HS is how the upgrades stay with you after you die... Its like the investments you make in the game are tangible. That's a good spirit for a zone to have. What I was shooting for here was a way to give players ownership over some part of the map.. some way that they can invest into the game and carve out something more for themselves than just a ship - but something that parallel's the zone's gameplay so as not to unbalance it. In Eve online, players can build their own starbases with sentry guns, mining outposts, warp points, shields... a complete base that they need to defend from attack HS is a basing game where the goal is to reach the core of a base and hold it against enemy attack. So if we give players the ability to exchange time played online (what we want) for the ability to design their own base - why not? OK, so you cant use bricks to make bases in pub... No destructible walls..:\ What if you could allow the player to create the base alone in a private arena using bricks as a way to tell the bot what you want in your map. The player could design their base and the bot would check to make sure there's a good path to reach the FR. If the player accepts the final bill, section 8 in the map is updated with their base but not published to pub yet (since this requires recycle) Here's the fun bit, when the zone dies out for the night and nobody is playing, the server can automatically update the pub map and the zone is refreshed with new content 2 new bases in sector 8 (one for each team) for the remainder of the day. (so there's room for 2 purchases per day... Dont queue up purchases, just make it so the first 2 people online after reset can buy - the incentive here is to BE online at reset, to boost population during slow times) I think, having turrets to defend a base adds an interesting level to the game, since, while alive, those turrets will generate money for the owner online or not. This is a desirable thing for players to achieve obviously, however, considering turrets and bases are very expensive, the amount of money they generate for a player isn't such a big deal The idea being, the most expensive items in the game can only be afforded this way... As a player, when you siege a base in HS, you want the JP. You want the reward for destroying the base. (and i guess, holding the flags) So if you could destroy turrets and the entire team was awarded $ for destroying it - that'd be cool In regard to purchasing turrets, you could have different settings for turret AI's (costing different amounts) turrets that aim in 1 direction and fire when an enemy crosses a certain zone (good for inside bases and cheap) - or turrets that aim directly at nearby enemies and fire (Good for perimeter defenses) etc etc.. -- Lets please just consider the idea without bringing manpower into the equation What do you think?
  10. Can you say a little more about that? I mean, you're right, I was assuming but still, I'd considered that there would be challenges along the way, just like anything else but also I think that there are ways to overcome them... Whats involved with getting an app affiliated with ubuntu?
  11. I just thought I'd come back with an actual solution before I'm called out for being a whiner with no solutions lol... I've looked at some business models for some other very successful MMO's ... HS having very similar things in common with MMO's (grinding for cash/exp/items, sieging etc) so i think its not outlandish to consider their approaches to keeping their players feeling rewarded in such a way that motivates them to play the game how the developers see fit. In HS's case - I can honestly say I truly see an entire world of opportunities that expand upon the zone without removing from the basing game that is the soul of the zone right now. Essentially, see my other post: http://www.ssforum.net/index.php?showtopic=24645 It may require an open source client to achieve, but even that would be a huge boon for continuum, i mean, if we made a linux distro, we could get it posted to Ubuntu's package management system and we'd have a whole flood of new players Anyway... Just thought I'd answer my own post :\ What do you guys think?
  12. QFT The "clear" lack of interest being the RQ'ing i assume.. Anyway, yes, its a big issue.. the zone would be healthier if players who were done playing could leave at a random time, and not at the same time, all from the same team. If players left one at a time, the situation where an entire freq quits and the enemy team is sitting there with nothing to do is less likely to occur. So I thought about it and tried to get inside the heads of ppl who RQ - they typically leave when the team feels like they've lost out on the JP (even though the losing team gets a pretty decent jp anyway) when they thought they had a chance at it. Its interesting because if the team feels that theyre bound to lose from the start, they dont RQ, they aim for the losing bonus and are happy with that. So, if a team has 12 flags and is holding the FR and they lose control of the FR, this is prime-time for RQ. As a developer I'm looking at what gameplay dynamic creates this behavior and on the other hand, why its a desired dynamic. I see that the idea of the game is to carry flags to the FR, and hold the FR long enough to win the flag game but the whole notion of a losing team is psyching people out I think... I mean, if you removed the JP completely (im not saying you should do this because you need some kind of incentive to make basing the ideal strategy) but what incentive would players have to RQ all at the same time if there was no jp? They earn money constantly from kills... I think a big part of the solution here is looking at the reward system and how it induces RQing - what's needed is a reward system that promotes basing behavior but doesn't induce RQing -- A team shuffle after each round wouldn't hurt either Thoughts?
  13. Hm that sucks well it was a fun idea No luck working around that with laser doors i guess?
  14. In HS, I see 2 things that are hurting the zone right now.. first is that players will RQ if they lose faith in their team. Second is the zone is quite challenging for new players.. Ive been thinking about ways to expand the gameplay without actually changing the the way the players play the game. Please hear me out: I think adding new things to buy is a great way to keep players interested in upgrading and buying things.. the more things to spend money on, the more time players will spend playing to earn money. So imagine if sector 8 (where scrap and salvage is located) Was cut in half, and half of it was left open and empty except for a powerball goal tile. Imagine if players could spend money to buy a base! - the bot would award them 50 bricks (or enough to build a base) and the player could lay bricks one at a time to build the walls of the base. Players can do ?undo to remove a placed brick Bricks would be bot controlled. Bricks would be on their own frequency so they act like regular walls. Here's the cool part, you can give them HP! so you have to repair your base etc Say for instance you could also buy turrets... which are like point defense guns that dont move but have much lower HP. Say, each team has a designated area where they can build at.. This way, you could allow the player to actually build their own destructible base. Similarly to how regular items are regulated by the EXP bar, you could limit base expansion to powerball goals - so like, 5 goals lets you buy a certain number of bricks and turrets... (10 bricks per goal and every 5 goals you get a turret) ... My thinking here is that powerballing is like mining - you haul resources back to the base and you get to spend money to convert those resources into base building components... This way, New players can be quite effective to help their team by scoring power ball goals - and also ppl who are left alone on their freq after their team RQ's can still be effective vs a large enemy team if they want to spend some money... BUT if they do not get a continued supply of powerballs from the center, they cannot repair their base even if they have lots of money. This makes blockading possible and effective. Thoughts? EDIT: To counteract teammates who grief by laying bricks in strategically bad places, you can select bricks and type ?vote (or something) to have it removed if enough players agree
  15. @Xog Thats a great writeup about the game... but we dont want to submit information about the game to slashdot - we want to submit a story the readers can chew on and go *Hummm* And think about the meta-ethics involved.. the big picture.. something..... controvercial even Something like "What makes a game last?" And then talk about continuum Or... after 15 years who truly owns a game? and discuss our plight and how copyrights affects us.. (Copyright is big topic on /.) Or... talk about the evolution of MMO's and where they all started (here) Or... talk about network latency compensation and how our client/server software was revolutionary for its time and what that means for games these days.. We just need to write a story worth telling that only we could tell ------- @others Please dont over-estimate /. and how hard it would be to get a story posted there, I dont think it would be hard at all. Just look at some of the stories on there already... a lot if it is already heresay and conjecture anyway. It seems to me our story would fit right in among the others. I mean, so many of their articles are like "Bob writes to tell us that company X is doing action Y" So like... cant we just say "We suceeded from our parent company a decade ago and look at us now" We just need a news-worthy story relating to continuum. Even if its talking about how we've stayed afloat under our own steam for so long. Thats a story that would be inspirational in these times and would be well received
×
×
  • Create New...