My role within the Calamity Mod development team is a programmer/game designer. I work with the other departments of the team like artists, writers, and sound designers to draft up content that we believe would add to the experience of the game, and then work on an implementation. The implementation is given to testers for feedback and balancing, and the content is tweaked as necessary until it is ready for release.
In addition to content development, I've also made a number of systems that make content implementation easier, more consistent, and more efficient, such as a music events registry/manager.
Lastly, I also create and maintain a number of external systems outside of the game that streamline our development process, making receiving feedback from the community easy, automatic, and coherent.
My first ever item contribution to the Calamity Mod was a rework to a ranged weapon called the Titanium Railgun. The associated clip was taken from a YouTube video covering some new content added in the Calamity Mod 2.0 update - the same update that the Titanium Railgun rework was released in.
The first item I contributed in its entirety (built from the ground up -not a rework!) was a weapon dedicated to one of the mod's donors, titled The Anomaly's Nanogun. The donor for this content provided a full writeup of what they wanted to the weapon to do, and I completed its implementation. For both the Titanium Railgun and The Anomaly's Nanogun, I did not provide the sprites - I only created the item code.
One of the systems I've implemented into the Calamity Mod is a music events registry. This system allows for songs to play out once in their entirety whenever certain criteria is met (specifiable via simple delegates) - currently, all events the mod supplies are triggered the first time certain bosses are defeated. This track playing runs for a configurable amount of time, with additionally configurable silence at the beginning and ending of the track - all done programmatically. It is also irrespective of framerate, and accounts for the game window being de-selected, which pauses the music.
One of the more scalable systems I've implemented is actually for upcoming content - which is yet unreleased. The "Murasama Variants" are planned to be implemented in a future update, where players will be able to customize their Murasama (a late-game melee weapon) with various styles and naming schema. Each of the variants was created by a Calamity developer.
Additionally, variant data is stored entirely within the Murasama item the variant is associated with - there are not multiple item entries for each variant. Variants are synced across clients, so no need to worry about variant desync. The MurasamaVariant class provides enough hooks for each variant to essentially function as its own item, with overridable methods for anything the existing ModItem and ModProjectile classes provide, without the need for creating more item entries.
Each hook has a default implementation, so at the very minimum, all you need to supply are particle colors, whereas at the very maximum, you can apply custom drawing code and shaders to both the item and the projectile. Reflection is used to automatically load all created MurasamaVariant types.
The Calamity Art server deploys an asset submission system that allows users to submit their own assets for potential use within the Calamity Mod.
Users can run the /submit command to create a submission with details like who made the asset, what the asset is, and any existing assets (if applicable). An asset can be a sprite, sound, or really any kind of game content - the bot handles it all automatically.
After submission, assets are automatically forward to the Calamity Development server, where they are then voted upon for implementation. Vote counts are automatically reflected in real-time in the Art Server. Once the voting period has concluded, if an asset received enough votes for implementation, it can be marked as implented in a separate "completed assets" channel.
Much like the Asset Submissions system, the Calamity Dev team deploys a Suggestion Submission system as well. Any user can write a submission, and after a validation period where it is verified that the user has correct formatting and follows all of the submissions guidelines, the bot forwards the submission to a public voting channel. Once per week, the Suggestion Bot collects all suggestions within a given time frame, and forwards top-voted suggestions to the dev server for dev voting. Once an additional time period has passed for developer voting, a suggestion is either passed or denied, and potentially eventually implemented.
When a suggestion has reached developer voting, devs have the opportunity to tag the suggestion with certain attributes that help with sorting and organization. There are additional markings for suggestions that can't be passed for one reason or another, such as existing conflicting plans. The user who submits a suggestion is notified whenever a suggestion receives an update.