Technical requirements

[Jan Zegers]

Hello,

As a student from the Netherlands, I noticed that the game can push to the limits of my computer, especially if I run the game in a higher visual setting. Are there any recommendations on the hardware requirements for playing the game. I see a lot of cool and advanced movies on the game, but I suspect these are not shot on home and garden PC's.

I would like to know of your experience. If you have experience with server requirements, I would be interested as well.

Thanks in advance,

Jan Zegers

 

[Cervator]

Hi @Jan Zegers

It is hard to post exact recommendations since it varies a lot on your graphic settings + modules enabled. With just the Core Gameplay and low graphic settings (especially view distance) any system that decently supports OpenGL 2.1 (I think) and Java 8 should have a chance to work. But if you turn up the view distance and other graphic settings then go start Throughout the Ages that might set even a beefy system on fire

The headless server is less problematic especially after some initial world has been generated. It does maintain a noticeable draw on CPU and memory even when idle though (not super well optimized yet)

 

[Jan Zegers]

Hello @Cervator and all the other contributors

Thank you for you quick respons to our questions. They were very helpful writing a particular subsection about deployment. We really liked working on and studying of Terasology. However, the project is going to an end and we are finalizing our report. During our study, we found a couple of points where a reply of the community would strengthen our report and let Terasology shine even more.

1. General overview of Terasology Architecture.
We described the Architecture of Terasology as an advanced modular architecture with a small engine and all the other content in modules. Do you agree on this idea? and what are the plans for the future. Are you keeping this Architecture? We followed the start of the discussion during the developers meeting, but we missed the end. An (in)formal stand or plan would be nice.

2. Technical debt.
During our study of the development of Terasology, we discovered from our point of view a considerable Technical debt. For example, low test coverage, low annotation/Javadoc, dependencies not always clear. Do you recognize this view? Are their plans to overcome this?

3. Jenkins report
Jenkins give to our opinion a lot of warnings when building. Has there been a choice to ignore these warnings? Are you planning to fix these warnings?

4. Active architect
The past weeks, we discovered there is a lot more activity then visible at our first view. Especially a lot of work is done in the different modules. Do you have lead or specific Architects for specific parts of the system?

We are looking forward to your response. We are happy with any answer of comment to our questions. We think that discussion improves the study and the project. Last weeks were a lot of fun, working with on Terasology and Architecture. I think more than one of us have got the Open-Source virus

Kind regards,

Jan Zegers
TU Delft

 

[Skaldarnar]

Heyo, I'll try to answer your questions from my point of view. @Cervator migth add some more detail or share a different opinion on some points

1. Yes, your view on our architecture is correct. Besides having (content) modules sorted out of the engine, we are working to factor out other core frameworks like the asset system or the entity system (https://github.com/MovingBlocks/gestalt).
2. I'd say to some degree this is a problem of being an all-volunteer project. A higher test coverage might help to discover breaking functionality in modules. Since we are a (relatively) small team there is not much time left for most of us to catch up someone else work. If nobody is actively using some parts of the code they might become stale and break. Putting the focus on gameplay and content development might help to overcome some of these issues as the current API is hardened and used by more and more developers.
3. I'm not sure which kind of warnings you mean. Many of the code style and inspection warnings are not critical - so the consensus is to "ignore" them until the code is touched for some other reasons. Occasionally new contributors start off by submitting PRs to fix warnings like these.
4. I'd say our main architect for the engine level is Immortius, although there are others who put a lot of work and knowledge into it. MarcinSc is currently working on "fork" (read: re-write of sorts) with some architectural changes. Devs like Josharias and Marcin have worked on larger gameplay modules and contributed changes to the engine where they emerged from the module work. All in all, we have "experts" for some of the departments (like Manu for 3d-wizardry), although these roles are not fixed in any way, nor are they "offical" or "exclusive".

I hope this helps you already. I hope to see you again with code contributions - as said: all-volunteer, all-freetime project

 

[Jan Zegers]

Hi @Skaldarnar ,

Thank you for your reply. It confirmed most we already guessed and gave some further insights on the project we can add to our report. I think you are right in your assessment that the checkstyle warnings are not critical. I was only curious because our professor does not let us commit if we add check style warnings.

Kind regards, even more because it is your all-freetime answer

Jan

 

[Skaldarnar]

Well, your professor might be right there Most PR reviews also have a look at checkstyle warnings and the like so that new warning cases can be avoided. Many warnings can be accounted the "technical dept", some are concious decisions, and others are false positives due to outdated rulesets (or configuration flaws). However, preventing new warnings from showing up does not reduce the overall number...