Cyclotronica - An Atomic Physics Game

Cyclotronica -[definition] /ˈsīkloˌtränikə/ noun PHYSICS - resembling apparati in which charged atomic and subatomic particles are accelerated by an alternating electric field while following an outward spiral or circular path in a magnetic field.
Released March 14th 2021[year of the woo] https://store.steampowered.com/app/1536590/Cyclotronica/
http://monumentalartseng.com/Cyclotronica


The Mechanics
It's a stunt driving racing game, but all of the tracks are particle accelerators, supercolliders, nuclear reactors, futuristic high energy devices. In the course of conducting an experiment in one of the Level Apparati the player may be required to execute fps or tower defense mechanics amongst other popular gameplay tropes.

The Player
You drive a high tech nanobot on a monowheel cycle around and collect subatomic particles while conducting experiments or averting disasters.



The Gameplay
Use your particles to catalog Elements on the Periodic Table, or fire them out of your S.C.I.E.N.C.E. Gun at Atoms and Antimatter anomalies.

Learn To Play - Play To Learn
Learn about science while shooting from the hip with reasonable fidelity to actual devices or a sci-fi bent.
Helps kids of all ages learn and explore and passively memorize the periodic table of chemical elements, helps gamers do stunts and blow things up.

My Perspective
I have been a CTO and main designer for a number of startups over the years and began using Unity professionally daily since early 2010. Over that time i have produced game and applications, eLearning materials and VR based project management suite for the AEC industries, theatre sized driving demo for Jaguar Land Rover, a VJ toolset for the most The Marquee, the largest of the elite night clubs in Las Vegas that was also used at international music festivals, museum kiosk for The Presidio and have executed contracts for over 100 freelance clientele.

During that time I created many of my own game projects which often languished in folders due to my own propensity for being a nitpicking stickler for perfection. My son, Jason and I had just completed the recladding and restoration of The Great Fish which i had sculpted and erected in 1995 as it has been designated an Historic Site and we were tasked for preserving it and created a patent pending patina process that was simple, non-toxic and effective within minutes of its application.
http://instagram.com/monumentalartsengineering
Being immersed in molecular chemistry to devise the patina formula we discovered I pulled Cyclotronica out of my personal projects and showed it to him. I loved the free riding, stick to the wall stunt mechanics of the gyrocycle and had vaguely put together a collection system for collecting protons, neutrons and electrons to create elements but felt it was missing that certain pizazz.

Being that he was what might be termed a hard core gamer who could trounce me roundly in Tekken at the age of 6 and watching him play many, many games while I absorbed the mechanics and gameplay, determining how i would write the components to achieve such I had him review the mechanics and gameplay I had designed and come back to me with a plan. He did so. I was gobsmacked. Yes! This was what I wanted to see. We began designing levels we would produce involving real world experimental and industrial apparatus and machines. I set up some basic ScriptableObject assets for AtomicComposteAssets, AtomicSpeciesAssets and SpecialWeaponsAssets and he set about creating full data sets for all proscribing all known and usable data for all 118 atoms and 79 of the most important isotopes, the characteristics and data sets for all of the known subatomic particles and designed weapons we could use in the S.C.I.E.N.C.E gun and probe which we would utilize as a shooter mechanic based on real world configurations of particles and energetics used in the laboratory.



I always had a distaste for arbitrary rule sets. These were not arbitrary but rule sets based on the actual rules that make up our experiential interaction with the constructs of the 3D laboratory universe we inhabit. It also had a play-to-learn and learn-to-play structure to it. By this I mean that a youngster who played this game would begin learning through mnemonics at the very least the names, configuration of protons, neutrons and electrons of all the elements and be exposed to magnetic parameters, fission daughter products, half lifes and other pertinent data of which we will incorporate each of these in levels we have already completed and future levels whose game play would involve for the purpose of demonstration principles based on this data. I dare say the professionals and student involved with nuclear physics and chemistry will get a charge out of playing this so to speak. The Lore he has written when inventorying atoms from collected PNE and the Mission Objectives use some very savvy wordplay and witty humor to engage the player. This is no longer a dry subject for the ivory tower intellectual but something fun and entertaining. It is truly a melding of science and art.



I will further expound on the development process, the training of a game designer, how I structured the components and other snippets that may interest budding game devs and designers or perhaps offer some insight for seasoned pros. I will break these down into single posts on this thread to avoid walls of text.

 

The Pitch
Part Racing, part Shoot 'Em Up, part Puzzles, all Nuclear Physics!

In Cyclotronica, players race through a series of high energy reactors and particle accelerators as "Mr. Big", the ironically tiny rider of an ultra-high tech monowheel cycle, collecting particles, conducting experiments, dodging and doing battle with antimatter and radioactive isotopes using the patented S.C.I.E.N.C.E. Gun, solving puzzles, and discovering the Periodic Table of the Elements in the process.

Our idea is for the player to be at the epicenter of the danger. All of the places where you can't look with your own eyes, shouldn't stick your hands, shouldn't approach with your body - that's where we want to put the player.

The tests performed by nuclear physicists involve fantastically large devices, employing immense forces on small targets. Many are designed like a racetrack to begin with, why not? We want to put the player in the middle of the experiments. Not necessarily drawn to scale, but drawn to the interaction.

LookDev and Performance
One of the earliest decisions to be made is lookdev when developing a game. Since we were going to be making use of physics sims and dozens to hundreds of rigidbodies whipping around with attendant efx particle systems to simulate the subatomic particles and elemental atom constructs, weapon and probe interactions we had to leave alot of processing power to be used by the physics system. Ergo the environment and lighting needed to be lightweight in terms of processing power needed. A texturing style decided upon used greebling in printed and etched crystalline surface styles similar to those taken with nanophotographic methods. Since this was at such a scale that shadows would not matter and I wanted to make use of normal maps to create a highly colorful overall graphics environment. I used four directional lights with shadows off with each set to a saturated color. This gave us a highly performant and detailed environment to construct gameplay and create the apparatus structures with.

 

Cyclotronica is out on Steam so I guess it is time for another post. [link in top of thread] .'cause ya gotta follow up and stuff according to marketing wisdom. So I was gonna bloviate on at first about UI choices and inventory systems, periodic element arrangements and etceteras in a dry and technical manner but I was boring myself to total distraction and watching cat and dog rescues instead of writing stuff..'cause ya know..yer supposed to do that stuff according to marketing whizzes so let's give 'er the ole college try..even though I never went to college

So I drafted my son, who is in his 30's and has kicked my butt in video games since he was six or seven to the point I would have rather watched him play than be fumble thumbing a game controller and frankly after 35+ years at a keyboard I still hunt and peck or it kills my hands so I am jamming away at what I think is a "W key and it is the "E" key and i am getting my arse kicked by the level boss. Game over. He has eSports level reaction speed compared to my 50 yard mosey. So I figured he would be good to put my mechanics thru a grueling beta test and his friends could assist. Utilize your resources.

It also pitted dichotomous virtual game world views against each other that became..here come's that dreaded corporate hype word... synergistic. My career schtick in Unity has been to fix stuff and work out complex frameworks and UI/UX for clients frequently not in the gaming sphere. So I of course try to weed out breaking corner cases but as a programmer you can work out something by repetitively coordinating series of mechanics and checking readouts etc. He gets a game and immediately sets about to break it and makes it do things it wasn't designed to do. The fixer and the breaker were gonna combine wits to see how we could push basic gameplay mechanics, combined with rules derived from nuclear physics, elemental particle composition and their interactions with the player and each other as well as the environment.

While he started filling ScriptableObjects with data about each element and isotope for extraction during gameplay I kept building UI widgets and environments and components of general purpose like particle emitters that could be tuned with any number of parameters to fire rigidbodies singly at intervals, as shotgun style dispersion, sequential prefabbing, aim vectors, initialImpulseForce etc. I also created jump gates, tower emitters, AntiMatter AI driven pursuit and annihilate species, particle efx and enviroment props along with libraries of materials to match te lookdev decided upon. By January of 2020 we were on a roll creating a basic environment with basic mechanics every 2 to 3 weeks whilst fine tuning gameplay of previously populated levels fixing bugs and etc. His proclivity for finding the breaking sequences led to it being more and more bullet proof... and then.. bam.. I had this weird flu that hit me quick with shivers and a tight chest. I beat it three days later with a good meal but it's effects lingered for a while and I felt a bit stupid .. Then some stupid Unity PhysX bug hit that cause collisions of emitted prefabs with the broadphase box to hard crash the app to the desktop and brought developing to a halt for a few months..Eventually one of the desktop engineers personally helped us get it resolved..

I tried to work around it with the ECS and DOTS and got some good crosstalk going between the ECS rigidbodies, the GyroCycles following rigidbody as well as Vanilla Mono Unity communicating with what I needed to from the ECS world but felt that it's physics was too deterministic and no matter what flags i set or numbers I changed I could not get them to roll when on a surface. It was pretty cool emitting 25K rigidbodies from a small volume in one frame and have them explode and bounce all over the arena at 180 frames per second.

to be continued..Next - Training a Gamer to be a Game Designer and Programmers of sorts.

 

Since we were dealing with atoms and subatomic particles which have their own precise rule set when interacting in the materium of the 3D laboratory universe they exist in, we needed to develop a plausible technological backstory and lore to support the demonstration of principles/experiment/mission of each level. By this I can use the analogy of Star Trek where in each episode they would travel enormous distances at incredible speeds, transport into and out of scenes, fire photon missiles, ignite force fields as protective shield against enemy weaponry and make use of tricorder telemetry. Though integral to the Star Trek universe they were used primarily as props to drive stories which unfolded to demonstrate moral, technological, philosophical, cultural and political dilemmas and resolutions.

Games are not linear in the sense of episodic sci-fi for example but a good backstory you can use to scaffold gameplay on top of already established interactions and behaviors as derived from atom to atom interaction and subatomic particle interactions and grouping to create atom composites from. We already had electronics which is the making of circuits to control the flow of electrons using rule stack/modifier components to stop, start, modify amplitudes, condense, store and release such as switches, transistors, resistors, capacitors, coils, tuners etc.. Since we would be dealing with many principles and manipulations of the other subatomic components of an atom composite we named the technology Protoneutronics. We would use an interface that would transform subatomic events into a graphical representation that was human cognizable.

That interface was given an acronym M.I.S.T.E.R B.I.G or Miniature Infinitesimally Stable Tachyon-Enveloped Reconnaissance & Boson Influx Gyrometer..or Mr Big as we ironically named him in our virtual protoneutronics lab bench. As a probe or emitter to cope with the various experimental duties and mission hazards the instrumentation was bestowed with the S.C.I.E.N.C.E gun which we gave the acronym the definition as Spin-Coalescing Integral-Energy N-Coupling Emitter. It'll launch anything you can hold onto, and even some things you can't!

So, while we are in the middle of tons of research into experimental apparatii, scientific papers, brain withering storms of acronyms and scientific techno jargon I came across an oldie i had not seen in a while and actually remember it from when it was on TV. The Turbo-Encabulator which as a science nerd kid thought was hilarious and decided to write up such for an explanation of how we formed Mr Big and his GyroCycle vehicle out of the mythical Nanides. And being a radical aethericist I wanted to allude to the aether as the medium of the materium that these species and composites existed within and of. Here is the original Turbo-Encabulator

In honor of that brilliant satire I wrote this about how we created our interface apparatus.

"For years research has gone into observational methods establishing an equilibrator axial stabilization and continuous angular momentum induction conversion system whereby the instrinsic binding of quantum observational anomalistic adherence to a non enspiralated, inhedralic and embeddability denying, banded step driven, boundary excursion jumping energetics could be bootstrapped into a continuously analog hypershere encapsulated observational device.

In the course of this research a particular array of protoneutronic devices in concert with each other was capable of creating an angular torque defining a 9D topological manifold, that when inverted by the torsion spin reversal pentode accumulator gave an output that when parsed using a ratcheted icosahedral relative frame based algorithm collapsed the dimensional complexities into a fourth dimensional observation point.

The field surrounding this observational point coalesced and a malleable quasi-substance that could be jittered into various forms via protoneutronic transverse wave interferometry that simultaneously exhibited properties of substantial matricular adherence and observational persistence and yet did not exist as per the standard definition. The research team at first wanted to name this peculiar state of collapsed hyperdimensional reality that was simultaneously there yet not there and they tossed the moniker Schrodinger's Cat Crap around but settled on the more marketable Nanides."

So, we now had conceived a notional game mechanics framework, backstory and lore to develop levels and scenarios around.

..to be continued...

 

Having been around these forms over decade I have seen alot of young folks come in and believe they can leverage their gamer skills into a game designer career. It is possible but you do have to know something about how games work and it would help to have done some mods and such. Jason had come up with a brilliant use of ScriptableObjects for dealing with the sfx and efx so I have to give him the props. He now understand Unity scripting and the component based frame dependent architecture, blittable types, conditionals, iterative loops.. so I had him write up a kind of roadmap of how he got from there to here..or hard core gamer/modder to game designer. Here is his write-up.

Gamer to Game Designer

"For me the learning process leading up to game development has been scattered, I started out in Middle School on a Power Mac 6100 with a 350MB platter hard drive (ballin'), messing around with the dwords inside of game plugins for things like Escape Velocity so I could make my spaceship extra powerful or so I could mess with my graphics and change the color of my ship so it was unique. Also enjoyed building DOOM levels and Warcraft/Starcraft levels, custom scenarios, it was good sandbox time - you could learn a bit about Triggers and Mission Events and Flags. Ways to tell a computer running an engine about events that are implicit and obvious to the human mind. Computers are funny, they do exactly what you tell them to as long as you talk on their terms, look at the bad rap our boy Tron gets... It was Flynn's instructions to "perfect" everything that were the real problem.

I started learning HTML and basic hex code in geocities chat rooms arguing with kids in special red text because that makes cussing look funnier. It also encourages typing speed and accuracy because you don't want to look dumb. I learned a fair amount about CSS by ripping MySpace themes from people who actually understood CSS syntax and then I would remove their custom watermarks and tweak the template, worked nicely for my music pages.

Later, when games started to have better physics sims, it was obviously necessary to mess with them. Grand Theft Auto is a gold standard for driving physics and if you bust into the archives, those tab delimited text files full of handling and weapon properties are really spectacular. Guns that pull with negative force, bringing vehicles hurtling toward your face with every shot fired. Fire trucks that weigh millions of tonnes with a 7-gear all wheel drive transmission, sweeping away bystanders awaiting their radiant AI-scheduled 6:30pm traffic jam. Good stuff.

Anyway you start to learn things about how computers deal with instructions. There's assets, there's scripts, there's a command stack. There's things in memory, there's things that stay in memory, there's things that aren't allowed to stay in memory. There's references you have to make depending on whether it's allowed to stay in memory or not.

Eventually reading enough of the c# scripts I figured out how to set up object references and pass components around - which is great if everyone is already on the stage and present and accounted-for. But then when you want an entity to have an ability to evolve and arm itself with appropriate scripts while its identity is refreshed, you can't rely on components to know what their references are unless you can hard code them from the jump.

In my instance I'm pretending a game object is an Atom or some Isotope of an Element and I'm trying to make sure its properties on spawn are appropriate to its gameplay purpose and chemical properties or whatever analog of that we are going with for gameplay purposes. If it gets altered, absorbs a neutron, or undergoes decay or fission, or needs a rebuild, it needs to look at our scriptable objects and build itself again from the new variables.

Talking further with Randy he told me scriptable objects remain on "the Heap", so it stays in memory. This got me to thinking later about a problem I run into when doing everything object-based in Unity which is if I have some temporary EFX or VFX to spawn, it isn't on the stage to be referred to yet - and when something changes it won't pick up the new prefab reference if the object gets refreshed since it wasn't in the hierarchy to store any details before runtime. You can frontload it and put a bunch of invisible things you don't need in every scene and fight with it about spawning an object and making it visible, or you can just make another scriptable object that stores all the fields of links to prefab EFX and then make that a public inclusion to your other scripts. You can then just refer back to the phone book of all of the EFX and it's hard coded as text in your other scripts.

Don't get me wrong, I love the inspector but this saves me a ton of time wiring up prefabs to each other and centralizes where I call them from and gives me a simpler hierarchy in my scenes where I only have permanent objects in the scene."