Download

Dual Monitor : Game on screen1 + User Interface on screen2 - How to?

Hello everyone,

I’m working on a space RTS on my spare time, and I wonder if it’s possible to have my game on dual monitor.
I’d like, for example, the players to be able to play on monitor 1, and to move the widgets (I already have movable window) on monitor 2. This second monitor must not show the game environnment, only widgets upon a 2D background.
Any idea if it’s possible and how to do this?

Thx.

This represents what I’d like to have at the end.

  1. Project-Settings -> Activate -> Split-Screen -> Vertical split
  2. Widen the viewport to double the normal width (using a console command)
  3. Create widgets using a newly added player and assign to player-1 so they show up on right pane
  4. Occlude the world, using SetViewTargetWithBlend to pick an independent camera below the map
  5. Duplicate inputs from player-1 to player-0: interfaces / ev’s. Mouse defaults to player-0 anyway iirc.

Thank you, I’ll check that.
But I suppose this way I can’t drag a movable window from monitor1 to monitor2, correct?

Not a movable window. I think you would need to code it in c++ to be able to get 2 different windows to talk to each other.

Yes, Widgets can cross screens, so a fully dragable window is possible.
But its not a separate ‘floating window’ as such like a Windows pane tho.:wink:

You should check these first, they’re FREE:
https://www.unrealengine.com/marketp…iewport-window
https://www.unrealengine.com/marketp…indowcapture2d

There are also other options that are PAID:
https://www.unrealengine.com/marketp…ble-window-umg

OK Thank you very much, and for the links.
I’m not sure I understand it all but I’ll have to test as soon as possible.
As for draggable window, I already have my own :slight_smile:
And Thank you **MostHost LA **also.

You can always try multiplayer on same PC. One client can render all (ie. 3d and gui) second client is only Gul.
However if your game will be “real” multiplayer at some point, that hax with 2 clients is more complicated than it is worth. You need to develop 2 projects, or gui only will waste memory and resources if code is identical to “main” game.
For singleplayer games (with fake multi for gui etc), you can do multiple monitors, each unreal “game” should run on separate thread, so it should be even faster than single game.

It’s intended to be MMO at the end, hopefully… then… what do you think is the best method?
Thank you

For mmo You should not use any hax, you need proper handling of that stuff or you get in potential trouble later on. (and probably do it in C++, so it is more stable)
I also suggest you focus first on ground level stuff. Doing multiple monitors support is kind of mid to late development.
So first you should find what is needed to make mmo working, like some backend or maybe sdk for mmo.

This is same problem like with making cool and pretty levels before you made any gameplay and movement code (that is trap i fell into multiple times, because it is fun to do)
That time spent on making level is usually wasted because later on you have different speed of movement, height of jump maybe bigger packs of enemies etc.
And you spent weeks doing really nice looking map that does not work with gameplay.

Same with coding any gameplay systems before you have working backend (or at least idea how you do backend)

However if you dont have manpower or $$$ to make mmo yet, i should suggest making coop multiplayer with private servers up to whatever number unreal supports out of the box now.
I really would buy rpg game that have private servers, modding support. So i can invite my friends to paly with me.

Nothing I suggested before is really suitable tbh. You should always say what the end goal is first.
For sure, you can build a prototype, which is great for proof of concept and finding people to join.
But as Nawrot said, this has to be done properly! A Blueprint MMO is like a running joke on here.:wink:

Allright thank you both of you… I push this for later developpment then. I have so much to do before that.