So today I'm writing a bit about event CG. But you can't start talking about event CG without considering what the alternative to event CG is, and that is almost always sprites in front of backgrounds. These are the foundation of virtually all VNs, because they "only" require initial effort, and then can be used for the rest of the game. Sprites and backgrounds will, in a long, not ridiculously-budgeted game, always be your basic bread and butter.
Of course, when everything is the same sprites and backgrounds over and over again, it's hardly exciting. That's where event CG comes into play. Basically, an event CG is something that is specifically created for an event in the game, something that is not universally usable or modular. But as we found out, determining when to use and when not to use an event CG is not as easy as it sounds.
We had two lines of thinking in the dev team: One saying that event CG should be less specific and more universally usable, and one saying that it should be very specific to get maximum impact from them when they happen. Much discussion was spent on this, and we ended up trying both. As always, it became apparent that both had their downsides as well - the real "bulky" scenes in the game are dialog scenes, and spending event CG on those seems less than ideal, because you could have done them with sprites. However, the other way, making an event CG for every "non-generic" happening, is just not possible — Ideally, you would do the entire game with nothing but event CG, and it would always fit without ever getting boring (and some games indeed do just that). But event CGs are "expensive", if not in money, at least in effort. So you will never have as many as you would like.
Basically, there are two types of scenes that are even considered for event CGs: Important ones that deserve the additional visual impact, and ones that just cannot be visualized otherwise. If those were always the same, it would be easier. However, the smaller the amount of CG you want to spend, the more they drift apart, to the point where you have to cut corners for the sake of feasibility. So some kind of abstraction, instances where something in the text is just impossible to visualize, will definitely happen. And sadly, eventually you have the choice between doing something that "deserves" an event CG but could be done without it and something that will have problems with the visual representation but isn't really important enough - and in this case, the latter will probably be the one that gets chosen.
Now, what did we end up with? We did not even have the (not that deep, to be honest) realizations above early on, so what we decided on was to let the writers decide where they want event CG. Which sometimes worked, sometimes didn't. But what can you do? Basically you only really realize you need an event CG when you try directing a scene with sprites and it just doesn't work. Then again, directing only happens when the scene is written, and the artists should already be working on the event CG. And sometimes you just have to bite the bullet and even drop text, as good as it may have been, just because it's not feasible in a visual novel. Of course, an experienced VN director could see those things coming (and an experienced writer would not write scenes that lead to the dilemma above), but I think all of us are more than ready to admit that we're just barely entering a level of experience that makes this possible. This is, in fact, a big part of the reason why the development process seems unrealistically slow sometimes.
But it's the way it is. We're still learning and trying new things every day. Not thinking in absolutes and theories, but in the compromises and realities of actually creating something. It's not always easy or fun, but it's what makes this project so interesting in the first place.
Today's blog art by our man to go to for emergency event CGs, climatic.
— delta
