Building the cathedral - building the legacy - building a vision


Google Summer of Code 2017 will end in the next weeks and I would like to take the moment and share a project write up and maybe a vision from my personal point of view.

When I joined the project early 2016, GSOC was about to begin. It was the first year that our organization made it into this great program and we got three amazing projects, namely the dynamic cities, the DAG rendering pipeline and the NUI extraction and NUI editor. While writing this I note that my first contribution was an API overhaul for the behavior system - exactly the topic of a gsoc project I am now mentoring myself with @dkambersky as student :ninja:.
This lets me remember how much really happened in the last years. Many changes in the codebase and also on the wiki and documentation. Also so many new faces, especially with Google Code In 2016 - and many of them are sill around, like @smsunarto @jellysnake @Isaac or @MandarJ to name only a few.
With GSOC 2017 the activity has really exploded. Overall we have 10 students working on different projects and so many people are mentoring, collaborating and working together in different spots but for the same vision and project... its simply amazing.

In fact, this community is one of the best I could ever contribute to. I really want to say thanks to everyone who invests his spare time to drive the project forward. Especially to @Cervator who spends waaaay to much time and holds everything together and organized. Overall we have people from all over the world, working from different time zones *sigh :rolleyes:* and with totally different skill levels. We have pupils, students, hobby developers, or professionals from the it industry involved, all working together hand in hand while disregarding different levels in skill and education.

@manu3d once made the nice comparison that we are all building a cathedral - sort of. This is true in two ways:
First - we are building a huge architecture, an engine. No one will be able to understand every detail of it at once without spending countless hours of reading. All we can do is to put our own brick in the wall and take care of it.
Its a project where you can spend hours or days, adding a complicated feature or try out something totally new and crazy. Or you could just write a small module and make a little contribution with new content where others can build upon. Or you can start the game, enjoy the beautiful soundtrack, take a moment to watch over the cubic world, feel the moving grass and just relax. Even without as much content and polishing as minecraft, Terasology is already a unique project and will have its moments when played as a game :gooey:.

Now the second part when building the cathedral - we are also building a legacy for all to come after us.
Every line of code, every idea, every piece of architecture, it all may be used one day by someone else. It is the responsibility of every contributor to take care of the project. Otherwise we may produce a big piece of stones, glued together from different angles and no one will ever know how to add the rooftop to the cathedral :unsure:.
This is the second topic I want to cover in my summary: Legacy Code. Once a system grows and people change, the amount of code which no one understands may grow. As a community, we have to take this into account - we have to sensibilise ourselves and find a way to make it better.
At this time, the engine alone has more than 240k lines of java source code.
The total coverage of all ~560 engine tests is 19%, which means that our entire test suite does not even execute 1/5 of our code. Note that the word is executing, not validating.
Same goes for our architecture and developer documentation. The best pages on the wiki are 2-3 pages long and we don't cover all of our topics - not even close.
This means that someone new to the project will have to read through a lot of code when he wants to implement something new. Some places may be well covered by tutorials and API, others are in the dark, with monsters hiding in the shadows, waiting to eat the greedy developers flesh once he enters the deep caverns of ancient implementations. Also how can one making a change to the engine without the fear to break existing features or old concepts from previous contributors? - The answer is simple: you can't :notworthy:.

Now what can we do about it, what are we doing about it :cautious:?
The first thing everyone of the community can do - some are already is to take responsibility. A funny phrase is the "you touched it - now it is yours!". What does it mean? Does it mean we should not touch code because we will have to fight beasts in the dark without help, shivering in fear and wish we were back to our clean hometown in the plains? NOPE! It means "you touched it - you have permission to change it" :thumbsup: go on, make it better, change it, no one will ever blame you for your courage :notworthy:.

- See a bad class? Go on and take the courage to refactor it! Don't let it rot for another year and hope for someone else to come and clean up the mess!

- Find a feature without documentation? Go on, read the code, understand it, then write documentation for it, make it easier for the next one to come.

- Writing a new feature? Go on, write down your ideas and concepts. Someone may come after you and would like to understand what you did without reading your entire codebase. Maybe you will read it yourself when returning after 3 months of other business :whistle:

- Find 50 lines of uncommented code, ignored tests, empty javadoc or dead functions and you have no idea if someone else may ever need it? Go on, be brave and fight the monster! Delete it, rip it to pieces and bring the bones to the town in the plains. Good old git history will remember your braveness :cool: - plus the code base becomes a bit cleaner
Maybe you are even brave enough to add new tests :omg: wooo, the master dicipline.
Why not specify a new feature with tests, write some documentation for it and then contribute a brick that will hold the cathedral for ages to come?

So why not step up, watch out and see what else besides some new features in code are in your reach? Is there a spot where you can contribute? A spot where you can help others or a place where you can grow your own skills while helping others to improve? In the end thats what we will be - craftsman, teaching and learning from each other, stacking brick over brick while reaching for the skies :gooey:.

And this attitude - in my opinion - is what is the real meaning of being part of a community, part of a great project and what drives open source.
It is team responsibility, collaboration and honorable changes. It is also the courage to make mistakes but also the will to share them, the wish to learn from them and the desire for steady personal improvement while helping others improve.

These are also the first three ideas of software craftsmanship.
Don't build only working software but well crafted software.
Don't only respond to change but steadily add value.
Don't value only individuals and interactions but also a community of professionals.

I think this vision is what makes really great projects.
Sharing and establishing at least a bit of it would be the best thing I could ever contribute.

In this spirit: Go on - build the cathedral - all of it, every brick is yours!
Last edited:


The Bug Whisperer
It's really easy to get overwhelmed when there's so many things that need to be done. It can sometimes begin to feel hopeless or unfixable on a large scale. However, the important thing is to pick small individual problems and fix them consistently over time. Don't embark on massive documentation or refactoring passes, instead send a quick PR covering just a single class or even method. Many hands make light work.


Active Member
Great post @oniatus , thank you. I completely agree and I am doing my best, over the long term, to bring the renderer out of those caves full of monsters you mention. Thank you again.