I am usually not one to complain on things as I am a patient person and know that things will get worked on when it comes to mmos. However, only giving 2 (3 once you hit lvl 6) character slots seems really cheap to me. You don't even have enough to do one of each available "class". This has probably been posted before but I am no going to search through the forums for it. Basically there should be more character slots, why they are so few is beyond me. Its just really cheesy that there is 3 total. (unless you get yearly or lifetime and probably c-store when its updated)
As for ships having only 1 ship type per op (Tact, Sci,Eng) also a little cheesy. there are more than enough ships in the Star Trek Universe to allow 2-3 per level no problem plus its 30 years late so you can make some up

I have posted something similar before on ships but never seen a dev address this.
Comments
But what can ya do..... /shrug.
I would hope that - like the character slots thing - there's a valid reason for introducing the skill cap.
Sorry but that is a bunch of bull. Storage solutions are so cheap and fast now. Bottom line is they want to charge people $$ down the road for each extra slot they get.
They make it sound like like BO's have inventories, lots of equipment slots, huge spell/skill lists.
There are many games out there that your Character alone has more equipment slots that all your BO's combined. With Inventories 3-4 times the size of STO's. Sorry, but this limited space due to Character size is bunk.
I dont think he meant the physical storage...he meant the database size...and very large databases tend to crash..there are also limitations in the software...dunno what STO uses..sql, oracle...somethingselfwritten. And a large and full database is verry slow...even on really good server systems....
theoretical it often sounds easy...but practical its a pain int the....
While I cannot claim to truely know how Cryptic has designed their data structures for characters, I do feel they're rather BSing us in it's complexity.
For characters, we have, maybe, 20 pulldown options (combining physical features and clothing options). These can be handled by a simple index value, and, given the number of choices we have available, those index values need only 4bits (half a byte, and 1 byte holds the data for a single text character). 4bits can give you 15 option index values.
Colors are also indexed. While a full fleged RGB color picker (like in photoshop) would need 3 bytes for any color in the computer's color spectrum, STO gives us... what? Perhaps 20 or 30 choices? Again... a simple 1byte index can hold the color information needed.
The rest of the character creation is slider values. They are NOT storing the model data. They are storing slider values to morph points on their single model. At worst, that's a 4 byte float (or 8 byte double) number over a total of, again, no more than 20 sliders.
So... I'd guess that character data can be represented by a sum total of...
20 pulldowns * 4 bits = 10 bytes
10 color options * 1 byte = 10 bytes
(high side) 30 sliders * 8 bytes (aka double) = 24 bytes
Total: 44 bytes
44 Bytes is equal to a 44 character long post. You send more data via twittering!
Models are not stored, they are loaded locally by your system and using the index/color/slider values, morphed into your character+BOs
Assuming you can have a max of 10 BOs at any given time, that's 484 bytes for character + BO data.
Ships are even simpler. 3 parts to choose from over 4 differ ship sections. Again, 4 bits could be used for those index values. That's a total of 2 bytes to choose how your ship looks. (BTW, with 4 bits for an index value for your ship parts, as it stands, Cryptic would still have 12 part, per ship section (or 48 parts total), they could add before reaching the max index value of 4 bits).
Colors, again, are indexed colors and we only have 2 colors we need to worry about for a ship. That's 2 bytes.
Add windows (4 bits), bridge (4bits), and color pattern per ship section (1 byte * 4 sections).
Total for the ship: 9 bytes of data
Ok... you can have more than one ship, but still... it's ONLY 9 bytes. You could have 53 ships before equaling the amount of data needed for your character and BOs combined.
They're limiting our registry number options, so that suggests they're storing the registry as a single numerical value (as opposed to a string of characters). That's no more than 4 bytes at MOST (and 4 bytes is probably overkill)
The longest bit of data would come from the name of your ship. If they max the size of the name to, say, 24 characters long, then the name of the ship is 24 bytes.
All inventory (in your inventory/bank/ship components/equipped on your BOs) is just a series of indexes of items (lots of items, so I'll give them 4 bytes for an item index) * stack count (1 byte MAX) and some reference links (what item is equipped in what slot).
At absolute worst, I cannot see character slots (BOs/Ships included) taking more than 2 megabytes (2 million bytes) at MOST. There are 1000 megabytes in a gigabyte and these servers HAVE to have storage in the Terabyte range!
I wont even bother with skills, and none of this is really taking into considerations the ability to leave room for future expansions... but the point is, if done right, you can store an amazing amount of information in an incredibly small space. Remember, they aren't storing the whole model of ever character (including BOs) or the ships. They aren't storing the textures. They're only storing simple and limited morphologies, color information, and strait up numerical data (for skills, ranks, equipment and their assignments). That's a pittance of data to a computer.
That being said, STO is their game. They'll either keep up that line of reasoning, or cave in a few months/years and give us more slots (claiming charity to their loyal fans).
But anyway...everyone has its own opinion. Believe what you like best.
Without knowing any specifics about that binary data, there is no way you can make any reasonable assertion as to the size of a single player character in their data model.
44 bits would be 44 characters 44 bytes is 352 characters which isn't much but you also over simplified the information they have to keep track of. you may not have thought about this but there are hundreds of thousands of combination of looks all options need to be kept track of individually in a database and while sure you could make a master list that assigns each option a a cute little 4bit long identifier like your eye shape being e123 and your head size being h254 and your forehead being f125 then every time your character is rendered not only will it have to query your character from the database but also have to run query's for each of the options for that character, now this may not seem to be a problem to you but what happens when 200,000 people do it all at once. would you rather have the database grind to a halt or it simply read your character from the database not have to look anywhere else and move on so its only 1 query for the 200,000 characters instead of 2million. now as for is that how it's being run, I don't know. but the simple fact is, they say there is a ton of data to be cataloged and i see there is, being a network engineer with 10 years in the business, i bet they could come up with a more efficient way to store data than they are using (there always is) however more efficient for storage is not always more efficient to read from.
The simple fact they are planing on offering more slots in the future, the fact they allowed Life time subs to have extra characters just shows they can allow people to have extra characters and are just want the extra 5-10 bucks per slot they will charge people.
A bit (1 or 0) IS binary. Text, index values, numerical data... in the end, that's all binary. 4 bits can hold a numerical value of up to 15, and that numberical value can be used for anything from indexing information to applying it to a morphology (converting that 4 bits of data, using a runtime algorithm, into a larger float point, 4 byte bit of data). It's simple data manipulation.
Cryptic would be nuts to store their model data for every character. It's a waste of space. They have a single model which is mathmatically/algorithmicly modified using the slider values. The details are handled via a lot of fancy graphical mathmatics... none of which needs to be stored. It's all generated at runtime. When you're character loads, the single model is loaded, morphed, skinned, and textured based off the index values for these morphologies your chose when you created the character, then stored in memory while the game runs. Only the morphologies need to be stored.
Easy way to picture this is WoW... There are skins that you can download to change the way your character looks (nude skins are well known). But, while you (the one using the skin) can see it while you are playing, all others cannot. This is because you've replaced a local texture on your computer, not on the server side. Server doesn't care, because it doesn't need to know what the texture looks like; all it needs is the textures index value.
Now, let's talk about your rank. There are roughly 50 levels in the game. Your level can be stored with only 6 bits with room to spare (in fact, we can store your level number up to level 63 with 6 bits)! The system doesn't need to store if you're a Lt, or Commander because that could be identified at runtime just by looking at your level.
If (lvl >= 11 and lvl <= 20){
rank_name = "Lieutenant Commander"
}
You only need to have a variable for skill points available (maybe 4 to 8 bytes) because the total spent could easily be calculated at run time by taking your skill levels (which max out at 9 for any given skill at any given rank) and multiplying them by their cost at their rank level (Lt skills cost 100 a piece, so, Starship Command, at level 9, means 900 skill points, while the LtC Science skill, at level 9, is 1800). Add all of those up and you have your total spent points. Take total spent and add total available and you have your total earned skill points. Generating total spend skill points only takes the computer milliseconds. Multiplication operations for a computer are cheap (one cycle, over a current CPUs billions of cycles a second) and there are only 100s of skills. BTW, a skill with a maximum value of 9 needs only 4 bits to store the value. So, assuming STO has 100 skills available, you only need 50 bytes to store skill data.
Of course, you're right. I do NOT know how cryptic is handling their data, truthfully. I'm merely making educated guesses on how they are doing it based off my 10+ years as a programmer. Perhaps skill information isn't stored in only 50 bytes. Perhaps they gave it 300 bytes for reasons I am not privy to. My point is, simply, that knowing computers and programing as I do, and seeing the information available to us that I have seen while playing the game, it feels very off to me that they claim the data is huge compared to so many other MMOs.
Without wishing to appear rude, if this is the case, why is it that you appear to persistantly ignore or gloss over the issue of binary serialization? I'll admit, I've only been in software engineering for about 5 years, having spent 10 years in IT management prior to that, but serializing data objects is an integral part of modern application design, and accounts for the majority - in terms of size - of the data we send to and from the database.
No, a single (ASCII) character is stored in a single BYTE (8 bits) which allows for 256 characters. Truth be told, STO is probably using unicode characters which, if member serves, is 2 bytes. Unicode allows for the non-latin languaged (japan, china, etc) to store their characters in the same structure. Unicode is used when you're planning for internationalization.
Eye "shape" is a SLIDER value, not a drop-down option. Slider values, I said, would most logically need a 4 byte float, or 8 byte double (both a double and a float allow for numbers such as 1.1234) Most likely, though, it's be a 4 byte float which would easily allow for a value from 0.0 to 1.0 (inclusively) which could them be multiplied by a maximum value to get the real size of the eye. Do this for every slider value (eye size, mouth width, lip fullness, leg length, cheat size, etc, etc).
4 bit indexes (though, most likely 1 byte indexes) would be used for the drop-down options such as "Denobulan ears, gradient skin, eye piece, etc, etc). This is because you have a finite number of options for them. You only have 3 options for eye pieces, for instance (None, Visor, HUD). There's no variation with those (yes, they have colors, but that doesn't change their model) nor can you add your own to that list (If you could, you'd be using something quite different than simple index values. You'd probably use model path infromation, which is a string and could be up to or even over 256 characters (bytes) long)
You make a mistake like this and expect us to take you seriously?
True, they could definitly be serializing, but, unless they're doing something completely strange, the process of serialization shouldn't increase the size of of the data stored locally on the computer. Transmitting it to the client would make it, bit for bit, larger (wrapping it in network protocols), but, in that case, you still want your data as small as possible to transmit as quickly as possible. That is, of course, one of the major reasons for serialization too... the transport of the data.
And all this is completely ignoring the various challenges in maintaining a performant (I hate that non-word!) relational database, which are themselves not trivial.
LOL... Awww... my whole argument falls apart because I forgot the zero at the end? My appologies. Let me rephrase...
(high side) 30 sliders * 8 bytes (aka double) = 240 bytes
Making the Total, 260 bytes per character (as in avatar/toon)
Meaning, if you're allowed a max of 10 BOs, then you'd need 2860 bytes, or 2.8 kilobytes to store your character's physical information along with that of your BOs. Quite a large size increase, but still nothing to a computer. If 10 physical avatars can be stored in 2.6 kilobytes of data, you can still store (rounding up to 3k per 10 avatars) 341 characters in a megabyte (based on 1024k per 1meg, and thats physical information only). 341000 in a gigabyte
If you dedicated an entire harddrive, like you get in an average computer (250gig), you can store 85333333 characters' physical data on that drive. Assume the rest of the data (skills, levels, inventory, etc, etc) requires 3 times the amount of data as the physical data alone, and you can store 28444444 complete characters (inventory and all)
Except even your 260 bytes is so far off it's ludicrous. It's clear you know the theory, but nothing about how these things work in the wild.
I can see where ObsidianBlk is coming from, but, frankly, I find his back-of-a-cigarette-packet figures about as unconvincing as he seems to find data serialization.
Enough masochism for one day, I think.
Yes, as I have admitted, I do not know how they are really storing their data, but my evaluation comes from educated guesses based on my experience with data manipulation.
Also, you're quite right. In a huge production like an MMO, managing a relational database (assuming their database is, indeed, relational), is non-trivial... but the complexities of managing the system only quite nominally relate to the size of the data per account being stored (physical data storage and data for the database indexes between tables and other sub-databases). Per account, I would be surprised at more than 500k of data on the database side for an entire account. Though, I will admit I have never used a database (again, relational or otherwise) in an environment expecting anywhere near as many connections and entries as would be required by a production level A+ MMO as STO
Mission completion
Accolades
Captain Logs
Inventory
skills
bridge officers