I spent the past few days playing through some of the Smile Game Builder games now available. This is for the Top 5 Showcase video I’m planning. This isn’t as easy as it should be because many of them are really good games.
The list of games I’ve played or will be playing are (in no particular order yet):
The game won the Bitsummit Award in 2015, given to those stand-out games, and deservedly so! It’s a remarkable DLC with plenty unique animations and characters to use in your games.
All in all, this Smile Game Builder DLC is quite remarkable, notably for its animated motions, which are uniquely customized. It comes with 95 models in total including its color variations. And there are a few other surprises in it too, which I’ll let you discover on your own.
I would highly recommend this for all Iron Will fans, and those who aren’t familiar with it as well.
Smile Game Builder‘s built-in camera control is a very useful feature, especially when it comes to achieving certain map effects during the game.
Camera Settings Variables
In Advanced Variables, you can store the values of various camera settings into variables and reference them throughout.
In my tutorial on camera control, I comprehensively go through using the camera in Smile Game Builder, so I won’t dwell on that here.
I’d recommend watching the video first and returning to this article afterward.
As usual, an auto-run synchronize event containing the variables needs to be set up and placed on each of the maps you want to reference the camera settings.
All camera settings are set in one of three ways:
Game Data:Game Settings is used to create default settings that are then used globally across all maps.
Map Settings: Each map has individual Map Settings (right-click on the map name and select that option) and change the camera settings to whatever values you want. These override the default settings in Game Data for that map.
Auto-Run Event: You can set an auto-run triggered once event to change the camera settings manually. When the player enters the map, this event will automatically orientate the map to these settings.
Choose whichever method suits your game’s needs, depending on the effect you want to achieve. The first two methods are "fixed", so the map settings are automatically implemented for the maps. The third method, however, re-orientates towards these settings unless Camera Movement Time is set to 0 (which is instant) in the Camera Control command.
As you’d expect, Camera Settings – X and Camera Settings – Y store the X and Y angles of the camera respectively.
Camera X is governed by the keys for up (R) and down (F) and Camera Y uses the keys for rotating the camera left (Q) or right (E).
As an example (shown in Fig. 15), in Normal view on Sheet 1, a Variable Box Check is added to check if the Camera X variable is set to -48. If it is (under Yes), use the Camera Control command to change X’s camera angle to -89 for this example.
Similarly, on Sheet 2, do the same to check if its value equals -89 and reset X’s camera angle back to -48.
Bear in mind, however, that the above example (as with all the examples in this article) only applies to Normal view. Camera angles and their corresponding variables work differently when in First Person view, but I’ll cover that in one of the next tutorials in this series.
Camera XY Minimum and Maximum Values
The value stored in the variable for Camera X won’t go below -35 (which is an isometric view) or above -90 (which is directly overhead).
And for the Camera Y variable value, the range is 0 to 360.
Field of View
The Field of View (or FOV) is the telescopic distance in and out from the character. In other words, when you zoom in (with the C key), objects become closer and zooming out (with the V key) results in objects becoming farther away.
With the example in Fig. 16, on Sheet 1 is a Variable Box Check where the Field of View variable is smaller than 4. And if Yes, change the FOV to 0.5 in Camera Control to zoom right in.
On Sheet 2, likewise, if it’s equal to 1, the FOV is reset to 3.5 from within the Camera Control event command.
Note that, as with all instances of decimal fractions in Smile Game Builder, they’re rounded down. And, since the default FOV is 3.5, if you were to use that as a variable value, it would be recalibrated as 3. Hence, in the above example, the variable’s value is set slightly higher. With the Variable Box Check, numbers are either above or below, or equal to, their fixed values; they’re not inclusive, so setting a higher value is good practice anyway.
FOV Minimum and Maximum Values
When zooming in and out with the C and V keys, the range is 0 (really close) and 4 (slightly above).
This only applies to the FOV on the map; it doesn’t apply to any other camera settings for FOV because that’s separate.
The camera’s Distance only applies to Normal view. It measures the distance of the camera in relation to the character or a position on the map.
In the example in Fig. 17, I set up a Variable Box Check for checking if the Distance variable is "the same as" 71 (1 above the default distance) and, because in this instance it’s not (under No), the camera moves all the way above the scene and rotates as well. If the operator is set to "smaller" instead, this would return true (under Yes) and it just zooms in with the FOV.
Don’t forget that the Variable Box Check operators don’t include the numbers you set in its Value, so they always have to be one above or below the actual value you want to use.
The final part is the Camera Mode. This is to check whether you’re playing in Normal or First Person mode to create different effects for each.
A prime example of its use – in conjunction with Player Direction – is my tutorial on creating a Compass HUD that correctly moves with the player depending on whether Normal view or First Person mode is used.
As another example, with First Person mode, you can create an event sequence where the camera quickly rotates behind you (useful to add tension to horror games), which would be useless in Normal mode. For Normal mode, therefore, you’d simply create another appropriate camera effect.
To use it, the Variable Box Check would use the Camera Mode variable, set to the value corresponding to either Normal view (0) or First Person mode (1). Use one or the other, but remember the Yes/No order in the branch. If it’s set to either 0 or 1, that condition then becomes true or false when you switch between modes using the B key, so whatever is under Yes will activate, otherwise, whatever is under No will activate instead.
I generally tend to use 0 (Normal mode) to make it easier to reference. That means, I always know that 0 is Yes and 1 is No. But, of course, it’s a matter of preference as long as you know which is which.
If you use any other value, it won’t run properly because there are only two modes and Smile Game Builder will treat the variable’s value as though it’s a zero, i.e., Normal mode.
I haven’t decided on the topic of the next tutorial in this series yet, as there’s still plenty to cover in Advanced Variables.
That said, I may continue with Camera Settings, but using the variables in First Person mode since they work differently than with Normal view. Although I’d like to go through some of the others first before revisiting this subject, it’s going to be one of those "wait and see" things.
In Smile Game Builder, you can store and reference various character stats via Advanced Variables.
Under Character Information, you can store:
Experience: A character’s Level and Experience.
HP and MP: Current and maximum HP and MP.
Stats:Attack, Defense, Accuracy, Evasion and Agility.
Each stat is stored in a separate variable per character. If you intend on using all of them with a full party, you’d need to reserve 44 variables. And then with each additional recruitable character, you need 11 further variables.
Using Stat Variables
There are many possible applications for Character Information. I’ve already visited several in my Smile Game Builder Tutorials series, but here are a few more.
Creating Stat Based Skills
What if you wanted to create stat-based skills, such as Lockpicking or Dodging?
You’d first need to store each stat in a variable (as in Fig. 11) and then create separate skills based on those stats.
I also covered this in Tutorial #29, which deals with using skills with chests.
So, for the first one, Lockpicking, it can be based on Accuracy.
To What? would be the Lockpicking skill itself, How? would be set to the variable assigned to Accuracy, and Do What? would simply be Assign.
The next step for this example would be to create another Variable Box where Lockpicking is divided by the Fixed Value 2 (or whatever number you want for the division). The end result is that Lockpicking is equal to half of the character’s Accuracy.
Using the defaults at Level 1, Sion’s Accuracy is 95. Halved, the Lockpicking skill would be 47 because fractions are rounded down.
For the Dodge skill, in this example I’ve based it on Agility and Evasion.
Assign the Dodge variable to Agility (in the same way as with the Lockpicking skill) and add another Variable Box to add Evasion to that.
Evasion is primarily based on armor. Light armor would probably decrease Evasion because it’s easier for weapons to penetrate through. Heavy armor would increase Evasion, as it offers much more protection than light armor.
Thus, Evasion can be a negative number. Cloth armor, for example, since it offers very little protection, might have -3 Evasion. And when this is added to the Dodge skill, it is, of course, subtracted from the total.
You can change the Evasion rates in Stat Modifications for each piece of armor (in the Items tab).
Checking Stats for Success or Failure
Once you’ve set up the variables and skills, the next course of action would be a chance of success or failure.
Smile Game Builder doesn’t have a direct method of comparing one variable with another because the Variable Box Check uses fixed numbers only. This means that we have to use a kind of workaround.
Starting with Lockpicking, decide on the percentage of success beforehand. In this case, there will be a 50% chance to successfully pick the lock.
So, Variable Box Check is then used to determine if the Lockpicking skill is greater than the percentage. The Yes branch would, of course, contain the routine for opening the chest successfully. And the No branch would be for its failure.
The events containing this information need to be running automatically synchronized and put on each map you want to reference them.
You can create other stat-based skills in a similar fashion. For instance, Strength could be based on half the character’s Current HP. Or Intelligence could be based somewhat on Maximum MP.
At the moment, you can only store the character stats defined in the Game Data. It’s not possible (yet) to similarly store monster stats, so these would need to be defined separately for each monster on the maps for an ABS or similar system. They would either be fixed values or random numbers and then scaled by multiplying them with character level.
For the next tutorial, I’ll look at variables for Camera Settings and how they can be used for various purposes.
Smile Game Builder has been out for some time now. So, it’s inevitable that there would be a number of games available for it.
Sometime next week, I’ll be showcasing some of the games currently available in Smile Game Builder. This includes both free and paid games. These are all in English since I don’t speak Japanese, but a number of Japanese only games have been produced as well.
None of the games in the showcase is a full review; it’s simply a video providing details on the games, which I’ve ranked according to atmosphere, playability, storyline, and enjoyment.
I won’t spoil the "surprise" by listing the games; you’ll just have to watch the video when it’s uploaded.
Good news for Smile Game Builder users. The latest update is actually a significantly useful one.
You can now import OBJ models instead of just FBX ones. Using OBJ is less proprietary than FBX and more universal.
A plethora of programs exist, both online and as downloadable software, to create 3D objects and export them to OBJ format. So with this update (currently still in beta), it opens the doors to 3D model creation. Since I’m a 3D noob, even I’ll be able to start creating models.
The second update is being able to increase the terrain height to 20. Imagine huge mountains or dizzying skyscrapers in your game! And when you reach the top, it’ll give you a fresh perspective on everything below.
I’ve had to prioritize things and spent my days off and the entire weekend in discussions with sponsors; going through legalese for several contracts; editing, rewriting and expanding one of my old novellas and looking for a publisher for it; and catching up on some chores.
This week is my last week at work before I have 2½ weeks off. During that time, I will certainly be making up for lost time and producing much more content, notably for Smile Game Builder, both on the blog and with videos. However, I’ll most likely have some RPG Maker content as well at some point.
If you do have questions regarding SGB, however, feel free to message me on Twitter, Facebook or YouTube, and I’ll do my best to answer them.
For this week’s Smile Game Builder tutorial, I’m going through the process of creating a public game, from start to finish, once you’ve created your game.
This has been requested a number of times, so I thought I’d make a tutorial for it. Also included is the process of creating a distributable ZIP file or an executable auto-extract file.
In the next tutorial (if all goes well), I’ll show how you can use your mobile device as a gamepad to play Smile Game Builder games. I’ve tested a number of apps that can do this and have decided on the best and easiest to use.