Visual Paradigm is a tool for modelling software applications, amongst other things. We use it in our Software Engineering course. In this article I’ll introduce a couple of the UML diagrams that we find most useful for modelling applications.
The example application I’ll be using is trivial, getting a simple character to move around in response to user input in the Godot Game Engine.
I have come up with some simple requirements for this game
Game (2D) for Godot Game Engine
Character moved around field by user input
- Character is represented by a simple graphic
- Field is game area of defined size (1024 x 600)
- Input is via keyboard arrow keys
Use Case Diagram
A use case is a simple graphic that shows what the user (Player) can do. In this case there is only one thing – move the character by pressing keys on the keyboard. The Use Case diagram from Visual Paradigm looks like this
For this simple game there are only two classes involved. The Sprite class is a predefined class in Godot that has an image texture which is displayed on the screen. It also has a position represented by an x (horizontal) value and y (vertical) value. The Input class is a predefined class in Godot that detects user events such as key presses. It has a bunch of methods that other scripts can use to find out if certain events have occurred. We’ll be asking it if each of the arrow keys has been pressed.
This is another UML diagram, created in Visual Paradigm, showing the sequence of events that occur when a use case is executing. It shows the messages passed between the actor (player) and the various objects in the game. The code will be executed each frame of the game, generally 60 fps, which is why it is in a loop. The Sprite checks with the Input to see if certain keys have been pressed, and if so adjusts its position on the screen.
I’ve created a new game in Godot, with a single scene, which has a Sprite. You can see this in the top left panel which shows the various objects in the scene. I’ve used the default Godot icon as the texture for my sprite. The larger rectangular outline that the sprite is inside of (not it’s immediate bounding bosx) is the bounds of the game, which I’ve set to 1024 x 600 in the Project Settings.
I’ve attached a script to the sprite, which provides custom functionality. Technically this makes our sprite a subclass of the Sprite class. In this case the code checks with the Input object to see if each of the arrow keys has been pressed. The position of the sprite is represented by two numbers, x – how far across from the left edge it is, and y – how far down from the top it is. So if the left key is pressed we need to decrease the x position, if the down key is pressed we need to increase the y position, etc.
The function _process executes every frame, about 60 times per second, so as long as the game is running the code checks for key presses and moves the sprite accordingly. We need to multiply our adjustment otherwise the sprite would only be changing by one pixel each frame, which is a bit slow.
And Here It Is
No action though, just a screenshot
This simple example demonstrates the use of Visual Paradigm and the UML tools to help design an application (in this case a game), and then implement it using the Godot game engine.