Abstract
Introduction
Project overview and objectives
Software used
- Unity engine
- Inkscape
Existing simulators and field research
Simulator examples
- Simulator main features
I had no prior knowledge of it, but I mainly used it to create sprites for the simulator such as port symbols, buttons and backgrounds. This one looks pretty simple, but it's surprisingly easy to use, the symbols are large and well represented. It lets the player move elements around the stage in groups, and on a larger scale this feature is necessary for large and complex digital circuits.
Visibility of joints: when connecting and removing wires, it is important that the joints to which the wires are connected are always visible and easily recognizable. Libraries: to drag and drop elements from a UI component into the workspace, usually components are inside arrays, such as logic gates, inputs, and outputs.
Simulator features flaws
- Library cluster
- Slow workflow
- Lack of interactivity
This in itself is not an undesirable characteristic, but there is room for improvement. One of the ways to organize elements in a user interface is to use a tab system. This system works well for large groups of elements, but is not user-friendly if the elements have a wide variety of functions.
When you're looking for the type of door you're looking for, because all the items are crammed together, it's hard to identify the door because it's hidden in tabs. The user will use the same set of primary ports, inputs, and outputs most of the time, so there is no difference between the items that are used the most and the items that are hardly ever used. Most simulators lack a sense of interaction when the user does things, for example when the user makes a change to a door or presses a button or moves items around the scene, there is no feedback.
UX design process
Design objectives
- Addressing user’s actions
There is no easier way to drag and drop elements than simply moving them wherever the user wants with the mouse. As for the others, I have decided that such actions will be performed through a user interface (UI). I decided to group the add, delete, and edit actions in the same UI panel because they are all equally important and will be used equally by the user.
The UI will appear right at the position of the mouse cursor when the player presses the right button on an element or on the background space. The reason for this is that the panel where the user will edit, add, edit or delete the elements will be right next to the mouse position. Therefore, he does not need to look at another separate part of the screen, and does not need to move the mouse too much, which reduces the time the user spends on performing actions.
Panels layout design
- Layout distribution
- Layout population
- Layout position
We don't need to address the drag and drop action due to its nature. It takes up very little space because the options are displayed when the user interacts with the menu. Radial UI: This layout works well for a finite number of elements, and is very easy and intuitive to use.
These examples are the ones I considered most relevant when it comes to responding to the design goals I proposed. This makes sense since the actions are about this element, and the user doesn't have to drag the mouse around the screen every time he wants to edit an element. There is the same distance for the mouse to get to each element due to the radial layout, and as mentioned earlier, I consider each action editing, adding and deleting equally important.
Simulator specific panels
- Add Wheel Panel
- Control Wheel Panel
This wheel will appear on the mouse position when the user has pressed the right button on an empty space on the workspace. It is convenient that to add an element on the screen, you press on the position it should be. When one of the buttons is pressed, the wheel will disappear to allow the user to continue working and start editing the instantiated element.
This wheel will spawn when the user presses the right button on an existing gate, it is intuitive that this panel appears when the user wants to modify an element that he clicks, the basic features are separated into sectors, to separate its functionality . This wheel contains more buttons and options than the "Add Wheel Panel" and it is also larger. This certainly improves the workflow but at the same time it also limits the number of actions the user can perform.
User actions and controls
Technical overview
Usage example
We can change that by pressing the right button on the desired port and button “3” will appear on the UI. The user will change the value in the top AND gate and then “OR” on the right. As we can see, this time the UI does not disappear after pressing the button and there is a third connection at the selected port.
We can go ahead and use the red button to delete the current port, duplicate it or even change the selected port type. To make things easier to see, we're going to change the vertical distance of the links to make it more visible and easier to use. To move elements around the canvas, drag and drop them with the pivot point on the door symbol.
Keep in mind that the blue outputs allow you to pull more than one wire from them, while the green inputs do not. To do this, we will press the left button on the link and drag it to the signal receiving link. Now we can continue to interact with the inputs and see what happens to the combinational circuit we have created.
Early definitions
Element hierarchy
- Logic gate object
Although these are very similar to the core elements of the simulator, in this case I am referring to the specific connections of a specific element and a specific piece of logic on this element. It has three children, Body, which represents the white square, and parents Inputs and Outputs, each containing its own prefab. At runtime, this component will simply have a specific gate type selected, say an AND logic gate, then with this information the prefab itself will change the I/O configuration.
The white square will turn into a logical AND gate shape sprite, and it will also have an AND logic associated with it. When the object detects that its inputs are attached, it will have an output signal with an expected AND behavior. If let's say the configuration is now set to one input, the gate will simply change the logic from AND behavior to only output a high/low signal.
It removes the input connection and enables the toggle function, allowing the user to change the value as desired. If it is a door it means it refers to the script and if it is a gate it refers to the object on stage. There are no high or low voltages carrying information over a wire to the next logic gate, just a series of scripts working together to make it look like a digital circuit is running.
DoorManager.cs and DoorLogic.cs are both an essential part of the whole system, but to be able to explain them properly, the other, more type-specific scripts must be shown first. For now let's say that DoorManager.cs manages the configuration of the door, the number of I/O, the selection of the logic type and the changes of all these variables at runtime. The most important part of Body is that it has an added component which is a PolygonCollider2D, a Sprite Renderer and a custom Dragger script.
A PolygonCollider2D will be used to detect mouse input and a SpriteRenderer to display the logic gate type.
Script management
- Connections custom script
- Wire custom script
- Gate Logic custom script
- Door Logic custom script
- Door Manager custom script
- DoorTypes ScriptableObject custom script
- Dragger custom script
Updates the attached output's references so that the output knows that it is also connected to the input. We will clarify this later when we delve into the simulator logic management. Now let's take a look at the output connector inspector window for the INPUT switch port.
So we should see that the list has one element, Input(Clone), which means it is holding the reference to the NOT gate input. In this script we can see that the Reference has an Output(Clone) which is the output reference attached to the INPUT port. This script is just a class handler for defining logical states, and a reset, setter, and getter method.
Respond to the Connections.cs flag being enabled, so that whenever there is a new connection on its port, it will attempt to perform the port logic. So if the logic check is true, meaning the door is passing logic, it will update the logic of the attached elements of the other doors. But the other input of the gate is not connected, which means it should not emit an active signal at the output.
DoorTypes stores the reference of the selected door type that will be the gate at runtime. When this object is enabled in the scene, meaning it is instantiated when it is added or when the simulator starts, it will first check for incompatibility of the parameters in the inspector. So basically in this script we keep most possible configuration and default parameters that are accepted depending on the port type.
First and most obvious, it changes the position of the dragged gate around the scene. In this image there is a visual representation of one of the four sections into which I have divided the space. In this position, the control point P1 will always be to the right of the output P0.
