SyntaxBomb - Indie Coders

In my opinion to reach a level that could be considered 'a pass mark' as a proper game of sorts the following (at least) needs to be polished and addressed:

1. Gui and Interface (finish the job and get it looking better).
2. Audio - especially the voice components.
3. Visual FX such as laser blasts etc - make them look better.

Assuming I was able to improve those three areas substantially then the game, in my opinion, could be really considered to be somewhat a 'proper game of sorts' rather than merely a proof of concept.

Frames on all panels now....I forgot to do it this morning for the top half of the screen....here we are:

Game Link: https://matty77.itch.io/conflict-3049

https://matty77.itch.io/conflict-3049

Game Link:https://matty77.itch.io/conflict-3049

Game Video: (updated) 

Hey, things seem to get in shape now ... nice!.

Regarding HUD/interface:
- Main-Menu button can be placed somewhere less "intrusive" ... buttom left, or so (small triangle-button with a red "power (|)"-symbol or so)
- "Eath" element does not need to have the "bottom panel" part ... simply let it "slide out" below the interaction button area ... it is just an "appendix information"
- between minimap and "interaction buttons" (on top of the "unit party frame element) there is a lot of space - there you could add little "trapezoid"-shaped icons (or more "right side diagonal shaped" buttons --- "|___\") which indicate "groups" you defined (if you remember my "ctrl + 1,2,3,4..." for marking a group and "1,2,3,4" (or mouse clicks on that new icons) for selecting a group
- right side of the interaction bar you could add another "/____|" like button/area/whatever which has a "!" icon or so and a click will move you on the screen to the next unit with problems (eg out of ammo ...).
- time/score - this can be on the top right or top left (there could also be the "power button ...") and use way less space!


Here is a mockup of a layout for top left (with interaction highlighted at the bottom - like uncollapsed message log or hovered power/Main menu button)



(edit: I added some color highlights to the "top" variant ... in your current interface this is the "dark orange stripe thing" which you could "repeat there" ... also extended it to the right to emphasize that it _could_ cover way more of the top screen - even ending in a similar "right top corner" if you have something to add there ... could be a spinning "globe" for the "earth  interaction button")


So where to place your eyes at: I used some "shadows" to indicate that things are "layered". These layers - if done also graphically, allow for "animations" ... like the interface building up during game start )extending from left to right, the right border element coming from the right .. just creating an "mechanical" appearance.
Also separation allows for easier effects for "hovered" states etc ... or "blinking" if something requires attention etc.

The buttons: for now the buttons have text in it ... If your units are distinguishable easily by their frames then "text" can be removed and only appear as little "unit tooltip" while dwelling with the mouse over it (after some sessions you know your units and then "text" just feels distracting and occupying valuable screen space).
"Tooltips" should always have a "skinned/themed appearance" - so they also have a tiny border with "screws/metal plates" etc - and they can contain the text about the unit in some "colored style" (you know ... hp, attack, damage - or maybe just "group xyz, 3 soldiers, 5 tanks, ...")


bye
Ron

Thanks Derron. Your image is a '404 file not found' for me, but otherwise I get the general idea of what you're saying. Thanks.  (EDIT - it showed as soon as I posted my reply...see it now thanks)

Yeah - there's always more to do, but it's coming along nicely. Thanks.

I created the frames for the buttons in Milkshape3d using the screen layout as a reference, then rendered it greyscale in blitz3d with lighting to get a heightmap image, then blended some textures into that heightmap, and finally added some gaussian blurred black underlay to the frame in paint.net.

Game Updated: https://matty77.itch.io/conflict-3049

There are some changes, enhancements and bug fixes...too many to list.

And video updated: 

In this video you can see the progress that was made in developing the game over the course of 1 month approximately.

Probably not going to be many uploads of either videos or new downloads for a couple of weeks because I've used up my internet usage cap early this month.  When that happens my already slow speed gets throttled so low it's almost impossible to do very much with.

Anecdote about some positive feedback received about my recent game from a member of the public.

I was at the shops today, talking with a young masseur who I sometimes get a massage from.  I showed her my recent RTS game I'm working on. First point - positive, enthusiastic response. Second point - "these are like the games my Dad used to play when I was a child". Hahhah - my games belong to a bygone era it seems, they're well received by some members of the public but as the masseur said, they belong to an era of gaming that her ancestors played, not her own era. I guess that's to be expected when they're made by someone who hasn't really played video games since the late 1990s.

A tactic I've not been able to pull off successfully though in theory it should work and be not difficult for a good player using the pause feature:

Surround your own base with a wall of tank traps at a certain distance from the base such that the base is totally impregnable, and then it just becomes a shooting gallery from inside the base.

I've not managed to do it...there's just too much chaos after a certain point makes it impossible for your soldiers to do their job under fire of building tank traps. It also requires moving around the map a heck of a lot, and even when paused - I'm not good at it. But I'm sure an experienced RTS player would have the ability to completely surround their own base with an impenetrable wall of tank traps.

Simply allow certain attacker units to destroy tank traps ... also tanks could shoot traps too ... it just takes a while.

AND ... if something can be destroyed from range... then your units will not be able to attack the attackers (range + range...so to say).


@ era
Yes, your game looks like the games of 15-20 years ago. More modern games will have more modern "looks" - something you cannot offer that easily as "one man show" (and also if you do not know how theses games play and look ). But players of 20yrs ago might still be players - and might not be caught from the "free 2 play" or "freemium" or ... games of today. - can be your benefit.


bye
Ron

If you want to look at the code and the shader code, but don't want to download the entire game, temporarily I have it available here:

Game Code and Shader Code

Note to self: This is an idea (while I'm at the library) of how to calculate a form of volumetric fog rendered over the landscape from a camera point that is above the landscape, such as in an rts like mine:

Basic premise/theory:

The color of each pixel is altered according to the following idea:
Sum of the 'fog density' between the ground plane and the height of the fog 'h' = total fog density at that pixel's position in the camera view.
Blend the fog color according to the density of the fog at that pixel with the polygon pixel as per the usual method.

Difficult part - calculating the total 'units' passed through of fog between ground plane and the height of the fog above the ground in a fast and efficient manner.

We can use simple pythagoras to work out the hypotenuse length of the ground plane to the edge of the fog height at that point like this:
angle = Atan2 ( camera.y - ground.y, distance (camera.xz,ground.xz)) = our angle of depression from the camera to the ground.

total distance from camera.xyz to ground.xyz at that pixel is 'L1'.

distance from ground.xyz to the edge of the fog height above the ground is "fog height" / sin(angle) = "HF1"

total units of fog passed through from the ground, through the fog, to the edge of the fog height is " L1 * HF1 / (camera.y - ground.y) " = FD (fog density)

Assuming a uniform fog density than we simply multiply FD by the colour of the fog and blend it with the polygon colour as normal.



That works fine...or it should in theory....BUT! - trigonometric functions are SLOW in a pixel shader....so what we need to do is the following:

Use a Taylor Series expansion for both the Atan2 and the Sin functions noting that with an RTS our angle is close to 45 degrees that we're looking down on the ground at.....

Then use the first two terms of both those series and use those values instead of the atan and sine functions.....Basically make two functions in your pixel shader called
approxatan2() and approxsine() which we pass through our values and get an approximate value back.....

Use Wolfram Alpha to look up the Taylor Series expansion for both those functions. (centred about pi/4)

That should be fast enough and only slightly inaccurate.

Potentially we can instead just use a lookuptable or simple interpolated equation to approximate fog density based on the relative camera to ground position.

Faster way again to calculate fog thickness at a pixel position given the camera pitch/yaw doesn't change:

Precalculate fog thickness at each pixel for a 16:9 display and put into an excel spreadsheet for each x/y.
Calculate a regression equation that links x/y -> fog thickness. Use that instead.

Precompute a fog thickness map

Since the RTS camera has a fixed pitch and height, precalculate fog thickness values once for each pixel and store them in a 2D fog density texture (LUT).
Then fetch the precomputed value in the shader via some texture lookup (thus eliminating runtime trigonometry altogether).
If dynamic height variation would be needed, interpolate between multiple precomputed LUTs.

Yet I guess a "formula" would be better.


Alternative to Taylor series:

atan2(y, x) ≈ π/4 * (y / (|x| + |y|)) (max error < 3%)
sin(x) ≈ x * (1 - x²/6) (valid near small angles)

In case of multiple terrain heights (not in there for now):
If fog is uniform, precompute fog density scaling factors per terrain height level and fetch them via a single texture lookup or fast linear interpolation instead of per-pixel computation.

If you have a depth buffer:
Use the buffer to approximate distance-based fog thickness rather than explicitly computing "L1". Difference between depth values of ground and camera provides a quick estimation of fog thickness.
Other speedups:
- calculate with lower resolution and sample it up (bilinear upscale or so)
- if different heights were used: reuse a previous calculation and blend things together (only recompute what is changed, "scroll" the rest)
- similar to font rendering you could consider storing the fog thickness as a signed distance field (SDF) in a texture

Just checked if SDF was useful for it - seems others use it too:
https://github.com/BentleyBlanks/FOW
more in depth:
https://bentleyblanks.github.io/2019/09/07/2019-09-07-Screen%20Space%20Fog%20of%20War/     (you need to translate that into English I guess)


other benefits of SDF:
https://shaderfun.com/2018/07/01/signed-distance-fields-part-7-some-simple-effects/


bye
Ron

Game Link: https://matty77.itch.io/conflict-3049

Coloured lights for explosions and lasers added.
GUI buttons have little graphical icons for each thing.
More sounds.
And other stuff...
Updated: