- Joined
- Jan 3, 2013
- Messages
- 577
- Reaction score
- 216
- First Language
- English
- Primarily Uses
- N/A
Hey there game designers. This is another tutorial on Game Design and how to structure our game in a way that we can get real feedback on our ideas.
This time I take you into the world of Scripting by showing you Systems Design. It's heavily related to scripting, but does not necessarily require scripting. However, a knowledge of scripting definitely helps.
1. The Basics
We need our flowchart software for this. Flowchart software is often times made for logic control of scripting, so it goes well here. Logic Control is just a fancy way of saying "Does this make sense?" and allows us to keep track of what all the code is leading to.
We also should have some drawing software in order to communicate our ideas. Our initial sketching of our ideas does not need to be perfect or polished, it just needs to communicate our idea. You can even use the flowchart software if you wish for this part.
Video Games and Programmed Systems are interesting. They're very contained, and constantly running while waiting for input from the player. I won't go too into detail, since this isn't programming class.
Just know that video games are unique software in that they're (surprise!) the most interactive software out there. They're constantly waiting for the player to give input, then responding to that input before returning information back to the player and waiting for input again. This is a constant cycle for video games. Your systems should reflect this.
2. The Process
The process of systems design is simple. Come up with an idea, then communicate the intricacies of that idea. In our case I'm going to create a simple Breeding menu that I came up with.
First, we access a menu system. That will be the start. What is the first input from the player in the menu? Well, how about we select the mother for breeding.
We need to do some stuff before we can do that though. First we have to draw the menu. Then, we have to populate the menu with suitable mothers to be bred with. As we change the information on screen we should represent this visually.
Now, I'll show you what the visual representation of this may look like:
<Pic 1A>
Here we can see the menus being created and then populated. A selection box is drawn around the first item in the menu. This is our most basic feedback and works perfectly fine. If you have strong programming skills you can also put any technical processes that might happen for your scripter to follow.
So what's next? Well, I felt that this wasn't enough info for the player. We should be able to select the monster, and then be given detailed statistics about that monster. Further, we should also be able to continue navigating the detailed window with the L/R buttons.
Here's what that looks like:
<Pic 1B>
Now we have a full display of the monsters stats and can make an informed decision. The menu should be waiting for confirmation or cancellation at this point. We should add an escape key input for the Mother population list. It's good to keep track of all our inputs expected from the game. Since the mother list is the first menu we see, it will likely be the exit portal through which we leave the menu. When exiting, we should purge the information collected during this whole process so that we have a clean start the next time we open up this menu.
The full build will now look a bit more complex, something like this:
This is not tracking the inputs we left out in our initial design and accounts for what they should do. This will give more information to the scripter and also show how the input in our game works. We now know what the system should and shouldn't do, and at what points it should do these things. We also know how to leave the menu at any given point, which is important.
So lets move on to the next step. What does the confirm key do after the mothers status card is shown? Well, we can make it automatically select that monster for breeding or we can add a confirm/cancel key. This is purely up to you, but I'm adding a confirm/cancel box just in case. Canceling returns you to the mother's status card. Here's the result:
<Pic 1C>
Now with the confirmation box out of the way lets decide what happens after we hit confirm.
At the bottom of the screen is another menu box. I added this because I wanted to use this space to display the choices the player has made as a way of giving feedback to the player.
We then will carry out the father selection very similar to the mother selection with a bit of a variance on where our escape inputs take us.
<Pic 2A>
<Pic 2B>
<Pic 2C>
Now, as you can see we have finished the father selection process which was simple because it was merely an extension of the mother selection process. Next, I want to display the output that can be expected from the two. This output gives the player an idea of what they'll create, which helps them feel like they're making an informed decision. If you want to you can always add variance so the final result is marginally different from the estimated result.
The breeding result is likely to be an involved process, and it's important that we clearly display what happens during that process before the Child result.
I have a special breeding process I want to have happen, and I display that in a list of processes that take place during creation of the Child and the acquisition of it's stats.
I then output the final results for the player to evaluate.
<Pic 3A>
The player is then allowed to confirm the end result or cancel it after reading the results and hitting the confirm key.
Confirming and canceling both result in a complete purge of the parent info. The child will either be saved separately for access by the player, or simply deleted. The end result will be a clean creation.
The final process looks something like this:
<Pic 3B>
The player is taken to Pic 1A at the end, which is the mother selection screen. There are plenty of text prompts we can add throughout, and tweaks we can make, but this is a great base to start off of.
3. Take Away
We have now put a abstract idea, like a breeding system, and put it into a visual, implementable result full of information and data that we can manipulate. Perhaps we find that the process of accessing the menus is tedious, and we need to add a button we can hit or hold to completely exit the menu. We'll expand on the diagram.
There's plenty of simple and easy tweaks we can do. These tweaks are easy to perform because we have the info right infront of us, and we can see the changes we'll make.
The most important thing when designing our systems is that we show what happens when a player makes an input, and we give the player information that shows their input was received and what the results of that input was.
This is what inherently makes video games interactive. A constant cycle of input and output around a system of constrained rulesets.
Skills can be designed in much the same way, as can a lot of menus, battle systems, mini-games and more. It's important that we understand the visual medium of our systems, and display that alongside the flow the system will take with each input by the player. When the game updates the information the player is seeing, we should be able to display that change.
This helps the scripter know when to update information and what that information needs to be.
This information can also make requesting scripts much easier, as the scripter will not be forced to do the design for you. It may even cut down on the price, as the scripter will not have to spend exorbitant amounts of time trying to figure out what you want and creating the rulesets and system for you.
4. Structure and Storage
We should store our system design in a separate set of subfolders near any scripts or scripting tools. It deserves it's own area. It's important that we make sure we reference other scripts and diagrams by their file names and/or folder names when needed. This allows us to quickly find and look up relevant documents that make up the structure of our game.
In this case, I suggest creating a folder called System Designs under a folder called Technical Designs. You generally want to store things about how your game works here. Rule sets, Systems and Scripts, for example.
Save the file as the working name of your system, followed by any other identifying data you need.
It's always a good idea to not overwrite documents with changes you make, and instead save the changes separately. You can always move the old versions to a new subfolder.
5. Conclusion
The take away handled a lot of the important information from this. I want you to take a look at your own systems and consider plotting them out in a design tool and seeing if they're coherent. Perhaps you'll find holes in your system you didn't know about.
Take your ideas and bring them to life with this method of design. If you're up for the task, show people in the Game Design forum your design and get feedback.
Try submitting scripting requests with a system design attached. See what the scripters say or how much quicker the request gets fulfilled.
The time you take to make your ideas real, to turn them into something you can get input and feedback on, and that you can manipulate directly shows a dedication to your work and product. It's the time we take in pre-production that determines the value of our production.
Take the time to plan out your game, it's systems, and how it works. This is merely one step in the arduous process of game design, and a great example of how we can communicate the abstract.
I'll try to bring you part two in a timely fashion.
Pt 2 will be focused on creating rulesets that make up our entire game. It's a far more abstract process but one that we can account for with good documentation.
Thank you for taking another journey with me through the art of design. We have plenty more things to discuss, and I hope to see you guys in the next Workshop!
Last edited:
