diceGameScalescript

So, now that I’ve completed BornCG’s great 3D game tutorial, I’m ready to set out on my own! Of course, I already mentioned what the game would be about, it is a remake of the classic “Ship, Captain, and Crew” dice game. I’ve already made a 2D version of this game as an Android app, but now I’m trying to develop some 3D skills by remaking the game using Godot’s 3D engine.

I have several goals for this game:

  1. 3D – I know, it seems kind of obvious, but I never made a 3D game on my own before! (No tutorial, help, etc.)
  2. Featuring all of my own 3D models – I want to personally build each 3D model to enhance my limited Low Poly Blender skills.
  3. Cross platform – I would like to be able to play this game on a Linux, Windows, and Android OS.
  4. Open Source – It is important to me that this project is open sourced to the public for any to view, edit, copy, and use. Perhaps my meager and fledgling skills will help some other newbie to create something better than I did.

So, with that in mind, my first goal was to tackle screen size. Once before, I made a 2D side scroller called Critical Velocity using the libGDX library, and I found out after I made the game that I needed to work out different screen sizes. It was really hard to do so after the fact, and so I wanted to start with that here, so I don’t run into the same problem.

I found several guides on how one might accomplish this in Godot. Some just moved the camera further or closer based on the size of the screen. Some used the stretch mode. Others scaled objects to meet the criteria. And yet others had different assets to use for various sizes. So, after viewing all three, here is what I came up with:

First, I made a global.gd script that is automatically loaded as soon as the game starts. It looks like this:

extends Node

var my_viewport_scale = 1
var actualScreenRatio = 1.777777
var numberOfPlayers = 1
var computerPlayer = 0

func _ready():
randomize()
var viewport = get_node(“/root”).get_children()[1].get_viewport_rect().size
# comment the below call for OS.get_screen_size() if you want to force a
# certain screen size. If this call is not commented out, it will use the
# native screen size of the device or computer, unless it is greater than
# the Godot project settings of 1920*1080.
viewport = OS.get_screen_size()
# print(viewport) # Reference only

actualScreenRatio = viewport.x / viewport.y

my_viewport_scale = viewport.y/1080

So, in this script, I am asking the operating system for the size of the screen. I am building the entire game in a 1920×1080 resolution, but I use this math to find the screen ratio, and the screen size. I then set a scale based on the y axis ( my research seemed to point to that one being the best to base off of, but I don’t know particularly why ). Once these variables are in place, I can put this at the beginning of any “scene” that I make:

func _ready():
# My way to change the scale for every screen size. This allows me to build
# in 1920 x 1080 resolution, and scale it for bigger or smaller displays.
# This works for both 16:9 and 4:3 screen ratios, although 4:3 may not have
# the proper look.
# Tested satisfactory on: 800×480, 854×480, 800×600, 960×540, 1024×600, 1280×768, 1280×720, 1280×800, 1824×1200, 1920×1080
# Did not work well on 1400×900.

var new_y_scale = get_node(“/root/global”).my_viewport_scale
var new_x_scale = new_y_scale

if get_node(“/root/global”).actualScreenRatio < 1.4 :
new_x_scale = new_y_scale * ((800/600) / get_node(“/root/global”).actualScreenRatio)
elif get_node(“/root/global”).actualScreenRatio < 1.61 :
new_x_scale = new_y_scale / (get_node(“/root/global”).actualScreenRatio/1.45)
elif get_node(“/root/global”).actualScreenRatio < 1.76 :
new_x_scale = new_y_scale / (get_node(“/root/global”).actualScreenRatio/1.54)
else :
new_x_scale = new_y_scale

get_node(“/root”).get_children()[1].set_scale(Vector2(new_x_scale,new_y_scale))
# print(get_node(“/root”).get_children()[1].get_scale()) # Reference only.

In the title screen scene, I use the “ready” function, which is called as soon as a scene launches, to set the scale of that scene/node. By doing this, everything in that scene is not directly scaled, but is automatically set to scale as the whole view is scaled. This saves me from scaling each object, but rather scaling the view as a whole. At least, as far as I understand it in my limited knowledge of Godot and 3D programming, and it seems to work well.

The key part being that I want to check the actual screens ratio. Once I have that actual ratio from the global script, I can edit the scenes scale to match (at least closely) the ratio of the screen, and scale appropriately. This allows the game to be viewed on a 4:3 ratio screen (like an older computer), and a 16:9 screen (like most phones and modern computers), and several odd phone screen sizes.

As you can see in my notes, I tested this out on various screen sizes, and it worked well on a lot of them. This does have one downside, as it will make some screen resolutions look “squished” a tiny bit. But, with my limited repository of Godot/3D knowledge, this will do for now.

Here is an example from a 3D scene, the game table:

func _ready():
var new_y_scale = get_node(“/root/global”).my_viewport_scale
var new_x_scale = new_y_scale
var new_z_scale = new_y_scale

if get_node(“/root/global”).actualScreenRatio < 1.4 :
new_x_scale = new_y_scale * ((800/600) / get_node(“/root/global”).actualScreenRatio)
elif get_node(“/root/global”).actualScreenRatio < 1.61 :
new_x_scale = new_y_scale / (get_node(“/root/global”).actualScreenRatio/1.45)
elif get_node(“/root/global”).actualScreenRatio < 1.76 :
new_x_scale = new_y_scale / (get_node(“/root/global”).actualScreenRatio/1.54)
else :
new_x_scale = new_y_scale

get_node(“/root”).get_children()[1].set_scale(Vector3(new_x_scale,new_y_scale,new_z_scale))
# And set the HUD scale…
get_node(“ControlHUD”).set_scale(Vector2(new_x_scale,new_y_scale))
get_node(“winControl”).set_scale(Vector2(new_x_scale,new_y_scale))
# print(get_node(“/root”).get_children()[1].get_scale()) # Reference only.

Most looks the same, with the addition of scaling the “HUD” display. In the 3D scene, I over-layed a control node with essentially a 2D scene where the controls and such are floating above the game and within view for the player to use. Of course there is also another axis to change, the “z” axis, which is added in as well.

So, perhaps there is a better way to do this, but it seems to work pretty well for me. I also don’t notice any sort of performance hit doing this, as it only scales once at the scene change, and the scenes seem to load instantly. So I’ll stick with this for now. If you want to check out the project as a whole, you can find it on my GitLab.

Linux – keep it simple.

Leave a Reply

Your email address will not be published. Required fields are marked *