Iâm almost finishing my HUD implementation, was thinking in wait for UMG but i gave a shot in that Draw HUD thing. It is a very laborious and time consuming way, but I got a nice result with those draw textures + hit boxes. hope to update the project until this weekend!
If you add -umg in your editor shortcut target proprieties, you can enable the UMG widget they are building, i didnât had time to try it yet and people also said that it crashes a lot, but i will give a try this weekend
Thank you for the hint concerning UMG. I think I will try that as well.
I currently have a Coherent UI trial licence. That way I can probably find out what works best for me. Since I donât know anything about JavaScript and html the Coherent UI start was a little bumpy for me but there are probably some helpful tools out there.
I also worked a little on my HUD concept. This HUD is not functional yet. It consists simply of two textures on planes in front of the camera that do nothing but moving with the camera but the idea should become clear:
I plan to make the HUD screens rotatable around the screenâs Y-axis to control how much of the screen is occupied by the HUD. The left side is supposed to give feedback on the surroundings. The right side displays the player shipâs status.
The top of the screen will get something like 3D radar screen thing working as a mini map. The edges of the screen will probably get some kind of sci-fi projector things that look like projecting the HUD planes on the screen.
Nice, let me know if i can help you in something. In my personal opinion Coherent UI its not a plausible solution at all considering their subscription, still too much programming to do be done, for web designers its a ease way, but in general you will spend a lot of time doing things as you would in blueprints! Its being a little bit complicated to build the HUD natively with blueprints, but its working good so far.
Really awesome stuff i hope you keep the work up looks really promising!
And thx a lot for your tutorial!
I loved to play Nexus the Jupiter Incident its a shame that the sequel havenât gotten enough funding on kickstarter.
For me their video is pure inspiration:
Hey there your project is looking very impressive, I am actually working on a similar project myself, but currently im jsut focusing implementing hte shaders and art, I was wondering how are you planning on dealing with rendering large amounts of asteroids/rocks in the scene? Are u basically jsut going to use level streaming?
Thank you for the encouraging words.
Unfortunately I was very busy over the last 6 month so this project had to wait. I started working again over the holydays and updated the project to engine version 4.6. Interestingly my movement physics system is no longer working with this version and I have no idea why.
@: I will have a look at that. That might be very useful for me. Thank you very much.
@: I must admit I havenât really thought about that. I will probably try how far I can come with the least amount of work. The astroids for example are mostly clones with different transforms. I hope that rather few different objects and some LOD will be enough to ensure smooth framerates. Also space is rather empty, so the number of objects will probably not be that large.
I should probably mention that I will not create one large seamless world. Faster than light travel will basically mean reloading a different level blueprint. Flying for hours through large empty spaces would probably not be that interesting anyway.
It has been quite a while since my last real update. I spend a lot of work on improving the code. Everything is more organized and easier to work with. Unfortunately it is not possible to show that in a video so I created a few new assets that are visible. Here is the video:
As you can see I experimented with a shader for planets. It is not perfect yet but I am quite happy with what I got so far. It is not visible in the video because the planets are rotating too slowly but the lights on the planets switch on/off when the terminator is moving across them.
After adding the planets I realized that I would need some kind of indication of movement in front of the camera since the planets are so huge and so far away that it seemed that the ship was not moving at all. So I added these little dust cloud particles that move past the camera relative the the controlled ships velocity. It might be hard to see in the compressed video but creates a much better illusion of movement.
The skybox is bought on the marketplace.
The ship engines also got a particle effect. That one is really basic so far and only a placeholder until I figure out how to make something more pretty.
There are also some obvious changes to the HUD. The small âTarget HUDâ will be used for quick interaction with objects while the âSide HUDâ will be used mainly for providing information to the player. Unfortunately I was not able to make the HUD on the side interactive. It is a Widget Component attached to the camera but it ignores all input so far. However, since that feature is still experimental I decided not to put too much effort into that right now and focus on other things. If someone has an idea why it is not accepting input I would be grateful.
I am not exactly sure what will be done next but I plan to test a few gameplay ideas and see how they work, and -as always- fix bugs.
I put a little work into the damage system and came up with something that will fit nicely into the concept of position and orientation dependent combat. At least I hope it will.
The main idea is that a ship uses shield generators to defend itself. These are small objects attached to sockets of the main ship mesh. Every generator has a certain angle it can cover. If an incoming projectile hits the shield at a position covered by a shield generator the projectile is deflected by the shield. The small blue parts of the generator mesh light up to give visual feedback which generator deflected the projectile.
By deflecting the projectile the shield consumes power which must be recharged before it can deflect another projectile. To recharge itself it must request power from an ship-wide power generator that is producing energy at a fixed rate. If energy is available the shield recharges, if not it can retry after a grace period.
This mechanic would allow the player to defend fragile portions of the ship by multiple shield generators to keep the downtime between requesting energy and granting energy by the power generator as small as possible.
Shield Generators also have impact on the offensive capabilities of a ship. To fire a turret the ship must check if the projectile would hit one of the shipâs own shields. If it would the corresponding shield generator ist deactivated for a few seconds. (Indicated by red glowing parts.) While the shield is deactivated the ship is obviously vulnerable from that direction. This makes it crucial to distribute shield generators cleverly across the ships hull and position the ship itself correctly to fight enemies effectively.
Prototypes of all the related components are finished. The shield shader has still a few seams but it should be fine for demonstrating the underlying principle.
After all these words - here is a video that shows how everything would look like.
I did not yet decide what will be done next. I already have a few ideas how to handle damage by projectiles that did not get deflected. Maybe I will get that working.
As you can see there is a lot of unfinished stuff going on. The HUD mesh is not textured yet and the the Buttons are not aligned with the mesh yet. Also, the emissive parts of the HUD are a little too bright but it should be enough to get the idea.
The small wireframe ship in the HUD gives feedback on the shipâs shield status and the moving bars next to it show which icon indicates the corresponding shield power.
I also added the awesome FX Star Starter Pack from JBaldwin which is visible in the background and the Advanced Laser Decal System from Devero (not visible in the picture but it is fun to blow âholesâ in ships. Even if they are just decals.).
I hope I will make some progress until next weekend and be able to make a new video.
The main improvement is a functional 3D HUD. (At least the bottom part is working. The stuff on the right sight is still just some concept stuff.) It turned out to be quite tricky give the player clear feedback on what is happening to his ship due to the fact that the orientation of the ship is crucial for the efficiency of the ship. I decided to use a small rotating wireframe model of the controlled ship with highlighted positions of the critical modules. In this case the shield modules. Everytime something happens to a shield generator on the ship the corresponding sphere on the wireframe model lights up. The icons on the left side give more detailed feedback. In this case a small progress bar indicating the power level of the corresponding shield generator. To make association of the icon with the shield generator easier a small status light lights up everytime the generator changes its state. I will add optional lines that connect the icon with the wireframe model (as shown in the screenshot from last week) but my current implementation of that feature gets completely messed up when the resolution changes. So I put that one on ice for a while because trying to figure out what was wrong gave me headaches:)
The horizontal bars at the bottom indicate the available power in the power generator. It goes down when the shield generators request power and then refills itself over time.
The small vertical bar next to the wireframe model indicates the hull integrity of the ship. When the hull integrity falls below a certain value modules will take damage. An interface for showing module damage is not implemented but I will probably color parts of the wireframe red when that section is damaged.
When using the HUD I realized that the icons and the small lights could be a bit larger. I will change that at some point but for now I will focus on a working prototype.
There are also a lot of other changes: I added sound effects and improved the atmosphere material. It is still not perfect but I somehow liked the surreal look of the planets.
I also started working on a demo mission that I will use for showing and testing gameplay. It is still a long way but I think I can do it in two to three weeks.
Unfortunatly I have nothing new to show. I ran into some difficulties upgrading from 4.7 preview to 4.7 resulting in apparently random crashes of the editor. I was not able to find out what is causing the crashes or how to reproduce them but it looks like it is caused by one of the blueprint in my main class hierachy. Since I do not want to rebuild each and every blueprint in that hierachy (I tried reparenting without success), I decided to implement most logic in C++ and stick with Blueprints for the top logic layer only.
However, I am not an experienced C++ programmer and I expect the transition to C++ to take a few weeks. At least for some parts of the game logic this will be a good decision. For example the way I emplemented the targeting system in blueprints could easily lead to problems if too many objects are involved.
Thank you. Almost everything is done with Blueprints. It is definitivly possible to make complex games without ever touching C++ code. I have a small C++ function in there that takes care of the correct rotation of ships by applying torque on a rigid body. That function involes a little bit of math which can become complicated in blueprint. Although I think the custom Math node that was not available when I started would make life easier today.
The downside of blueprints is that if something goes wrong, you are a bit lost. I am not sure if there is a way to restore corrupted blueprints but I donât think there is. So make sure to commit changes to a version control system frequently.
Really impressed by your skybox. How did you go about that? Most star boxes Iâve seen around for Unreal are all so dark and dull, but yours really pops. Love the stylized nature of it.
