The game engine just seems wasteful and inefficient

CPUs are really designed for logical operations and integer calculation. In fact what does most of the math, especially floating point math in CPUs didn't even start out as part of the CPU. You used to have have a chip independent of your CPU to do all that. Now they are all integrated into modern CPUs but keep in mind that CPUs still suck at calculations. That's why there's all these PhysX, CUDA, GPU acceleration stuff. Mostly just because GPUs are MUCH faster at floating point calculations, but usually harder to program for.

However as a programmer, it is tempting to just always use floating point. because it can handle negative and positive number with a huge range. And it is easy to tell when a programmer has been lazy just spamming it everywhere and not care about execution performance, all because of this explosion in hardware performance in the past few decades.

• Player health and energy are in Double precision float, that's a range between PLUS OR MINUS to the POWER of 1000 Yes, one THOUSAND. The same is true for other monsters. Why is this needed? why can't they just be 4 bit integer? is 4 billion not big enough for your lv.10 boss? Well then how about give it multiple health bars like old arcade games? Instead of doing this slow floating point thing for EVERY MONSTER?
• that same value is then converted multiple times between single and double precision while the game runs and while treating damages and save files. I mean if you're gonna use single precision at some point, what's the point of having double precision? Wouldn't it just bottleneck?
• Your ship's fuel is converted into floating point in order to calculate the length of that bar on the starchart or fuel panel. Do we really need that much precision? Like would anybody be bothered if their fuel is 500.3 and the bar isn't SLIGHTLY longer than half? Oh yea I'm sorry, you CAN'T HAVE decimal fuel values! NEVER MIND!
• weapon damage, and fire time are also stored in double precision floating point. But the weapon tool tip shows them in integer, which obviously requires some computation and conversion. But then the character panel shows the value in what seems to be half precision floating point. yet another separate conversion and computation. Again, is this necessary?
• the game engine itself is just incredibly serial and not optimized for multi-core CPUs everybody uses today. Most obvious example is when you click connect in Multiplayer and the server doesn't respond, the game will freeze until it times out. Why can't that be on a separate thread? The same can be seen when you have a really big recepie list. The game will freeze when you open your craft menu, and when you do searches. The search algorithm is bad and buggy yes but it should be on a separate thread so it doesn't clog up the game thread while you're doing searches?
• many of the static values in game are constantly updated and calculated, like current zoom level, your health and energy even when at max.
• Your breath and warmth level are ALSO in floating point! PLEASE IT DOESN'T HAVE TO BE THAT PRECISE!
• many values and information needed by the game appear multiple times as identical copies in the memory. Things like current health/energy, player name, player UUID, item name and their information... etc... A game like this should not take more than 500mb of memory if properly optimized.

Do not reply with the following response:

• It's in beta and it will be optimized

I know it is, and this isn't a problem with optimization . the engine is designed with these flaws and you cant fix them easily.

• It runs fine for me

It's a bad habit to be wasteful regardless of whether or not you have the performance to run all the junk code. Besides, most people do not, it gets really choppy with just a few thousands sprites on screen.

 

Can I reply with "I understood some of these words"?

 

you just called the programmers lazy and claim to know better than they how the game should be developed. why dont you apply to work for chucklefish then wiseguy?

 

because it is easier to criticize than to do it yourself.

 

It is still beta. They already said there is much to be optimized. Also, it doesn't really matter to use double or floating or even integer, as todays cpu are more than good enough to handle all this. If you are experiencing high cpu load it is mostly due to graphics being rendered on the cpu (it's common to do this in the early stage of a game).

And yes, it IS A BETA - BETA BETA BETA!

 

I donno, I agree with the guy, regardless of the tone of the post.

I don't know much about programming, but he supplies relevant information and the reasons why they're a problem. An A+ in my book, I don't need him to whisper sweet nothings while he does it.

 

the game is fully open to modding. give it a shot.

 

Modding doesn't seem to allow you to change the core game code on the levels implied.

Edit: I wonder if this explains why memory is used so much on servers.

 

Very interesting points. I think Minecraft and Terraria also suffer from some of these problems. I'm only a hobbyist programmer so I don't know all the technicalities of the code, but I can definitely see your point. I know you aren't trying to bash the coders either.
However, I'd suggest you bring these observations up in a more laid back manner. The people who don't understand what you are talking about will ignore you.
My question would be, how did you find out what variables were being used to store this information? Is it in a log file or something?
I also would challenge that you say it's "lazy" programming. You and I both know that mistakes are easily made staring at black text on a white screen for hours trying to make a program do something for you.
Maybe what started out as a str_playername turned into a flt_playername(to.string) after they were debugging some of the code. What do you think?

 

My only issue, I don't really know what General Discussion is going to do with this. Most of us like myself don't have that deep of a concept of programming. Those that do can only add speculation to what you've found. This should probably just be emailed to the devs.

 

theyll get wind of it so long as people keep bumping the thread, but if op is really determined to be heard then there are more appropriate channels.

 

I understand that this is feedback, however, we're in a forum and in forums people discuss ideas and their own experiences (good or bad ones), if possible in terms that makes it possible for everyone to understand so we can avoid miscommunications and misinterpretations. The complex programmer language doesn't do anyone a favor unless they are in the same area as yourself. It looks to me that you wrote this just for the game developers, so they would read and do something about it and if that's the case, then you would have been better off just sending this to them, privately.

 

I agree with the first post, but at the same time I must wonder if the extra precision really maters that much with the examples he gave. The bigger question is if this kind of stuff is happening with more complex things that have a bigger impact on how the game runs. Stuff that is used in calculation many many times per frame.

 

Can your replies get any more useless and rude?

 

I think there are enough people in the forums who understand his text enough to justify the thread. I'm also fine with the idea that not every thread is meant for every forums member.

 

Hey it's not because he says something is wrong that it is only right to attempt to spit on his face. Beta needs people like him. Also on the 'handy' nature the OP is right.

 

Also a programmer here, although I'm not very good and I disagree (mostly) due to several points:

1. Double-precision and single-precision floating point numbers and their variations are the only types of numbers that can handle non-integer values such as 1/2. Clearly in many situations a fractional number would both be used and valid.
2. Simply put, Integral values are limiting. Unless you know for an absolute fact fractional numbers will never be used or valid or accept the fact that Double-to-Integer conversion rounds (or truncates, I don't remember off the top of my head), you should use Single or Double.
3. Double and single precision floating point numbers are easy to swap later via changing the property's data type. They are essentially the Long and Integer values of the non-integral world and, like Long into Integer, The only issue with converting Double into Single are overflow errors, which basically says "You should be using Double for this".
4. Converting a floating point decimal into any of the standard numerical data types (Single, Integer, etc.) requires very, very, very little computation power and happens automatically if the target variable's data type isn't Double in most, if not all, programming languages.
5. Static values are not Constant values. Static simply means that the data is not reset after the method ends, instead, the data remains until the parent class, module, or program is unloaded. Thus you can have values that can be something other than the default value when the method starts. It's a common and accepted practice to use Static values in place of Class or Module-level properties that would only be used in one method.
6. In many cases, decimal values are the most common values, especially for time-sensitive objects such as breath or warmth since time is measured in milliseconds, not seconds.
7. Double is the only numerical data type with support for a Not-a-Number value. This is especially handy for cases where positive and negative are valid but also may not be applicable in some cases.
8. Some of your points, such as multiple copies of the same value and not optimized for multicore, I have no choice but to say: IT'S BETA! Optimization is one of the last steps of development, and seeing how much of the game is in flux at the moment, they haven't reached that point. Also, in the case of multiple copies of the value: unless the value is then saved to the in-memory value in all possible cases, this should be the case. You told me not to say it, but I'm saying it as that is the sole reason it's "incredibly serial and not optimized for multi-core CPUs".

I agree with you however on one point: the data types should not be converted willy-nilly, but instead only when absolutely needed. There's no need to convert Double into Single and there's no point to converting it the opposite way or from an integer. In some cases, this is acceptable, such as when a method returns an integral value which should be stored as a double, but in all of these cases the conversion should happen automatically. There shouldn't be an instance where data type matters immensely either, it's just bad coding (ie. a pair of same-named functions, one needing a Double parameter and one needing a Single parameter, both with vastly different contents).

 

Eliminating all the floating points you listed would do jack squat, there aren't nearly enough of them that converting from floats to ints would have a noticeable impact. This isn't the 1990s, memory is cheap and a few dozen floats that could be stored as ints is not going to have a meaningful impact. The engine is also packed full of debugging code, which is a major cause of slowdowns. Optimizing the way lighting works and how blocks are handled, unrolling loops and such will be infinitely more effective than converting the player's stats from floats to ints.

 

Your point about optimization is spot on and very important to consider when making a game of this scope. While you do make good arguments for some of the variable types, I’d have to disagree with the premise that floats are somehow inherently evil (no you didn’t say that directly, but it does seem to be the general heading of your argument.) Floats are incredibly useful, not just for precision but for percentages and smooth transitions.


In basic theory, you could store health in a simple integer and leave it at that. The problem is that anything that could possibly modify health would also have to be an integer or convert itself to an integer before finishing the calculation. In situations with status effects/armor calculations/etc, the value is not always as clean as a simple number.


Your point about the weapon damage/attack speed is a bit confusing, as I haven’t witnessed the number of different places you see these numbers being displayed. For swing speed, it’s absolutely understandable that it be stored as a float since many have values less than 1. As far as displaying it differently, that may be a consistency issue but shouldn’t affect the game speed-wise in any measurable form. Converting a float to an int is a simple, non-taxing function.


I do very much agree with you on the rate at which things are updated. Event driven functions are much more efficient than constantly polling values, especially when those values go unchanging for a given amount of time (such as max health/energy/etc). That is a somewhat simple thing to fix and I’m sure they will toward the end.


At any rate, I hope you’ve at least given the devs something to think about, which is always a plus.

 

I agree with everything you said except this:

This is wrong, an optimization phase is exactly the time and place where these things would be fixed, if necessary. Why would you think they can't be fixed easily, or that "easy" is even a requirement for optimization?