OMS Newsletter 3 (08/03/2024) - Systems overview

Greetings, fellow developers and enthusiasts!

Welcome to this edition of the OMS (Orbital Mechanics Simulator) Newsletter. It's truly heartening to witness the growing interest and engagement with each passing update. In just the first 8 days since the post went live, we've seen the viewership of our last newsletter surpass that of the first, a testament to the community's enthusiasm and support.

In this instalment, we're delving deep into the systems that power our simulator - both front and back end. We'll explore the choices made, the challenges faced, and whether, given the chance, I would approach things differently.

Before we dive in, a quick disclaimer: The regular updates on the progress of our simulator will follow below the more technical content. So, if you're here for the latest developments, fret not, they're coming right up!

Frontend: Designing the User Experience

In crafting the frontend of the Orbital Mechanics Simulator, I aimed for a user experience that strikes a balance between simplicity and depth. The interface needed to be intuitive enough for newcomers to grasp while offering advanced functionalities for seasoned users. I think the current temporary UI does a good enough job of that, but there's always improvement to be made!

Design Choices

• Minimalistic Interface: I opted for a minimalistic design to reduce clutter and keep the focus on the simulation itself. This approach also enhances usability across different devices and screen sizes. This will become better translated with the UI as it gets its art pass!
• Interactive Elements: Incorporating interactive elements such as the velocity vector indicator enhances user engagement and facilitates better understanding of spacecraft dynamics and later down the line how orbital bodies effect those interactions.
• Futureproofing: While designing the frontend, I kept future expansions and feature additions in mind. The UI architecture is flexible enough to accommodate new modules and functionalities seamlessly, with little effort. This was important for me as a solo developer, as I need to work efficiently. Clear hierarchy trees and naming scheme are vital!

Backend: The Engine Behind the Scenes

The backend of the Orbital Mechanics Simulator serves as the powerhouse, handling complex calculations and simulations to deliver accurate results. Here's a glimpse into the core components and decision-making process:

Implementation Choices

• Physics Engine: Selecting the appropriate physics engine was crucial for simulating realistic orbital mechanics. After careful consideration at the project's inception, I settled on building something custom and using Unity's rigid body system as a base beneath it. 
  • The results of the simulator must be realistic enough to accurately teach orbital mechanics, to that extent, later down the line I plan on doing some form of unit testing to make sure we're creating accurate results consistently. But more on that in the future!
• Data Structures: Efficient data structures play a vital role in optimizing performance and memory usage. The simulator makes use of dictionaries and arrays for the most part. We cache as much as we can where needed to manage celestial bodies and their interactions efficiently.
• Scalability: As the project evolves, scalability becomes a key consideration. The backend architecture is designed to scale gracefully, allowing for the seamless integration of new features and optimizations. That being said, I'm constantly looking for ways to stick to programming conventions and make sure that I program things in a way that aids me now and in the future - so things will still be rewritten from time to time!

Reflections and Future Directions

Looking back at the development journey of the Orbital Mechanics Simulator, I can't help but reflect on the choices made and the lessons learned along the way. While I'm proud of the progress we've made, there are always areas where improvements can be made.

This is part of my core strategy and will remain part of it going forward. I'm not afraid to spend as much time as I need rewriting systems or refactoring as I know things like that are going to be vital to keep things clean and concise in the future.

Would I Do It Differently?

Given the chance to revisit certain decisions, there are indeed aspects I would approach differently. For instance, exploring alternative physics engines or refining certain aspects of the user interface could potentially enhance the overall user experience.

I think I know I would certainly redo the timeline aspect of the project. Some features had too long spent on them and some had too little which is still biting me a little now. The best example of this is the Orbit Display which still gives me consistent issues to this day.

Regular Updates

Now that we've delved into the technical aspects of our simulator, let's shift our focus back to the latest updates and progress.

As a quick note, a proper update post will be coming later! For now, here's a small update:

Teaching Module Progress:

• Status: Fully underway
• Importance: Vital to the project's core goal
• Approach: Utilizing the Fungus package for streamlined development
• Progress: About 30-45% through writing dialogue

Main Menu Enhancement(s):

• Status: Completed (see attached image!)
• Impact: Elevated overall project polish
• Upcoming: Further UI work and settings menu refinement

Deadline Adjustments:

• Status: Anticipated as deadlines approach in April
• Expectation: Scope may shift rapidly to fit deadlines
• Flexibility: Prepared for adjustments to project plans

These are some of the minor updates! More will come in the next newsletter as per our regular scheduling.

Stay tuned for more exciting developments in the next edition of the OMS Newsletter! Watch this space!