≡

Google Summer of Code Wrap Up

Posted by Isaac Lichter on August 27, 2020

Summary

This summer, I worked on transferring Destination: Sol from the Object-Oriented Programming model to Entity-Component-System (ECS) architecture. In ECS architecture, new behavior is added using composition, rather than inheritance, so it becomes very easy to add or remove any particular piece of functionality.

For example, in order to construct a ship with a shield, an entity would be given a ship component and a shield component. If, at a later point, the ship loses the shield, then the shield component would simply be removed. However, if the ship with a shield was constructed using inheritance (i.e. the ship-with-a-shield class inherited from ship), then it would be very difficult to remove the shield dynamically.

Entities are the core type of object in ECS. They don’t have any behavior on their own - to add behavior, Components, which contain information, are attached to the Entity. When something should happen to the Entity, an Event is sent, and Systems process that event using the information in the Entity’s Components.

For my project, I used an existing ECS library (Gestalt). Gestalt is a library that is based on how Terasology (The Terasology Foundation’s main game) handles ECS. Gestalt provided the framework for me to build new, Destination-Sol-specific ECS structures, without needing to design the underlying framework. I created basic systems using that structure (health, force/contact handling, entity removal, physics, graphics, and projectile handling). I also had several pull requests for small features (rubble creation, stasis, and money-dropping) and refactoring/bugfixes (impulse handling, EmptyComponent implementation, and sprite scaling). In addition, I designed asteroids as a proof-of-concept that makes use of the new architecture.

To put it more simply, there are a few basic traits that players expect objects to have. For example, objects should have qualities such as health (if they can be damaged), position, velocity, rotation, graphics, and collision handling. My code provides a stucture for giving an entity those - and other - qualities. For example, to create an entity with health, a position, velocity, durability, and size, the code would look like:

EntityRef entity = entityManager.createEntity(new Health(), new Position(), new Velocity(), new Durability(), new Size);

Some components, such as Renderable components, require a bit more setup before they can be used. For Renderable, each sprite needs a RenderableElement that contains the actual sprite and metadata about how the sprite should be handled.

As of now, the biggest core area that hasn’t been refactored is sound-playing. In the legacy code, the sound was built into the way that individual classes handled certain events. Now that the code is becoming more modular, the sound structure needs to be updated to reflect that modularity. Once that is done, the rest of the gameplay can be transferred to ECS.

For guides on working with ECS, check out these links:

Links to my Work

Here’s the full list of my work:

For further detail, check out my previous blog posts (1, 2, 3, 4, 5) or take a look at my documentation. For the current list of TODOs, see here.

Conclusion

I had a lot of fun working on this project! At times I felt like a detective, and at other times I felt like an architect. I couldn’t have wished for better mentors or community - everyone was amazing! Whether it was helping me with questions, providing helpful tips, or discussing design concepts, everyone was incredibly knowledgable and friendly. I appreciate my mentors’ guidance, which helped me grow as a developer. I’m happy to give back to the open source community. I loved the experience, and I’m thrilled to have been able to contribute!