"But it works on my PC" - sigh, the problem of solo developing....

Started by Matty, February 01, 2025, 10:56:52

Previous topic - Next topic

Matty

The massive pitfall of being a solo developer is that you have no idea if what you're building will run fine on someone else's machine.

I've had this issue on almost every release I had no Steam over the years, the worst being unprepared for different cultural settings on machines meaning text files read floating point numbers completely differently.

Worse than that is when some of your tools (Milkshape3d) export things perfectly fine, but decide to use absolute paths for the texture filenames in the exported files....and you can't work out why the textures don't show up when you move the game to another folder on your PC.

Having additional PCs to test on at least lets you know if what you're doing could be a problem.

On the older Android versions it's even worse with some companies using variants of the operating system that mean what works but shouldn't work according to the Android specification on one device will crash out on another.

It's one of those things I guess that you have to live with if you don't have people testing your games.....

It's just annoying to do a release only to find some blatantly obvious error crops up that would have easily been solved if you'd had a spare computer or two to test on with different settings.


Derron

If you grow into doing cross platform development you will learn the pitfalls (absolute paths, relative paths, "\" vs "/", user-writeable directories aka /home/username or c:\users\... ).
Similar to filename case sensitivity (on Linux and Mac you can have "file.txt" next to "FILE.txt" while on Windows it would ask you if you want to override a file :D) and son.

Next to os specific issues you will find backend specific issues (oh no... old intel IGP do not support OGL > 3.x --- which is why my elitebook of 2012 cannot run newer Blender --- on Windows! on Linux the driver supports the newer OGL and there it could work with some flaws).


If you develop for others:
- their locales can differ (like you identified, we Germans have "3,14" not "3.14" ...) and depending on your locale-awareness of the modules/libraries some might use and others even require it (eg run Excel ... and play with CSV data)
- their resolutions can be lower than your min resolution (happens more likely on ancient "casual gamer"/old people PCs ... so old 1200x800 res or hdready times on netbooks :D)
- their refresh rates can be higher (240hz screens ...) means you need to ensure running refresh rate independend logic
- their OS version can differ (I was blamed for no longer offering Win2000 support of TVTower... yeah.. .2000... same to say about incompatibilities with XP (which I still use here and there in a VM for building stuff)), newer Windows = sudden block of app activity or issues with networking ...
- their hardware locales can differ (keyboard - scancodes etc)
- their "computer performance" can differ (AV tools in the background, different CPU horse power, ...) - any "does not run smooth" is what they will blame to you :D
- too few horse power (or faster than yours!) can expose bugs in your engine (eg race condition issues / concurrent modifications in multi threading programs)
- inabilities of persons (color blindness, eye sight issues, deaf people ...)
- different locales requires different font rendering (what I mean is: if you offer the game in a language localization which writes from right to left or up to down etc...)

you wont be able to tackle everything ... but at least try to tackle what covers "the masses":
- it should run on Windows
- should be able to save (user profiles / locations...)
- should run windowed and fullscreen (non exclusive, just windowed-fullscreen)
- should display everything regardless of used resolution (no benefit of "bigger screens" in multiplayer games)
- should run on all locales

Dunno if others have to add important things (please do so if you have some).


bye
Ron

3DzForMe

@Derron, I recall the joy of transitioning from Windows operating systems when developing software. It may have been the transition from XP to 7.... more likely 7 to 10.

But the relative paths were a right headache. So, you've not only the disparate manufacturers to deal with, but dependant on the iteration of Windows, even within what you may think would be baked in backwards compatibility within Windows, nope! Glad I found skating... keeps me away from the keyboard these days.
BLitz3D, IDEal, AGK Studio, BMax, Java Code, Cerberus
Recent Hardware: Lenovo Re-furb'd Laptop
Oldest Hardware: Commodore Amiga 1200 with 1084S Monitor & Blitz Basic 2.1

RemiD

Quote from: Matty on February 01, 2025, 10:56:52On the older Android versions it's even worse with some companies using variants of the operating system that mean what works but shouldn't work according to the Android specification on one device will crash out on another.
let me give you an example where it is not even the OS version which caused the problem, but the way the user (me) configured the display :
on android smartphones, there is the option to increase / decrease the size of the text of the GUI, and also the option to 'zoom'.
if i remember correctly, the issue was caused by a too high zoom, which then hid a button of the GUI, and i was not able to go to the next step.
i thought that it was a bug in the app, but no ! it was the user's fault (my fault).
i figured this when i tried the same app on another smartphone (which had a normal 'zoom').