A while back I made a terminal model that looked meh but was designed to serve as a stand in for some kind of computer interaction:

I started out wanted to make a command line interface, but then I changed my mind and wanted a Doom 3 style interface:

View post on imgur.com

Setting up the actors

To accomplish this I found that unreal has a whole system for defining this procedure called a “widget interaction component” (see https://dev.epicgames.com/documentation/en-us/unreal-engine/umg-widget-interaction-components-in-unreal-engine) which is great! However if you’re not only trying to push buttons its a real pain to get everything setup to map properly.

The component works by doing a ray trace every frame so many meters in front of you, if that trace hits a widget component (the container class for UI components, see: https://dev.epicgames.com/documentation/en-us/unreal-engine/building-your-ui-in-unreal-engine) then the widget component will receive events as if the widget component was the 2d UI that is used for basic UI development. In other-words: Unreal makes a virtual screen, then I add the “virtual screen user” component to the player character and then it should be the same UI development process I would use for menus, huds etc.

To show the UI in game I made a quick actor that held my terminal and my UI widget

My initial UI widget is just a white box cursor and a translucent green background

So ideally I would just use my Widget Interaction UI and do 100% of the development on the widget side. HOWEVER, I found out there isn’t a good “get What the Widget thinks the cursor position is” within the widget (The widget that holds the UI design also has its own execution path if you didn’t know that). But the issue came from that the only way to get the cursor position was the ACTUAL cursor position, which wont work here because it will always be centered on the screen during gameplay.

Sooooo, to fix this I had to make a “Set cursor position” public function that can update the location of the white square:

Then I had to add yet ANOTHER tick function to my main character to handle terminals:

So here’s the order of events:

1.) The widget interaction component detects its hitting a widget in the world here:

I then grab that widget and hold it in memory

2.) The tick function executes on the next tick

Which sets the position of the white square.

The result:

Seems decent enough, I just gotta mess with the sizing a bit more and disable debug to start really working at it.

Making a simple UI

To make a quick cursor (if you ever need this information)

1.) Select all

2.) Scale down to 1/4 of the screen

3) Fill black

4.) Rotate your selection 45 degrees

5.) Remove the corner

6.) undo that because that would never work

7.) Invert your selection and fill white

8.) Undo that because that makes no sense

9.) Select all

10.) Shrink by 50

11.) Rotate your selection 45

12.) Undo that and select all again

13.) Shrink by 25

14.) Rotate by 45

15.) Erase everything in your selection

16.) Select all

17.) Shrink by 50

18.) Scale horizontal by 50, increase vertical to 125

19.) Rotate by 45

20.) Undo and rotate by -45

21.) Be sad that you didn’t scale large enough on step 18

22.) Undo the last 4 steps and increase vertical size to 150

23.) Do steps 19-22 again and resize to 175

24.) Select all black, and realize you have weird artifacts from rotating

25.) Mess with the levels to remove all of the artifacts

25.) Make a boarder around the black selection and fill white

26.) Invert the colors because you realize most cursors are white not black

27.) Gaussian blur to make sure no-one can see your horrible brush strokes

28.) profit?

Now with that squared I can imported everything into unreal and made a quick ui with a few buttons:

Then I threw in some logic to make the weapon lower when you’re looking at a terminal, and that the “fire”event will left click the simulated UI:

The final result:

Still not sure why the cursor is so blurry when moving around a bunch, probably because of some of the motion blur I have on. But generally the goal is to have one of these on each assembler and I should be able to use it as a capture point kinda process to gain control over the assembler to create minions to go capture more assemblers etc. Which I think is now my basic “game loop”

So now I think I know what the game is, I’m thinking one map, 4-5 assemblers, one “Hub” boss area, I’ll probably package in my survival game mode because it’s kinda already done. Essentially this will be a single player MOBA against an over-world AI

So that means I need:

1.) An overview map UI element

2.) Region based spawning for the assemblers

3.) A “Boss hub” whatever that means

4.) Some kind of stationary turrets like which will essentially be a moba

5.) Some kind of countdown that adds an element of urgency to the player

So I added 5 tasks while removing one…not a great ratio (see https://trello.com/b/dmIooAod/blacklaceworking-board ) but knowledge is progress.

Also for some reason my output log is taking up 8 gigs of memory.

I admit I had a divide by zero error but why did it fill up the output log to the point of nearly crashing my computer…

Other news, I reworked the bot deaths so they spray oil everywhere:

This is a oil material I made in gimp, then randomly subdivide and throw on walls. The oil material I made from an awesome blood splatter tutorial here: https://www.gimpusers.com/tutorials/blood-splatter-texture

Which long story short, it’s just the “sparks” brush grey-scaled. But still….

I also did another pass on the AI to 1.) stop it from following you while it was reloading and 2.) To keep it moving during a fight.

#2 was done by adding a list of positions where the bot received damage last

Then I made an eqs query context to basically make the bot shy away from where it was shot before.

To fix #1 it was just a weird quirk of ai services objects. The way I’m looking at the player is via a service (Called PatrolBot2FaceTargetService), which runs every 0.5 seconds that sets a “focus” variable for the ai controller. This essentially just turns the controller to the object it wants to “focus” on.

The issue was that that green guy was running after it stopped going down the “findFiringPosition” leg. So you never really cleared out the focus on the character. So a quick fix is when the bot reloads it drops all focus

Here’s the results of the two:

Honestly I think its already helping out with making fights a bit more dynamic.

I also added bot teams so I can start doing stuff like this:

I want to somehow get the eqs setup so it is a bit more random, you can see both of the top two bots moving upwards to find the next “good” position, which is scored more from where they’re at. I think I’ll need to do some kind of radius check? Not sure yet.

There still other issues to sort out also…