wadaltmon

Create graph nodes at each intersection/along the roads' curves. This is oftentimes able to be done automatically with many game engines; although RS's is proprietary, I expect they have such a tool. Give each person a start node and a destination node (or start point and end point, and determine the route to/from the nearest node for each), run the A* or another pathfinding algorithm to find the shortest path from one place to another, save that succession of nodes as some kind of structure on each driver (linked list works best conceptually imo). Do all that serverside for the online play so you always have plenty of processing power. In single player, do that solely for the ones that are visible on screen. Add in some graphical smoothing for the driving so it's not choppy, add in some handling for when you attack or threaten them (start a running away procedure when attacked, after a certain amount of time, assess if there's still a threat, continue running away or go back to trying to get to the destination if not). That's probably just about the basics of it. There's certainly a lot of little nuances that RS took to make it more realistic. Stuff like using a weighted graph system for allowing pedestrians to run in the street, but not prefer to, perhaps. And I expect a complex state machine to govern their mood, current objective/destination, etc.

I'm excited to see support for the Quest. Being able to test standalone without having to have it hooked up to the PC would be nice as I do with... another engine that starts with U. It would be good to also support the camera-based hand tracking the Quest can do, but support on Oculus/Meta's end has been finicky for it too.

I remember back when GameMaker was older (started using it when I was 13, so that's a long time ago now, that was around the time version 8 was coming out), the model was that you could do almost everything with the exception of a few functions that were locked behind the Pro version (most notably all 3D functionality was disabled). The big thing was that you could not create a standalone executable for your game, you had to run it out of the IDE. Maybe that should be part of the Ultra model - let people use the tools to play around, but don't let them create a standalone executable or publish the game without paying the subscription. The subscription basically then functions as the recurring price for distributing the game.

Perhaps using Unreal as "the big guys" was a bad idea. Unity kind of fulfills the same role in my comment. I hope your confidence yields some stellar results when this is released.

Knowing what I know from working in the software industry (as well as having friends in game development, having interviewed for the roles, and constantly getting emails from recruiters about said roles), the main draw of the most popular 3D engine at the moment (Unreal) is that it has crossover potential. Out of the box, you have something that anyone of any skill level can pick up and use. (Even if this isn't what you're going for, or you specifically market to a skilled/experienced crowd, this is still the case.) While this seems like they're pandering a great deal to children with rich parents who will absentmindedly pay the subscription fee (they are, but that's not the point), they also want a full team to have the highest accessibility to their product as possible. An artist, a level designer, a programmer, and an intern off the street could all open UnrealEngine.exe and have something working within their respective fields within a matter of minutes. There's also the point that Unreal Engine (Epic Games) knows how to sell itself. I'd hate to see another comparison that clearly shows Ultra as the winner only for someone to say "w-well, it doesn't have Nanite!" These are the types of things that the "little man" tech news channels tend to latch onto, and collectively their reach is great, and largely to those who have about as little knowledge on the subject of game engines as they do. The point of me saying this is that to attract both the Leadwerks users and the enterprise users, you will likely have to do a lot of work on presenting this engine in an aesthetically pleasing a manner as possible, as well as provide toolsets that can be used seamlessly by those people. I hate the fact that people will defer to their lizard brain and just go to the flashiest coolest thing possible, but I can say it's better to have some semblance of this initially and let people discover on their own how capable your engine is than to try and wow people with the more technical only for it to push people away.

I'm interested to see how a legit demo will fare with this early engine version.

Displayed as intended, but once I closed it, Windows Defender recognized it as a trojan and automatically deleted the exe.

Very typical Reddit.

The mention of Code::Blocks on Linux triggered my fight or flight response. Horrible times with that in college. That was on 16.04 though; looks like Linux/Ubuntu has developed pretty well in the meantime. If we get Ultra Engine on Linux, could be fun to try and dual boot and develop for cross platform.

In the context of UAK in a vacuum, C#/Lua (though it wouldn't be for me, I just know a lot of people would benefit). EDIT: Should've added before, if the choice is on the table, I'd rather see the 3D engine before more UAK stuff.

And this becomes the case just by setting the physics mode to Entity::CharacterPhysics (2) and the collision mode to Collision::Character (3)? It continues even when using a different collider than the default?

The SetInput function interests me, as it seems like it has a lot rolled into it that allows it to take the place of many lines of code, but doesn't block other functions from working in tandem with it. There are a few functions that it overrules (as stated in the documentation), but it provides acceleration, velocity, and rotation for a character while seemingly also overriding the default physics behaviors associated with force applied to a Model or Entity with a given collider applied. On that note, it also seems that it doesn't give you a maximum velocity; for if I use the SetInput function but also apply an extra force in a given direction, I can give that object a boost for a short time before the force dissipates. Anyone know of the equivalent code for SetInput? It seems to go beyond just AddForce(), SetRotation(), and/or SetVelocity(). Is it maybe a Move() function with some math to determine things like acceleration?

Now these new collision functions are top tier. Exactly what I'm looking for. Would love to get a chance to beta test and try them out.