Friday, June 23, 2017

Copierre, Portraits finished(?)

Hopefully I'm done with my primary art responsibility. I'm only experienced with drawing standalone images, like most amateur artists, and it's really apparent with these portraits. Hopefully it doesn't bother me too much, because I really can't waste more time than I already have on these. ..And they have.

Thursday, June 15, 2017

Copierre, Scripting

The programming side of the project is interesting in some ways. Most of the game takes place on the map screen, with the majority of the scripts affecting Scene_Map.

Third-party plugins

By default, RM isn't capable of creating instances of events, so I use Hudell's Orange Custom Events to gain this functionality. I believe there's still a performance issue with the plugin when spawning roughly over 4000 events. If it becomes an issue, I'll likely switch to creating and managing my own Sprite class, rather than using map events. I'm already familiar with doing that from the (now abandoned) shmup project, so it wouldn't be that big of a deal. It'd likely only be a day or so of work, but I'm not sure if I'm going to create any stage that will reach that unit count, so hopefully I won't need to.

And, of course, I'm using a ton of Yanfly plugins. He just puts in so much work for the community, and it's insane. Several things I'm even remotely in need of, and he's already made a plugin for it. I primarily make use of his Skill Learn plugin to have a stat point allocation system, and his Item Synthesis plugin for equipment crafting. Once I've created a stage or two to personally playtest as a player, I'll see if I want to have anything more intricate to the equipment system, like an enchanting/enhancing system or whatever. If so, I'd be using his Attachable Augments or Item Upgrades plugins.


I've played a lot of defense maps back when SCBW was all the rage. When it comes to the pathing for defense maps, there are two different pathing types: dynamic paths and predefined paths. It would be pretty interesting to create a dynamic path game, because those are the ones I'm most fond of. From the player perspective, they get much more freedom in how they'd like to create their defense. It's really interesting to see people's take on things in these types of defense maps. And from the developer perspective, I've seen and studied a lot of different pathing algorithms, and it would've been pretty cute to implement into RM.

And while I do prefer dynamic paths, I decided to go with pre-defined paths for this project. It makes it a lot easier for me, as the designer, to carefully balance each challenge to a suitable difficulty level. With dynamic paths, it's much more susceptible to game-breaking strategies. There are quirks to any pathing algorithm that leaves them susceptible to abuse. This then creates a huge gap between regular players and veteran players, and makes it incredibly hard to craft a challenging stage for all players.

Originally, I just designated particular regions on the map, and the spawned enemy event would readjust its route upon stepping inside a particular region. This is how waypoints worked in SCBW maps, and it worked out okay. The issue with this is that there then becomes a slight stutter (1 frame, to be precise), when an event reaches one of these regions. When events finish their given movement routes, they then run through their body code again to be assigned another movement route.

To deal with this movement stuttering, I decided to issue the entire path to events from the moment they spawn onto the map. And to do this more effectively, I made use of a pretty cute programming technique: dynamic programming. It's a programming technique where you record a previously calculated result, and use that saved data in the future to improve performance. So in this particular case, I save generated movement routes. Each time an event requests a movement route from a particular x,y coordinate, it first checks this 2D array. If there isn't a path stored for that map coordinate, then it'll run the pathing algorithm and save that new path into the array. If there is a path stored for that map coordinate, then it'll simply use that path, and no other operations are required.


I'm quite fond of RM's menu scenes, and windows, so for first few projects I plan to do, I'm likely sticking with a lot of the default menus. There are quite a few "portrait/picture menu" plugins out there, but I, for whatever reason, decided to write my own. I guess it helped me learn how to modify the menu scenes a lot more, with the Equipment screen being the most impressive result of it.

I modified the temporary stat comparison window to be quite different from the usual RM number display. By default, RM shows "original -> new(difference)". In my project, it's formatted like a typical math equation, so it shows "original + difference -> new".

Tuesday, June 13, 2017

Copierre - Visuals

This is the current look of the game. Complete in some ways, and far from complete in others. Here, I'll be talking about how we've split the asset work load between Fei and myself. I'd say I'm stronger with pure detailed, anatomical drawing, and Fei's much more familiar with creating cute and appealing art. That essentially determined who was tasked with what artwork.

Map sprites

Fei's done the entirety of the map tiles for the forest area. The water and ground tiles are more elaborate than I was intending to have in the game, honestly, but they do look nice. I'm likely going to be working on the next map's tiles. And since I value a fast project completion time above all else, it's likely going to be of much lower quality/detail than this forest area. Hopefully not that much worse.

For the monster sprites, Fei's done the slime and fairy sprites, and I've created the thicc treant and serpent boss sprite. Slime quite cute, and the tree quite curvy.

Fei did the swordsman's (fantastic), archer's and mage's sprites. The bard's probably my favorite in the party, though, so I took it upon myself to create her fun-loving, guitar-strumming sprite.

For battle animations or visual effects, I did the (god awful) archer hitspark and the blue flame upon monster death. Fei did the rest. I like the lightning bolt and the item bag drop. The bag drop reminds me of Legend of Mana, one of our favorite games.

As for sprite animation, I did the bard's strumming and the mage's casting (then had Fei finish its coloring and final touches) animation, and Fei did the Swordsman's running and the Archer's shooting. Both of us aren't looking forward to animating the Swordsman's spinning slash animation, so it's been held off till even now. lol

User Interface

The UI elements in and out of battle are just RM's standard menu and window system at the moment, and they'll very likely be heavily modified later on. Can't say I have that strong of an opinion on what it should look like.

For now, I just have it so that the menus are somewhat animated, and the equipment screen was simplified a lot to look more.. sleek.


While we're both at our strongest in this particular area, we've decided to go with my more "realistic", but still primarily anime, style. I really do hate drawing nowadays, though, so I've only been able to stomach it for the two characters I find appealing. I'll eventually get to drawing the rest. 😭

Oh, and again, practically everything's a WIP. Even though I've already started posting the game around to various places in its current state, the swordsman's definitely going to be a regular (pretty boy) JRPG protagonist. I just made him look cute to mess around. That's about how seriously I take my artwork.

Tuesday, June 6, 2017

Copierre - General Information

"Tower defenses" are games where the player stops monsters from reaching the goal line by building towers to defeat those monsters. The player chooses which towers to build, and where to place them. Different enemies require different configurations, and it'll be up to the player to optimize their tower defense. Though really, these "towers" are just clones of the playable party members.

The main game will contain three different areas: a forest, a cave/mountain(?), and a castle. Within each of these areas will be stages with multiple different waves.

The four units available to the player are the following:

Swordsman - attacks nearby enemies with a circular AoE
Archer - shoots at single targets from a distance
Mage - casts long range nukes
Bard - buffs nearby units, and generates resources over time

As the party levels up, they can invest into six primary attributes:

Strength - improves the effectiveness of physical attacks
Intelligence - improves the effectiveness of magic attacks
Agility - increases the rate of actions
Dexterity - increases the attack range and the area-of-effect for spells, and reduces the damage variance
Charisma - decreases the resource cost for creating new units and upgrading existing ones
Luck - increases the amount of resources obtained via kills and through passive automatic generation, and increases the item drop rate

I'm wondering what other secondary effects could be added to STR, INT and AGI.

Monsters will also drop items that can be used for crafting new equipment. Always gotta have a crafting system for no reason.

Saturday, June 3, 2017

Hello, World

Well, my current RMMV project's progressed far enough that I thought it'd be appropriate to setup a dev blog for everything. The simple introduction for me is that I'm the "sole" developer of TGS. I take care of the programming and music. As far as art assets go, however, I do receive help.

While I do have a long history with drawing and digital painting, I mainly only take care of the character portraits. My friend, Fei, provides all of the map tiles and most of the spritework.

As for the project itself, it's essentially a "tower defense RPG". The party clones themselves to defend against waves of enemies. Can't have a video game without addiction mechanics like increasing numbers and random drops, too. You strengthen each character by raising stats via level ups, crafted equipment and enchants.

As far as the "RP" goes, though, that's not set in stone. The majority of the development's been focused on implementing the game mechanics and producing art assets. I've never been too big of a "story guy" or a writer, but I have a plot that could be somewhat interesting. That's provided I actually get to it, however. It depends on how smoothly development goes. I'm hoping to finish this project in a very short period of time, so any plot elements may unfortunately be cut if need be.

I'll be posting updates regularly here from now on.