Question: Game for SteamDeck

[d.mach]

I wonder if a Solar2D build game with “normal” touch functionality is automatically working on the touch screen on a Steam-Deck device?

Any info on this? Any help welcome!

Thank you!

[famousdoggstudios]

Not on SteamOS. I haven’t tried making linux builds but windows builds won’t work there for obvious reasons. On windeck, my games launch and run fine including touch

[d.mach]

Thanks for the info!

Do you have some information on what to look for when building for normal Steam releases with Solar2d? Are there any “pitfalls” ?

Thanks! Much appreciated!

[famousdoggstudios]

Hmm. We stopped pushing updates for our Steam titles some time back so I’m not current on the whole process. Basically once you get a grasp of how their different release channels, containers etc work, it’s pretty straightforward to use the SDK to deliver the payload and release your build.

I do remember that back in 2019-2020 when a lot of users still used to have AVG/Avast, there were issue with the antivirus flagging our exe so we reached out to Avast (I believe AVG use the same DB) and they gave us an FTP track to upload new builds to so that they could whitelist. This definitely helped because a fair number of users were previously approaching us with this issue.

Generally, I’d say stay clear of any shady websites that will invariably approach you to sell your keys through them and if you can add anything to your game that has a community element to it, do that as it really helps to maintain interest and engagement. We had a feature called LiveWire in both games that we published where we would push an encrypted level file from our server into the game once every month and this would be a like a limited-time competition event with a leaderboard and it used to always get some interesting discussion going on Steam Community and Discord.

Controller support helps too and invest time in some GIFs and quality banners/capsule images for the storefront.

All the best

Edit: just another word of advice if your game involves a lot of movement/scrolling-- the timer resolution is really bad with Solar2D and it doesn’t seem to vsync so you’ll get 64fps which means horrible stuttering on displays with a fixed 60Hz refresh rate. You can work around this by using an average fps calculation and then force a fixed time step instead of using delta-time. Should be much smoother this way

[anon63346430]

I guess the real question is, how big a market is this compared to mobile?

i.e. is it worth spending any time/resources on it?

[d.mach]

Thank you very much for your detailed answer and help! Much appreciated!

[d.mach]

Could you explain the 64fps problem and the fix for it in more details please?
My test game also has some issues in the simulator already and the final windows build also. It was a mobile game before and the mobile versions are running smoothly. It seems like it has to do with physics and collisions. For example I have a tower defense game with paths. You then can freely drag towers on the screen and a collision detecten prevents you from moving the draged objects “over” the paths. The collision detection stops the tower and just continues when you reach a free (without path) area with your finger on screen again.
BUT: In the Windows build, just like in the Simulator the towers start to flicker when a finger is moved over a path. As long as a finger is moved over a path and the collision detection is working the tower is starting to “flicker” and shown one time where it had stopped when hitting the path and one time over the path at the fingers position.

Could this be a problem related to frame rates?

[famousdoggstudios]

This problem is probably not related to frame pacing but could be related to Solar2D’s rendering pipeline and how sprites are batched.

The ideal workflow for games AFAIK would be that you have logical entities that you manipulate the parameters for in each update and then you update their “view” or sprites all in one go but Solar2D doesn’t work like that so if you assert a new position for a displayObject or translate it across the screen, the rendering occurs immediately from what I know and this can be a problem when you want to check if a position is valid and only then move an object.

Are you able to make some modifications to your code where you can perhaps use a table that stores x, y coordinates and is associated with your display object being dragged and you can use the values from this table to first check if a position is valid and only then allow any movement on the actual display object? Sorry if I haven’t explained this very clearly but I think you’d get what I’m trying to say.

I had a vertical endless scroller where the character would run through a forest populated with trees and what was happening was that on collision with a tree/obstacle, the character would already have overlapped visually with said obstacle before my algorithm to prevent from overlapping could kick in and this led to flickering of sorts. What I did was to use a record of the x, y coordinates of the leading vertex of this character and checked collision on that point rather than the actual display object and this worked out okay for me.

[d.mach]

Thank you for your fast and long answer and help with the details. I will look into it. Much appreciated!

Have a great day!

[d.mach]

I did find a solution to fix it…

Let me explain: I am dragging a weapon on screen. When the weapon is hitting a path, the weapon normally is stopped while a collision object still is hovering over the path and when it enters a “free” area the weapon is following to this free position.
So I did set the weapon position to the position outside of the path, right before the collision started. And the weapon (which still was moved by the touch listener) started to flicker over the path (one time over path, one time last position outside of path).

This behavior started around two years ago with a new Solar2D build but did not appear on mobile devices.

NOW I have added the following code in the touchListeners “move” phase:

if holdWeaponInPlace==true then 
                    myWeapon.x=myWeapon.rangeCircle.x
                    myWeapon.y=myWeapon.rangeCircle.y
                end

right behind the mover function for the weapon. (The rangeCircle is positioned on the last pos of the weapon outside of the path before the collision was detected)
This code normally was run in a GameLoop with deltaTime where it still did result in a flickering weapon.

Run in the touchListeners “move” phase it now is working again as planned…

so maybe there was a change somewhere back in a build where a gameLoop function OR deltaTime and the touchListeners phases were changed somehow??? This would explain it.