Why would instructions need to be read from a file? Wouldn't it be simpler to hard code the instructions, since each of the scripted sequences will stay the same? It would improve performance too since there wouldn't be any file io.

Are there any significant drawbacks to this approach versus using a scripting language, or is it manageable given the scope of my requirements?

The general benefit of reading scripts (and configuration data) from a file rather than being hard-coded is that changes do not require your entire program to be rebuilt for every change (scripting can even be implemented in such a way that you can modify and re-run scripts without even stopping the program), and that scripts are "sandboxed" -- that is, the only actions exposed to the script are safe, and can't make mistakes or take harmful actions that could destabilize the program or overwrite important data. As a single developer, that second part is perhaps less of a concern to you, but the the first part helps reduce your iteration time (time to identify problems, make changes, and see results) for scripting sequences.

For very simple scripting activities such as moving characters around a screen, showing dialog, and setting or testing flags (as to indicate progression past a plot point, and testing for it later) those sorts of things can be done with a simple, command-based scripting language. This kind of language generally has one command per line in a text file, where the first word is a verb (some kind of action to undertake), and the remainder of the line serves as parameters -- this is basically like a function call.

A simple script might look like:

MOVE Goku, Slow, 10, 0, 0, 0
TALK Goku, "Hi Master Roshi!"
TALK Roshi, "Goku! Piccolo needs your help!"
TALK Goku, "OK!"
MOVE Goku, Fast, 0, 0, 20, 0

Its not difficult to write a simple script interpreter, especially in a language like Java that has good support for Regex. In your code, you need a means of parsing the file to recognize commands, classes and methods to implement those commands, and a system for dispatching those commands. Depending how you handle movement and how fine a control you want, and how hands-free you want your script to be, you might need to implement some basic "concurrency" so that commands can complete simultaneously (as in, two characters can move at the same time, rather than in order). Timing also plays a big part in scripting, so you'll want to build in various pauses, delays, timers, and time-based triggers into your system. Many kinds of scripting languages employ the Actor model and/or some form of coroutines, which form the basis for concurrency and timing.

When you want to talk about moving game logic into scripts (again, to reduce turn-around time) then you definitely want to look into readily-available scripting languages like Lua, unless you actually have an interested in building a scripting language of your own (And if you have no interest at all, even to build a simple, command-based scripting language, you might want to adopt something like Lua regardless). Lua is generally considered to be a simple and effective scripting language for games, and its widely used -- I'm not sure what its Java binding story is though. If Lua is too complex, Java/TCL (Wikipedia) [project homepage] is a command-based scripting language that can be embedded into your Java application.

Finally, you don't *have* to use a scripting language if you're willing to forego its advantages with regard to iteration speed, security, and flexibility. What that generally looks like is that you provide yourself an API that does all the common things you want to do in your cut-scenes, and then you have methods that correspond to each scripted sequence that linearly call those functions; In this approach you don't need to implement value setting and testing because you can rely on the language's normal operations and flow-control. You can even use the language's timing primitives to an extent, but you probably don't want timing to block your thread -- you'll probably need to provide a non-blocking system eventually, and you might find a library or framework (again, "Actor Model") that does this and more for you, if you don't want to write it yourself.