I don’t really have hard boundaries between Editor and user code.
Which is nice for debugging and general usability, but bad for exception handling.
I am not sure there exists any nice solution. If I want exception safety, I should just launch separate process.
I am using ImGUI, which is both a blessing and a curse. On bad side, rendering 10k item list with ImGUI is much slower than 10k item list with normal UI. On good side, ImGUI doesn’t care about total item count, it only cares about visible ones. I may have 10k nodes, but if they are mostly collapsed and hidden in the tree, I will not pay for them. And with ImGUI I have 0 lines of code to handle updates. It is just 100% automatic with ImGUI. So I’d say using ImGUI is net positive trade.
Would it mean multiple Rendering contexts ? I personally would want to avoid that .
I didn’t check it yet , but it would be interesting to know how Unity and Unreal are handling it.
.NET 6 has a good exception handling , my editor got it mostly covered but not all of it (I might be missing something ) , I guess I will continue to search for the optimal solution .
I am using customized Urho3D UI , using Urho3D ListView in my Hierarchy window tab .
The slowdown is caused due to addition/insertion of new entries/items (the ListView already contains > 10K items).
I guess I will write my own customized ListView UIElement
More editor stuff. I implemented asset importing (from glTF for now, but it can process any file), was quite annoyting to handle asset processing cache without redundant re-imports and with automatic imports when needed. Also improved plugin system: I can select sample plugin and it will run sample with scene generated in code. I want to make all samples run-able in Editor at some point.
Got Steamworks working for lua with ffi! Now I can make an online p2p multiplayer game using steam’s servers for free, without need for port forwarding or server setup. Here’s what I’ve got so far: basic menu set up, creating a lobby, and viewing the lobby list, which will update when a new lobby is created. In the gif I open two instances of the game and create a lobby with one so I can join it on the other. The lobby is not locally hosted, but instead the game finds it from steam’s servers based on the game’s appID.
The next step, after gathering all players in the lobby, is to start the game and use packet sends to manage/play the game (simple p2p, not authoritative). I plan to make a simple 2d fighting game. I’m fine releasing only on steam, so this makes online multiplayer in urho 100 times easier. I can also do achievements, leaderboards, friend invites and all that other stuff. The best part is any multiplayer game would use the same lobby setup so I only have to do the hard stuff once really.
P.S. lowered the framerate on the gif to post
You’re supposed to register a game ($100 and 30 day wait before publishing) to get your game’s appid. But you can use steams testing appid during development. I’m not sure about their rules exactly but I imagine if you set up a developer account and registered a game (even open source) you can still get your own appid, after paying.
You dont need any game server code or docker images or even need to know anything about ports or addresses or punchthroughs. I dont know exactly how steamworks p2p works but you connect to steam by just having the application open and add the api to your project. It’s awesome because all the hard work and security is done by them (plus you don’t pay for nor maintain servers). A user launches your game on steam as normal and is automatically connected.
This is how my game integrates it. I use lua so I needed this ffi wrapper but steamworks is c++ so that would be different if you are making a game that way.
steam = require("sworks.main")
assert(steam.init() and steam.isRunning(), 'Steam client must be running')
assert(steam.isConnected(), 'Steam is in Offline mode')
user = steam.getUser()
Then I can do stuff like:
steam.queryLobbies(filters, limit, callbackFunc)
And get available lobbies (that steam takes care of specific to your game only) as a table, connect to them, create them with another function, send chat messages, etc. It’s very easy. As far as gameplay, once you are in or made a lobby, you already have all the other player’s steamid. You use the send packet function to communicate with them. Since it’s p2p you don’t need a host controlling gameplay but you could make the host collect controls and relay things out if you wanted to. I’ll probably just have players send packets to all others with where and what their character is doing (casual game anyway, so it doesnt really matter). The reason some would want the host dictating stuff is if one player had a bad connection they might start glitching and teleporting.
Our newest APIs relay packets through the Valve network by default, which ensures that players and gameservers are protected. It is higher performance and uses a higher-quality reliability layer. It also supports ordinary UDP connectivity. An open-source version is available on github.
Yeah sure thing. Took me a while to figure out you could do this stuff since most posts about steamworks integration online seem to be only focused on achievements and leaderboards, rather than p2p connections. I’ll post another gif when I have more done with it.
(joined effort with @glebedev)
Implemented object outlines. It should work with any vertex shader, but it’s not very smart since it just replaces pixel shader with either solid fill or ALPHAMASK cutout fill.
For now I use only one temporary texture and do edgedetection between colors, so I cannot do intersecting contours of different colors now. At least it’s more efficient…
Yeah… It took some time (and hacks questionable design decisions) to make it work.
But I almost finished the Editor.
I can now run extrenal games fully embedded (one process with the Editor), yet in optionally separate OS window. Games will need some minimal glue code, sure, but it actually imposes much less restrictions on the game code than I anticipated.
It took maybe 30 minutes to port my existing game to be perfectly run-able in the Editor… and maybe 2 days to fix all the bugs on the engine/editor side. Fixing mouse handling was very annoying and I am still not sure I fixed all places…