Heretic's Animated Title Scenes with Events
Authors: Heretic
Version: 1.02
Type: Customized Title Screen
Key Term: Title / Save / Load / GameOver Add-on
IntroductionThis script will allow you to fully animate your Title Screens using just Events! By using Events, you can also set up a Prologue for your Story, or show off certain elements of your game. Eventing a Demo for the style of gameplay can be very useful if you Custom Battle System that you want to show off, or some other elements that you feel should be Demonstrated.
The only limits are your imagination, and, how much caffeine you have in your blood stream!
Features
- Minimal Scripting Required
- Simplifies Customizations to the Title Screen
- Allows Custom Pre Load Screen Logos via Events - Crapcom - See Demo
- Fullscreen on Load (optional) - Its like 4 lines of code to do that...
- Sometimes, I dream about cheese, and wonder if people read the features
- Title Menu will fade out if Inactive (Customize the Time)
- Events allow Title Animations to be Skipped
ScreenshotsThe words "Game Title Goes Here" are In Game Pictures that are also Animated using just Events.
(http://downloads.chaos-project.com/heretic86/images/CollectionTitle.jpg)
(The Image is from Heretic's Collection, but works the exact same way.)
Demohttp://downloads.chaos-project.com/heretic86/AnimatedTitleScene-TimedUserInput1.02.exe
(Dont start a New Game immediately to allow it to go into "Demo Mode".)
ScriptScript available in Demo. Due to some required eventing (see the big red letters above), Events should be considered as part of the script. Thus, both the Script and Events are necessary.
Put just above Main.
InstructionsYou'll need to configure the Script a bit.
When you start up your game, you'll jump straight into a Map instead of the Default Static Title Screen. The Map ID, X and Y coordinates will need to be set up for your game. The Map you land on is where you will use Events to set up your Title Screen. Use Autorun and Parallel Events.
Next, you need to be able to bring up the Title Menu. That is the New Game / Continue / Shutdown Menu. Do this from one of your Autorun or Parallel Events by running "display_title_menu" in a Script.
Important: The Menu will NOT be displayed unless you call display_title_menu in a Script!Only certain Maps are allowed to have the Title Menu be displayed. If you are not on one of those allowed Map ID's, then you will start the entire scene over. This allows the Player to press a key and exit the Demo of your game so they can actually start playing.
You'll need to put the allowed Map ID's to match however you have your game set up. I made it an Array so you can have several different Title Screens if you want.
The default setup is to change the Player's Graphic to None, but they can still move around. To stop the Player from moving around, set a Move Route for the Player to Wait X Frames, and enable Repeat. Checking Repeat should exclude the Player from interfering with Wait for Move's Completion. Alternatively, you can set the X, Y coordinates to a place the Player wont be able to move. If you dont want to use Tile Graphics, you can use Events and set the Opacity of whatever Non Passable Graphic to 0.
Everything else is up to you to make happen with Events!
CompatibilityProbably not compatible with scripts that modify Scene_Title. Some changes were made to Scene_Load, Scene_Map, and Scene_Battle via aliases, but should be highly compatible if placed above Main.
Order will be important. Any other Scripts that fully rewrite anything in Scene_Title, Scene_Map, or Scene_Battle need to be ABOVE this script. Any scripts that Alias any of those scenes should be able to go below safely.
Credits and Thanks
- Thanks to Blizzard just for being Blizzard!
Author's NotesThe Demo is cheesy. It is supposed to be.
--- Style ---
Style Choice is completely up to you.
What this Script does is to make Easy Animation Tools available to you. You can use Fullscreen Images, then have your Game Title come flying in by using Events to move multiple Pictures around, if you want. You can use a Static Image. You can resize your Logo. You can do it how ever you want. There is no need for the Player to ever see an In Game Map as your Title Screen, as that is a Style Choice. The Map just makes Eventing available, but Players dont have to see that it is a Map.
The Demo was required because some of the Eventing can be relatively difficult to pull off. It tries to provide examples of how to allow the Player to skip any Animations and bring up the Title Menu (New Game etc.) quickly. The aim of the Demo was to provide functionality through the Events to help you achieve skippable Title Animation Sequences. The only limitations you will have are what you can do with Eventing in RMXP.
--- Simulating Input ---
Diagostimo has given me permission to include an early version of a script for Simulating User Input, which is very useful for doing Demo's of scenes that are otherwise very difficult to get to work in Demo Mode, primarily, Battle Systems.
--- UPDATE (Wed, Apr 3rd, 2013) ---
I wrote an Add On to allow you to Mute Sounds and Sound Changes. I found this to be useful while having a game go into Demo Mode and not change the music, play Battle End Music or ANY Sound Effects. Since this scripts allows you full access to RMXP's Event System during your title, it is possible to change your Battle End Music to nil, but the game will still play Sound Effects from Animations. As a result, a script was necessary. So here you go.
This addon should function just fine as a Standalone Script, and I've tested this to make sure it is 100% compatible with DEE, Dynamic Sounds, and Ambient SFX by their various authors.
NOTE: This script is also available in the Demo.
#===============================================================================
#
# HERETIC'S MUTE DEMO SOUNDS
# Version 1.0
# Tuesday, March 19th, 2013
#
#===============================================================================
#
# Author: Heretic
# Date: Tuesday, March 19th, 2013
# Version 1.0
#
# This is just a little something I whipped together to allow Muting of Sound
# Effects for Demo Play. It can be used with BGM Music if you want.
#
# You dont need to create Events to change the BGM on a Map if you intend on
# using a Gameplay Map during Demo Play
#
# Instructions:
#
# Run any of these Script from any Script Box:
#
# - $game_system.mute_sound_effect = true / false (Any SE)
# - $game_system.mute_music_effect = true / false (End of Battles)
# - $game_system.prohibit_bgm_change = true / false (Dont Change the Music)
# - $game_system.prohibit_bgs_change = true / false (Dont Change the BG Sound)
#==============================================================================
# ** Game_System
#------------------------------------------------------------------------------
# This class handles data surrounding the system. Backround music, etc.
# is managed here as well. Refer to "$game_system" for the instance of
# this class.
#==============================================================================
class Game_System
#--------------------------------------------------------------------------
# * Public Instance Variables
#--------------------------------------------------------------------------
attr_accessor :magic_number # magic number
attr_accessor :mute_sound_effect # Mutes Sound Effects
attr_accessor :mute_music_effect # Mutes Battle Music Effects
attr_accessor :prohibit_bgm_change # Prevents BGM Autoplay on Map change
attr_accessor :prohibit_bgs_change # Prevents BGS Autoplay on Map change
#--------------------------------------------------------------------------
# * Object Initialization
#--------------------------------------------------------------------------
alias mute_demo_sound_initialize initialize
def initialize
# Call Original
mute_demo_sound_initialize
# New Properties
@mute_sound_effect = false
@mute_music_effect = false
@prohibit_bgm_change = false
@prohibit_bgm_change = false
end
#--------------------------------------------------------------------------
# * Play Background Music
# bgm : background music to be played
#--------------------------------------------------------------------------
alias prohibit_bgm_change_bgm_play bgm_play
def bgm_play(bgm)
# If Chaging the Background Music is Prohibited
if @prohibit_bgm_change
return
end
# Call Original
prohibit_bgm_change_bgm_play(bgm)
end
#--------------------------------------------------------------------------
# * Play Background Sound
# bgs : background sound to be played
#--------------------------------------------------------------------------
alias prohibit_bgs_change_bgs_play bgs_play
def bgs_play(bgs)
# If Chaging the Background Sound is Prohibited
if @prohibit_bgs_change
return
end
# Call Original
prohibit_bgs_change_bgs_play(bgs)
end
#--------------------------------------------------------------------------
# * Play Music Effect
# me : music effect to be played
#--------------------------------------------------------------------------
alias mute_music_effect_me_play me_play
def me_play(me)
# If Music Effects are Muted
if @mute_music_effect
Graphics.frame_reset
return
end
# Call Original
mute_music_effect_me_play(me)
end
#--------------------------------------------------------------------------
# * Play Sound Effect
# se : sound effect to be played
#--------------------------------------------------------------------------
alias mute_sound_effect_se_play se_play
def se_play(se)
# If Sound Effects are Muted
return if @mute_sound_effect
# Call Original
mute_sound_effect_se_play(se)
end
end
#==============================================================================
# ** Game_Map
#------------------------------------------------------------------------------
# This class handles the map. It includes scrolling and passable determining
# functions. Refer to "$game_map" for the instance of this class.
#==============================================================================
class Game_Map
#--------------------------------------------------------------------------
# * Automatically Change Background Music and Backround Sound
#--------------------------------------------------------------------------
def autoplay
if @map.autoplay_bgm and not $game_system.prohibit_bgm_change
$game_system.bgm_play(@map.bgm)
end
if @map.autoplay_bgs and not $game_system.prohibit_bgs_change
$game_system.bgs_play(@map.bgs)
end
end
end
#==============================================================================
# ** Audio Module
#------------------------------------------------------------------------------
# This Module handles Sound Effects for non Map or Evented Sound Changes.
# It allows for Muting Sounds that are played by Animations during Battles.
#==============================================================================
module Audio
# Prevent F-12 Crash
unless $heretic_audio_class_defined
# Dont run Module Audio again until next time Game is started.
$heretic_audio_class_defined = true
class << Audio
alias mute_sound_effects_se_play se_play
def se_play(name = "", volume = 100, pitch = 100)
# If Sound Effects are Muted
if $game_system.mute_sound_effect
return
end
# Call Original
mute_sound_effects_se_play(name, volume, pitch)
end
end
end
end
Nice this is a good way to do it :P
I personally just use a title skip script, and then event everything from there, but for those not as good at eventing things like that this will definately help, and have basically the same effect.
Thank you!
The title skip script is one way to do it, but not sure how well it would work for doing Demos of Battle Systems and what not. The script is aimed at those who are good at eventing, but arent great at scripting! Hopefully it will just make it easier for anyone to have a customized Title Screen however they wish over the default single Static Image with looping background music. That single image title always felt very limiting in what it allowed people to do. MOG's Animated Title Screen also on the Scripts Database has a dead link.
This script isnt quite perfect yet. I am running into some very odd things that appear to be intermittent, which makes it really hard to figure out what exactly is causing them. Let me know if you find any bugs, or especially compatability errors, and I'll do my best to resolve them!
I'm not exactly using it, but I played the demo and I enjoyed it actually lol. You made me realize though, that I need to find someway to disable that f12 thing lol. Since my game doesn't use scene title.
hmmm, i'm going to have to try this out, at the moment i got a scene title override that takes me to Scene_Map at the start meaning i can create a title screen from there (havn't started yet, still coding GUI for the XGrid) but this might cut down on some of my work
I've been going back and forth with diagostimo for the last couple of days, and he has built an amazing Auto Input Script that is so good that I am trying to encourage him to release it as a Standalone Script. Basically, all the screwy hacks and work-arounds I came up with to demo input and close the Msg Window are a pain in the ass. Basically, what his script allows you to do is to set up Key Presses and execute them at specific times. Much like Move Routes, but for Button Presses. Essencially, it makes Demos by scripted Key Presses possible for almost every script out there!
His script is a Work in Progress. He gave me permission to go public with it. There are a few bugs to iron out in it, and I've already been in contact with him about them. I added the comments until he gets around to a more official release of it. I've updated the Script very slightly to check for Fake Inputs and disregard them so they can be used during Demo's. I also remade the Demo Battle Sequence to only use his script for faking the keypresses, which I think looks better now since it shows menus.
Both Scripts are available in the updated demo. See the Link in the First Post.
Not to burst his bubble, but like this?
http://forum.chaos-project.com/index.php/topic,2310.0.html
Quickly glancing at the code, it is a better script, but I dont think I'd be able to make it compatible.
One of the things I did was to cause "expected" things to happen when the user presses a key. Such as, during the demo parts, any key presses will quickly switch back to the main title screen. Or if the title menu fades out, it brings the menu back up. So my difficulty was trying to detect the difference between a fake keypress and a real one, so the fake one wouldnt cause demo resets. Its not the easiest thing to use at the moment, but were workin on that.
If you need to differentiate whether a key trigger is fake or not, then there may be no point in using a script like this and you'd be better off directly executing whatever code you need. Or create a method that can be called directly or is called when a key is pressed normally.
Different things happen during the title screen depending on whether a key press is simulated (by the additional new script) or came from a Player.
That's exactly my point. If different things happen, then you don't need a key simulator since you're not using the code when the player presses the button anyway.
the whole purpose of the key simulator is mainly for reasons of this script, and compatibility overall, what the script does is forces input, so the input value checked returns true if it is forced, the reasoning for this is for the creation of demo's, you could initiate code to skip to all the to all the scenes and actions etc, but then the person viewing the system would be like, how do i do that :O, so basicly you can simulate a video of the gameplay, creating a list of inputs that are to be exicuted in the demo, and not allowing the user to contribute to these inputs, i found it easier to create fake inputs as to editing the update methods, as the update methods would have to be replaced to condition to your new methods/variable values where it checks for input, thus making it less compatible with other systems, there are probably multiple ways to go about it but mine is a way none the less :)
I am trying to say that if you have to differentiate between fake and real input, the whole input simulation thing loses its purpose. If it's fake, it's obviously executing completely different branches than the real ones so you can't even call it "input" anymore as it never executes the branches intended for actual input.
Im not sure I follow.
Is the name itself possibly implying something? Maybe "Simulated Input" would be better?
During the Title Screen and Demo, I still wanted the user to have a way to skip out of the Demo mode, similar to the style of old console games. So Real Input takes to the New Game / Continue window, or any modified versions of it. The Simulated Input was initially giving me some difficulty because Simulating Input was also causing the screen to zap back to the New Game / Continue screen. So, the only time I check for Simulated Input is before the game starts or is loaded. It might also help to know that I changed the Demo a bit. Version 1.0 did not show any menus. With the Simulated Input script, I changed it so instead of Eventing Forced Actions by the Actors and Enemies, they were left completely alone, and the script monkeyed with the input, and commands were selected by simulating interaction with the menus. If you want to see those "Demos", grab the download, fire it up, but do NOT press any keys! Be patient, the Demo part starts itself up about 10 seconds after the "New Game" screen initially pops up. Just let it do its thing!
The Demo here works as I expect it to, but Im not sure everyone totally gets what my idea of "expected" is. Hit a key during Demo Phase and go back to the New Game screen pretty much. But if you dont press any keys, the Title Screen fades out and either an example Prologue will come up, or a Map which leads to a Boss Battle to demonstrate the Battle Stuff itself. The Map is easily done by using Set Move Route, but when we get to the Battle Screen, then the Simulated Input is run. The Battle is actually real from the Engines point of view, but the Input is just simulated. So the Simulated Input moves thru the Menu and what not. This is all assuming the Player has not started the game yet and has not pressed any keys. During that Demo Battle, again, pressing a key by the player takes the player back to the New Game window. When the game is in "Demo Mode", hitting a key at any time, anywhere, for what ever reason, the game should take the player back to the screen they "want" to see, which is to start the game. That is pretty much the way that the old 16 bit generation consoles did a lot of their stuff, right?
Although Simulated Input is going to be its own script eventually, what I imagine it being used for would be also to create User Tutorials for other stuff with much less effort. For example, if someone came up with a Crafting System, and parts of it needed to be explained, it could be explained by showing the player by example, by Simulating Input for the Player.
I'll admit that doing a Demo for the Default Battle System is pretty well useless, it just shows that it is possible. I think eventually, it will be a much much cleaner solution than the cheap hacks I was coming up with, like $scene_start_phase4. But other people have worked really hard to create their own Battle Systems. Thus, if they wanted to do a Demo of their Battle System, or show off other features of their game, they could also do so by Simulating the Input in a Demo of their Battle Engine. The scripts will be different from project to project, but the Input will hopefully essentially be the same. Up, Down, Left, Right, Enter, and Cancel are usually used in every sort of game, thus, simulating that input for whatever purposes are felt they are needed for. The Input for RMXP is pretty much Universal, as is Simulating that Input! If Super Mario Bros were converted to run on RMXP, it could even work for demos for Super Mario Bros because the controls for that game correspond to the Universal Input.
I totally dont understand the point you are trying to make.
Quote from: Heretic86 on October 18, 2012, 04:40:18 am
and the script monkeyed with the input, and commands were selected by simulating interaction with the menus.
Ah, that is something else. Yes, maybe this kind of script would be simulated input. But you could also achieve the same effect with certain script calls. e.g. To changing the selected option in a window, it is enough to simply change the index (window.index = NEW_INDEX).
Quote from: Heretic86 on October 18, 2012, 04:40:18 am
or a Map which leads to a Boss Battle to demonstrate the Battle Stuff itself. The Map is easily done by using Set Move Route, but when we get to the Battle Screen, then the Simulated Input is run. The Battle is actually real from the Engines point of view, but the Input is just simulated. So the Simulated Input moves thru the Menu and what not.
Yes, this is something else. You are basically emulating the battle scene as if somebody was playing it.
Actually now that I think of it, maybe it would be much easier to simply prerecord a video here. O_o Never mind though, this is not the point of this script/topic/discussion.
I still believe that these things could be achieve through smart design, but that would include that the default scripts have been designed in such a way which is not the case. So a "Simulated input" script may really be the best way to do it in RMXP's case. You would only have to detect real input in your special method to exit all those animations or show the title menu. I understand now why you are trying to do what you are trying to do.
Quote from: Heretic86 on October 18, 2012, 04:40:18 am
Although Simulated Input is going to be its own script eventually, what I imagine it being used for would be also to create User Tutorials for other stuff with much less effort. For example, if someone came up with a Crafting System, and parts of it needed to be explained, it could be explained by showing the player by example, by Simulating Input for the Player.
I'm liking that idea.
Quote from: Heretic86 on October 18, 2012, 04:40:18 am
I'll admit that doing a Demo for the Default Battle System is pretty well useless, it just shows that it is possible. I think eventually, it will be a much much cleaner solution than the cheap hacks I was coming up with, like $scene_start_phase4. But other people have worked really hard to create their own Battle Systems. Thus, if they wanted to do a Demo of their Battle System, or show off other features of their game, they could also do so by Simulating the Input in a Demo of their Battle Engine. The scripts will be different from project to project, but the Input will hopefully essentially be the same. Up, Down, Left, Right, Enter, and Cancel are usually used in every sort of game, thus, simulating that input for whatever purposes are felt they are needed for. The Input for RMXP is pretty much Universal, as is Simulating that Input! If Super Mario Bros were converted to run on RMXP, it could even work for demos for Super Mario Bros because the controls for that game correspond to the Universal Input.
If you design it to work with generic keys such as where you simply tell the engine which key you want to activate/deactivate, then people will be able to use it with a custom input module without problems.
Quote from: Heretic86 on October 18, 2012, 04:40:18 am
I totally dont understand the point you are trying to make.
I didn't know how exactly you were using the simulated input. As I said, some things could have been done in different ways without having to resort to a script like that, but the possibilities it offers and the possible problems it can solve in advance make it a good idea after all.
I wasn't trying to discuss the idea of simulated input (which is a useful thing), I was trying to discuss the idea of why differentiate between real and fake input. But I can see now that this kind of hack may be the cleanest solution after all.
Thanks! I think what we are ending up doing is Brainstorming code, so there might yet still be better solutions.
We are having small degrees of difficulty with the script. First problem being is F12 crashes with a Stack Overflow. Is there a better way to do this that allows aliasing in Input?
module Input
class << self
I did manage to come up with a work around by nesting class << self inside a conditional branch by checking for const_esxists? but think that isnt the best way to do it.
Our next issue is trying to simplify this for users. Right now, it requres nested arrays. It messed me up quite a bit by doing [[[DOWN],20],[[C],]], but I did get it working. I was thinking of making each entry an object. Something to the effect of "add_sim_key(sim_input.new(wait,[button_array]))" or something to that effect (syntax might be off in that), and in the object using "def init(wait=0, *array)" to grab any keys ater waiting.
So for the sake of keeping it simple enough that non scripters can use the code, Im totally open to suggestions on how to make it as user friendly as possible! Thoughts on keeping it user friendly?
P.S. I did read your suggestions, but havent had time to try to implement your suggestions yet. Lots of stuff I totally was not aware of! Thank you for that!
Forget the F12 functionality. Best you/other people just use the F12 fix for that.
#==============================================================================
# F12 fix
#==============================================================================
if $game_exists
Thread.new {system('Game')}
exit
end
$game_exists = true
As for the implementation, why don't you make it like I did in my Custom Input Module? Just make an array of 256 elements and fill them up with "false". When you activate a button, you can simply called something like "press(Input::C)" and it would look like this:
def press(button)
@key_states[button] = true
end
Same with release().
def press(button)
@key_states[button] = false
end
Checking would be as simple as this.
def pressed?(button)
return @keys.include?(button)
end
As I said, check my input module, you can reuse a lot of that code to get things working smoothly. The best thing is that it will work universally. In normal RMXP, the buttons are given the values form 1 to 15 if I remember right while with a custom input module, it will use the values from 0 to 255 so it will always work.
Okay, weird question.
Event Scritps are intermittently hanging, but seem to resolve by putting something below them. print "foo" for example seems to hang, stuck on that in the script, but putting a comment below seems to resolve it.
print "foo"
# Comment makes the above work?
/scratches head...
I think this is what you are referring to? http://forum.chaos-project.com/index.php?topic=938.0
That fixes it. Super goofy, I've never had a project wig out like that on me before!
Minor Update:
I wrote an Add On for this script which allows you to mute or prevent any changes to Audio.
While messing around with a game I'm sort of working on, I decided that I didn't want Battle Sound Effects to play. This was normally impossible because the Sound Effects were playing from the Animations. So a script was necessary. It is intended as an Add On, however, it will function just fine as a standalone script. That Script is in the first post at the bottom.
Just to let you know, the demo link is broken
I know, server died. Putting up another copy of the Demo for it is on my "to do" list. For the time being, the Demo is still available as part of my "Collection" in my sig, which is soon to get a big ol' update.
Edit: Okay, uploaded to chaos-project (thanks Blizz!) and fixed the picture.