As others have pointed out, at one level this question is about Universal Turing machines. So that answer is probably unsatisfying.

Can you do something a little narrower that is not a UTM? Since you are talking about "modeling" and "simulation," I assume you mean modeling of physical reality, not modeling of computing systems, since that is covered by UTM theory (any computing system can be exactly modeled/emulated by a UTM, so that is not particularly interesting; it is when the model is necessarily an impoverished representation of the referred-to reality that modeling and simulation get interesting).

Unfortunately, I think the answer to this question is basically "No."

The devil is in the details, and unfortunately each kind of modeling language requires specialized handling at the "simulation algorithm" level you are thinking of. For example, tuning an ode45 simulator for things described with ODEs takes some local, specialized skill, as does tuning the expressivity of your algorithm's general purpose data structures for representing objects in the open modeling formalisms that represent object universes. Yes, you could create a "general" simulation algorithm that does all of it, but there will be no real "sum greater than parts" advantage, because all the complexity is down in the details. You will get very little extra leverage by doing it all together. In fact, I'd argue that lumping the capabilities together will create a worse algorithm overall than a more focused algorithm that just tries to be the specialized simulation engine for a single modeling paradigm.

Another way of saying this is that there is stronger coupling than you think between the modeling formalism and a simulator that can run models described in that formalism. The engine must match the car, and an engine that can be used on anything from a Kia to a Porsche is probably not a very good engine.

That said, it is useful to review the most general tools that ARE available, since it sheds light on why more general tools haven't appeared.

The most basic modeling formalism is just symbolic math and logic. Wolfram's Mathematica rules here. This is basically an attempt to replace human mathematicians with an AI to the extent possible. The simulation algorithm for something like theorem proving (yes, theorems are a kind of modeling, and proofs are a kind of simulation) has to be finely tuned to deal with symbol strings efficiently.

The next most basic language is ordinary differential equations. Tools like Simulink within Matlab reduce ODE-based modeling down to a GUI-based interface. You still have to do some artistic selection and tuning of the integrator (whether you use ode45 or ode23 depends on the domain... you'd use different precision integrators for car suspensions vs. the orbit of Jupiter, and this is a matter of judgment about the sensitivity properties of the specific equations, though these judgments are increasingly being automated)

If you generalize a little bit and add difference equations, finite state machines, Petri Nets, Markov Decision Processes etc., you can still use the stateflow/statechart description languages and stick to tools like Matlab. Try Lafortune's text on discrete event systems.

System Dynamics is a cousin of these, and there are tools like iThink that specialize in that. It claims extreme generality, but that comes at the cost of such low precision (which practitioners hand-wave away with "directionally correct what-ifs") that I barely think of it as modeling/simulation.

Once you get away from ODEs, you get what is technically known by us modelers as a "mess." There are a couple of directions where things get messy.

First, if you move from ODEs to PDEs, you end up in one kind of mess. ODEs are well-behaved, often have closed form solutions, and when they don't, can be numerically simulated in lots of useful cases in stable ways.

PDEs generally require extremely careful custom handling, and even then you'll usually get a mess. A classic example is the Navier-Stokes equations of fluid mechanics. There are entire disciplines devoted basically to modeling and simulating these equations. If you write down an arbitrary innocent looking ODE, chances are you will be able to simulate it. If you write down an arbitrary innocent looking PDE, chances are, it will crash your best abilities to model it.

Another direction of messiness is the discrete direction. Once you get beyond simple state machines and Petri nets describing relatively fixed universes, and move to working with open systems, you are essentially doing a specialized kind of object-oriented multi-threaded programming where handling non-sequentiality in time becomes the biggest headache. Again there are no truly general frameworks (C.S.P Hoare's "Communicating Sequential Processes" will give you a sense of the complexities).

Generally people who deal with this stuff call themselves "agent-based modelers." With or without realizing it, people doing game or VR programming stick to a tractable narrow class within this domain. How different agent-based modeling is from OO programming is a matter of debate. One popular line is "objects do it for free, agents do it for money." Regular programmers are skeptical that there is a useful distinction at all.

There have been attempts like the programming language Swarm (really a library for Objective C, I believe... I haven't used it... I chose to stick to Matlab even for my ABM work) to support this kind of modeling.

If you haven't actually done any of these types of modeling (I've done at least starter models in all these domains, and pretty advanced models in some), it is easy to get tempted by a false sense of potential generality. There are people who get very excited by visions of a "general systems theory" (GST). I admit I used to be one of them, and even took a stab at it many years ago.

I have since decided that this is basically an impossible problem for a variety of technical and philosophical reasons that go beyond what I've mentioned here (these have to do with NP-completeness theory, no-free-lunch theorems in optimization etc.) I have also concluded that anyone who adopts that label for something they've produced is basically a charlatan.

But don't let me stop you from hunting for a true GST. Who knows, all battle-bruised modelers like me might be mistaken, and you might find one, build Skynet on top of it, and take over the world. And even if you fail, tilting at this particular windmill is a very educational experience. I learned a lot from attempting it.