Valyria Tear 1.0 Feature Import List

A discussion area for general design issues that staff would like detailed feedback on.

Moderator: Staff

User avatar
Posts: 8643
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX

Valyria Tear 1.0 Feature Import List

Postby Roots » Sun Sep 21, 2014 9:26 pm

Hey everyone. I've spent the last week playing through the Valyria Tear 1.0.0 release and studying the code to understand how it differs from Allacrost. I did this partly to come up with a list to see what we can port back to Allacrost from VT, and what we can leave behind. With that in mind, here's the list I've compiled of what features we should import or ignore, and why I feel that way about them. Feel free to add your own comments, or point out anything that I've missed. Some of these points are not really features but are rather technical details, mind you.

Features to Import

1) Visual effects in map mode
VT has support for things such as patches of fogs, snowstorms, etc. Some of these effects also influence the movement of sprites (pushing them along a wind draft, for example). I think this is a great addition and makes the maps feel much more alive.

2) Break up map files into separate map and scripting files
VT took the large map files that Allacrost has and broke them into two separate files. The map file contains all the tiles, tilesets, etc. that are laid out in the map editor. The script file contains all the code that we write to make events, characters, etc. happen on the map. I really like this, because it helps keep our map files more manageable and easy to use. We just need to make sure we have some standards so that it's apparent which files are maps and which are scripts (perhaps separating them into two different directories).

3) Character emotes
VT supports little emotes for characters such as exclamation, ellipses for silence, etc. I think this is a worthy feature to add, but I don't want us to rely too heavily on emotes either. I think custom sprite animations are much more effective than emotes for showing emotion such as surprise or sadness. Of course this requires more effort to make, so emotes could be a useful stand-in as well for when we don't have the artwork available that we desire.

4) Pressing F1 opens a help screen
I really like this feature, as it makes it easy to bring up the controls and other information at any time during play. One addition that I'd like to make is that the contents of the help screen change based on what mode it is called from. So pressing F1 from battle mode shows you information about how to do battle, while map mode shows information about exploring maps. In the future, we can expand our help screens to contain more information, such as a legend showing what the different parts of the battle screen are indicating. For now, we can just use the help screen to tell the player what the controls are like VT does.

5) Window reflections in map mode
This is a very cool feature. I have no idea how this is implemented at the present, however. I think it can be a low priority item, but definitely something I want to add support for eventually.

6) Multi layered support in map mode
Currently the tile and object layers in map mode are fixed in Allacrost. And they really don't need to be. I want to add support so that a map can contain as many or as few tile/object layers as they need to have. Supporting this shouldn't be terribly difficult to do. It will lift an unnecessary restriction on our map designs that need not be there in the first place, and may make some features (such as bridges you can both walk under and across on) easier to implement.

7) Various map editor changes
There have been a number of improvements to the layout and design of the map editor. I think we should take in all of these changes. The VT editor is clearly superior to the Allacrost editor, even though the VT editor only has a small number of additional features.

8) Map mode background images
Some maps in VT use a static background image that tiles are drawn upon, such as a cliffside on a snowy mountain map. I like this additional depth a lot. In the future we can expand this to support parallax scrolling of the background image as well, which was on our future feature list anyway. So importing this feature will give us a head start on that.

9) Puzzle solving in maps
VT has some puzzles on their maps that really enhance the gameplay. Although the puzzles are mostly simple (they involve pushing a spherical stone until it stops on a switch), they are effective and a good start to adding support for more puzzle-solving problems. We should study how this was done in the map scripts and mimic this for Allacrost.

10) Including specific engine subsystems instead of entire components
Instead of including "video.h", a file might just include "image.h" if it only needs access to the image APIs. I like this idea, as it doesn't make sense to include the entire video engine when you only need to use a small portion of it. This can be something we keep in mind and change as we work on various parts of the code. Although I'd prefer if we used "video/image.h" instead of just "image.h" to make it more apparent what system the file is being included from.

11) Particle effects
VT seems to have a much improved graphics engine with better support for particle effects. We should definitely leverage this work so that we can support these sorts of effects as well in Allacrost.

12) Ability to change game options from pause mode
One very nice touch was the ability to modify the game options when the game was paused. Presently, we only support modifying these options in boot mode. I found this useful when I was trying to turn down the audio levels while I was playing the game and was thankful that I didn't have to find a save point, save my game, exit to boot mode, change the setting, then load my saved game. A very nice touch to have. Although I don't know if you can change the language successfully from the options menu. Being able to change languages whenever is one feature that I want to have in Allacrost, but it might take some work to do.

13) Day->Night lighting transition
This was what looked most impressive to me, and I nearly forgot about it. Toward the beginning of the game when you are heading back to town after a quest, the map gradually becomes darker and darker as the sun sets and the moon rises. It looked fantastic, and I'm really excited to see more use of such lighting transitions.

Features to Ignore

1) Minimap in map mode
Some maps in VT have a minimap. I don't think this feature is worth the effort it will take to implement. Maybe it can be something we add in the future if it makes the game better, but not right now. I would instead prefer if we just design our maps well enough so that a minimap feels unneeded. We would do this by adding certain distinguishing features at different points of the map, and avoid repetitive tiles/scenary where we can.

2) Custom images for weapons in battle
VT separates out the battle sprites and the equipment they use to execute attacks. While this is a nice little detail, I don't feel it's worth the effort. I would instead prefer if we just use a common-looking sword, crossbow, etc. instead and not worry about changing up battle animations when a new weapon or other piece of equipment is added.

3) Status effects are active in map mode
Effects like poision, etc. persist after battles in VT and their effects can sometimes be seen while on the map, where they also weaken in strength and dissipate. We long ago decided in a design discussion that status effects in Allacrost would disappear when a battle ended, and I strongly feel that we should keep it that way.

4) Adding support for damage-causing traps in map mode
Some of VT's maps have traps that inflict damage or status changes to the party. I prefer if we leave this feature out of Allacrost. I don't want the player to be worrying about taking damage and being afflicted with other ailments when they are not in a battle. It's not a bad feature to have; just one that I don't feel would add too much to Allacrost.

5) Animated battle enemies
VT has a few enemies that have a small amount of animation (and those that do have no damage frame sprites). I think we should leave our battle sprites static, as they are large and complex to make already, that adding even a small amount of animation would require resources that we just don't have. Plus it becomes difficult to have enemies that have both damage frames and animations. I would prefer that we stick with just damage frames, which are easy to make once you have the non-damaged sprite completed. However, we could add support for battle background effects to be placed alongside enemies sparingly, such as smoke or other particle effects. This would enhance their appearance without requiring more art resources.

6) Move build system from autotools to Cmake
VT uses Cmake instead of our autotools build system. I don't see a reason to move from autotools. It has worked fine for us for years and continues to do it's job well.

7) Removal of defs.h
This file contains declarations of all namespaces and classes that other code includes so that they don't have to make those declarations themselves. VT removed this file and declares the classes/namespaces separately at the top of each file. Removing defs.h was done to improve compilation time and use better coding practices. Frankly, I don't feel it's necessary for us to spend time removing defs.h at this time. Yes, it slows down compilation if any header files are modified and isn't good coding practice. But it's convenient to use, and I don't want to spend time yanking it out of the code base when there are better uses of our time.

For the record: the reason why this file was created in the first place was that way back when the code was still in it's first couple of years, a lot of files were making declarations in their files of code that either no longer existed (because it was renamed) or just didn't use it anymore. I was tired of seeing a mess of class declarations all over the code that was outdated and misleading, so I made defs.h so that things could stay nice and clean.

8) Removal of "using namespace std"
This is another compilation efficiency that VT added, as apparently calling using namespace std pulls in a lot of code that you don't need. We might want to look into this in the future, but right now it is a very low priority and not worth the time and effort, in my opinion.

Return to “Design”

Who is online

Users browsing this forum: No registered users and 1 guest