And this is precisely the point, and the cause of a lot of language arguments, IMHO. What software 'should' look like is very dependent on whether it is a team or an individual working on it, if it needs to be used over the short or long term, (can't be bothered listing more but there are more).
Programming experiences
Collapse
X
-
For me one of the biggest benefits of OOP is better context-aware tab-completion in your IDE, and the ability to just type "object." to bring up an object's capabilities without having to refer to the documentation Seriously... that alone saves me SO much time.
OOP is also convenient when you need to quickly describe the architecture of a program to another developer. A picture is worth a thousand words they say, and an old-fashioned class diagram can be quite instructive. A good IDE can even auto-generate some diagrams for you. Sure, you can diagram function calls and stuff without OOP... but IMO it's not as easy to digest that way. I am, of course, biased.
Encapsulation should be done with or without OOP; OOP is just a nice way to abstract it.
You've got polymorphism, too - sometimes that's convenient, but sometimes not. It's just syntactic sugar for function pointers. You'll notice that most OOP language still provide a way to use function pointers even without polymorphism. Java has interfaces, C# has interfaces and delegates, etc...Comment
-
Debugging is time consuming and mentally demanding. Much more than the coding step.
I think an important factor of choosing a language is to choose one where it's less likely to make bugs. This depends on the programmer (different people think differently and make different sorts of mistakes) and the language (some languages just have more traps and pitfalls for the unwary than others).
C++ was and still is a language in which I make fairly many mistakes and also it is harder to debug than many other languages. If you choose C++, you should be aware that it is a very powerful tool, but a difficult one, and one where programming mistakes can be quite hard to track down and fix.I have a project problem? I have no project problem. I start a project, I work on it, it fails. No problemComment
-
Realistically these days there's only two reasons to use custom binary file formats:
1) You want it to take an extra two hours for the hackers to figure out how to modify your savefiles / the idea of people being able to easily modify your game fills you with shame and horror.
2) You're writing a program for older mobile devices that don't have the storage/processing power to effectively make use of text formats.Comment
-
Realistically these days there's only two reasons to use custom binary file formats:
1) You want it to take an extra two hours for the hackers to figure out how to modify your savefiles / the idea of people being able to easily modify your game fills you with shame and horror.
2) You're writing a program for older mobile devices that don't have the storage/processing power to effectively make use of text formats.Glaurung, Father of the Dragons says, 'You cannot avoid the ballyhack.'Comment
-
Realistically these days there's only two reasons to use custom binary file formats:
1) You want it to take an extra two hours for the hackers to figure out how to modify your savefiles / the idea of people being able to easily modify your game fills you with shame and horror.
2) You're writing a program for older mobile devices that don't have the storage/processing power to effectively make use of text formats.
But anyway, yes agree to generally use a txt/xml/yaml/json format, and I'd even go so far as to say that if you have speed enough, don't use C or the like, but an interpreted language (Python/Perl/choose your preferred poison).Comment
-
However, I suspect that MMO saves are stored in databases instead of flat files, since there must be all sorts of juicy analytics that the game developers will want to be able to run.Comment
-
We store many items (non game related) in, for example ASN.1 formats, which tends to be highly efficient (and easily readable again if needed).
The smaller items/larger numbers stuff indeed goes into clustered databases, but keep in mind that for companies wanting to keep data for longer periods, even one byte saved means massive savings (not only storage, but also transport).Comment
-
Then you use compressed text. zlib is not hard to work with and will get you similar space savings as a custom binary format would. Heck, we have a custom binary format at work (I didn't choose to use it!) and compressing it gets us a 50% reduction in file size simply because it's not well-designed for space saving (it contains a lot of raw image data).
Code:<item><name>The Phial of Galadriel</name><bonus type="searching">+1</bonus><bonus type="light radius">3</bonus></item>
--
Dive fast, die young, leave a high-CHA corpse.Comment
-
I dunno about Angband, but Pyrel will most likely be using plaintext JSON for savefiles. I'd guess (completely blind) they'll probably end up in the 50kB range, which is not exactly going to break anyone's hard drive.Comment
Comment