AdventLegacy

Hello to anyone following this thread. It's been nearly 2 months since I last logged in, and it's become apparent to me that I do not have sufficient time to work on this project. I deeply regret to announce that I'm officially cancelling it. I hate to let this project go. I had really intended to work on it a lot this summer, but I'm working on several other projects that are quite important to me and this one just keeps getting put on the back burner. There's no realistic way I would finish it in a reasonable amount of time at this rate. ...I feel like I should say more, but I guess that's pretty much it. It's just another classic case of someone biting off more than he could chew. Sorry to dash anyone's hopes for a pony RTS.

Considering how the game no longer involves advancing from one era to the next, I suppose I might change the name completely. But until then, Eraquestria sounds good to me! It is indeed easier to say. I'm a fan of component-based programming in game design. In component-based programming, you start with a blank game object and add prefabricated scripts to it to give it features (such as the ability to move). Using that pattern in Godot is tricky because only 1 script can be attached to any given node. Some forums suggest that you can just add scripts to child nodes and use get_parent() to access and affect the parent node. I haven't gotten that to work yet, but I'm sure it's possible and I'm just missing something simple. I would like to use a component-based approach to all the game objects (units, buildings, trees, animals, etc.) in Eraquestria. Here's my initial thought on how to break the essential functions down into individual scripts: Structure Script: gives the object a gridWidth and a gridLength so it can occupy space on the grid that underlies the map. Unit script: gives the object a position and a radius so it can occupy a small area of real space (as opposed to "grid space" which is discretized). Moveable script: The object can be moved in real space. A game object must have a Unit script in order to have a Moveable script. Includes a bitmask to determine which players are in control of the unit. A bit for "nature" is included in the mask; nature units such as birds and timber wolves will be controlled by a special AI player. A "Flyable" script extends Moveable. Flyable game objects can lift off the ground and change their movement behavior. They do not block buildings from being constructed under them. Damageable Script: gives the object health and optionally shields. It can take damage and be repaired/healed. Selectable Script: Allows the object to be selected. When a game object is selected, information about it is displayed in an "InfoPanel" UI at the bottom of the screen, and actions available for that object are presented in an "ActionPanel," such as attack, move, train unit X, etc. This script will need to detect the presence of other scripts on the object, such as Moveable, while also determining which unique actions should be displayed for that type of game object. Perhaps I could add an "Action" script to the building for each action that can be performed. I worry that arranging and displaying these actions on the ActionPanel might be a little inflexible (like, what if I want a dropdown menu or scrollbar instead of a simple button?). Resource Script: Imparts a resource type and count on the object, allowing it to be harvested by workers/villagers (peasants?). To create a building, I would start with a generic game object and give it a Structure script, Damageable script, and Selectable script. To create a unit instead, I would give it a Unit script, Moveable script, Damageable script, and Selectable script. To create a typical resource, I would give it Structure, Selectable, and Resource scripts. Once this architecture is in place, the idea is that I'll be able to compose many different types of units and buildings quickly and with minimal individualized programming effort. There are many, many other details to consider regarding buildings: 1. I need to detect whether a unit is blocking the place where the player wants to place a building. I'd like to avoid either looping through all units or having every unit find its position on the grid during each game tick and setting an "occupied" boolean or something. There's got to be a more efficient solution... 2. It should be possible for a unit to stand in certain tiles that are occupied by a building. For example, units should be able to walk over farms, and I would also like to provide "channels" for newly-created units to move around so that production buildings can't be boxed in by mistake with other buildings. I think this should be possible using colliders that are sized slightly smaller than the grid. On the other hand, maybe I *do* want buildings to be useful for blocking enemies and keeping them out. 3. If a unit is hidden behind a building, an outline of that unit should be visible to the player. This is another one where an efficient solution isn't obvious to me. 4. I want the player to be able to build walls like in Age of Empires. The display of the wall segment will need to update according to which tiles around it are also occupied by wall segments. I also want to somehow detect breaches in the wall and alert the player to them. Maybe I could maintain a "coloring" of the grid, wherein each closed region is assigned a different color. If the coloring changes significantly after a wall segment is destroyed by enemy fire, then I'll know that the wall was probably breached. The player can display this coloring when they click on a wall segment so they can tell whether their wall is complete or if they're missing a segment somewhere. Friendly peasants should not open a hole in the wall by chopping trees. 5. Buildings should take some time to construct. While under construction, actions available to the building are limited. I would like for static defenses to begin shooting arrows or whatnot *before* they are 100% completed, however. I've lost all my villagers after reaching 98% constructed on a castle one too many times. Grr.... 6. Buildings can be destroyed or deleted. When this happens, a few manager scripts need to be updated: A script for managing prerequisites (like, building A must be built before building B), a script that is responsible for recording stats during the game so they can be displayed at the end (showing how many buildings you destroyed and lost, for example), a script for managing the grid, and a script for managing the minimap. There may be other lists that need to be updated as well. I need to come up with a robust way of dealing with game object deletion. Additionally, I'll need to distinguish between various *types* of deletion (destroyed by enemy, deleted by player intentionally, destroyed by friendly fire, destroyed by nature, etc). The Damageable script should probably handle all this deletion overhead. 7. If buildings can be disabled, this may impact the software architecture too. I don't have any current plans for disableable buildings, however. 8. When a building is selected, the active hotkeys should change to reflect the actions that are available for that building. The Selectable script will likely be involved, along with some sort of keyboard input manager script. 9. The map will have a varied terrain. When a building is placed, should the terrain under the new building be flattened? 10. I'm considering having flying buildings (e.g. cloud buildings). Should they be placed on their own, second grid? To be honest, though, I'm leaning against flying buildings because it might make it annoying to finish off an opponent. 11. Production buildings should maintain a queue of units in production. The player can remove units from the queue 12. Buildings need to be informed of research upgrades that affect them, such as increased hp for buildings, increased unit production rate, unlocked units, etc. Some sort of upgrade manager script is needed, and I could use an "Observer" coding pattern in which every new building registers itself to the upgrade manager to be informed of new upgrades (and catch up on the old ones). Wow... that ended up being a much longer post than I expected. There's a lot to consider when you write it all down. Is there anything big you think I might have missed? I'd like to identify as many software requirements as possible before I finish planning out the architecture and begin coding. In the meantime, I promised an animation in the next update, so here's my first attempt at a running cycle for the mare model: It could definitely use some refinement; I'll fix it up later (also, it seems there's a duplicate frame in this gif, causing the animation to pause at the end. oh well.) I successfully loaded the model and animation into Godot, so I'm feeling more confident about this workflow. I also experimented with something called "bone attachments" that should let me add and remove armor (and maybe hair too) from the ponies at runtime.

It seems to me that all of Blender's features have a steep learning curve. But once you master one, the results can be quite amazing. After many hours of figuring out how to properly sculpt and how to model hair, I present my first iteration of a generic mare model: I know... the mane is an absolute mess right now. There are too many spikes anyways, so I'll be redoing it. I plan on making several hair styles, actually. I'm very pleased with the body shape, but there are way more vertices than necessary (2775 not including the hair). I will create a new model, carefully placing as few vertices as possible and using this model as a guide. I'll also arrange the vertices a little more strategically and avoid concentrations of nodes or situations where one node is connected to many others. I'll take the opportunity to fix up the ear and smooth out the muzzle, too. But before I do any of that, I'm debating whether I should model the eyeballs or just "paint" eyes onto the model. The perfectionist in me wants to be able to animate the character's eyes and make them blink. I believe there may be ways to warp or even animate a UV map to accomplish this. If not, then I want to model the eyes. At this point I could already make a bone system and create some basic animations (walk and run, for example). The current model has the right proportions. I want to make sure I can properly import the model and its skeleton animations into Godot before I do a bunch of remodeling, so expect some animations in the next update! And one last word of good news: school is out, so I will definitely be spending more time on this project.

There seem to be a lot of Sublime users here! It is a very handy and intuitive editor. I use Sublime as a general text editor and for coding simple programs in C and Java. For larger programs in C++ and Java, I use Visual Studio and IntelliJ, respectively. When working with C# in Unity, I just use the MonoDevelop IDE that comes with it. I have also on occasion used Vim and Emacs on Linux machines when other editors are unavailable.

I wanted to post an update here real quick lest everyone think I died/left. Things have been busy in school. The semester is coming to an end, so all those big projects are coming due. I'm enrolled in a Computer Science program but also taking some animation classes. After graduation, I would really like to work in the video game industry. I'd like Era Equestria to be a useful educational experience for me in addition to providing a creative outlet for my love of ponies. I'm aware that there are already animated SFM and blender models of ponies available, but I've never built and rigged my own 3D model from scratch (rigs have always been provided for us in the animation classes). I'd like to develop first-hand experience with that process, so I've begun working on a Blender model of a generic mare. I'll post it here when I've got something presentable. After considering various game engines and the possibility of modifying MegaGlest or another existing game, I still find myself drawn the most to Godot. It has a very modern-looking interface, exports to lots of platforms, and seems to have pretty good support and an active community. There are already many useful tutorials on YouTube. Building the game from scratch in Godot will provide the richest learning experience and give me the ultimate flexibility to do whatever I want (with proper planning, of course). I've begun brainstorming on how buildings will be handled in the game (there are some interesting considerations I'll post about later). Before I plan out the software architecture in detail, however, I think I'll make a couple of super simple games in Godot just to familiarize myself with the engine.

I'm in the earliest stages of developing a pony-themed RTS (see mlpforums.com/topic/175916-era-equestria-a-pony-themed-rts/ for more info), and I've been looking around for a good, open-source game engine to build it with. I've taken notes on a few and I thought I'd share what I found. First off, there are a TON of open-source game engines. Literally dozens. Many of them are not being maintained or lack a lot of functionality, though. At a minimum, I want a maintained engine that supports the following: 3D graphics Particle systems (for magic effects) Ability to import models from Blender (the only open-source 3D modeling and animation suite I know how to use) Multiplayer networking Exports to Windows, Linux, and MacOS Another plus would be a versatile animation system (i.e. it allows the user to blend animations together so a character can attack while running or flying at the same time, for example). Below is a list of 3D game engines I've considered, with some notes on each. As I said earlier, there are many more game engines out there, so I may be missing a couple of good ones. I tried to pick only ones that are currently maintained. Blender Game Engine people generally say that it's good for prototyping but not for making a full game. It needs 3rd party plugins for particles. Scripting is done in Python. It does not come with a high-level networking API. You have to code all the networking yourself. Armory3D Fully integrated with Blender. Graphics look exceptionally good. Scripting is done in Haxe. Seems really cool, but it's not quite complete and there are bugs. Their website says the engine is still a work in progress. Spring RTS A game engine made specifically for RTSs. Interesting side-note: It just so happens that "Zero-K", an RTS made in Spring RTS, is going to release on Steam in 12 days. Scripting is done in Lua. Proven multiplayer capability. This one sounds very interesting to me, but I'm concerned about there being enough support. There don't seem to be many tutorials around. I'm also concerned whether the engine has enough flexibility. For example, there are a set number of unit classes (which define specific ways that the units can move). This probably means that flying units would have to fly all the time; pegasi could not land. It may be possible to create my own Lua script to make that happen, but I'm not sure how much work that would entail. Some people have said that making a game in Spring RTS is more like making a mod than making your own game. Godot Very popular, relatively good support. Some have said that it's not as good with 3D games, but I think this was only the case prior to version 3.0. There's a lot of excitement around Godot's recent decision to incorporate "Vulkan", which looks like some high-performance, cross-platform graphics API. It has a notably good animation system, and any property can be "animated" including functions. Scripting is done in either GDScript (Godot's own scripting language), C++, C#, or VisualScript Includes both high-level and low-level networking APIs One thing that personally bugs me is that each "node" can only have 1 script attached to it, making component-based programming a little trickier. Panda3D Scripting is done in either C++ or Python. I don't think it has any high-level networking API. Panda3D was originally created to make a multiplayer game for Disney, though, so maybe I'm wrong? Multiplayer is conspicuously missing from their features page. My overall impression is that Panda3D was once a great engine, but is rapidly becoming obsolete. It does not support mobile platforms, and writing shaders is very hard. Torque 3D Seems to have pretty good support. Scripting is done in TorqueScript (Torque 3D's own scripting language). Includes high-level networking stuff. Animation blending exists but is limited (all bones must be used in the animation blend). Urho3D inspired by Ogre 3D and Horde 3D (rendering engines) scripting is done in AngelScript or Lua (or C++ too, I think?) has animation blending, but it sounds like it's limited like Torque3D's (blending uses entire skeleton). I think it has high-level networking stuff. It's been around since at least 2009. It used to go by the name Bofh3D The editor isn't very pretty from what I've seen (but hey; if it works, it works). It sounds like a bit of a pain to set up. You have to download the source code and compile it yourself. Irrlicht Unofficial bindings allow scripting to be done in a variety of languages, including C#, VisualBasic, Dephi, Java, ruby, perl, python, Lua, Autolt, and C++. Supports a variety of Desktop environments, but is lacking in official mobile support. Apparently, it does not support audio on its own. However, there are various audio tools that are designed to integrate well with Irrlicht, such as irrKlang. Does not have any high-level networking API. You need to code it all yourself. It's been around since ~2006 It seems to me that Irrlicht itself is somewhat bare-bones and focused on graphics, so you'll need to pull in some unofficial contributions and 3rd-party software to make a complete game. The big picture: Godot is a relatively young game engine (4 years old) and seems to be the popular choice in the open-source world these days. It looks quite good. Torque 3D and Urho3D have been around for longer (~8 years) and also look pretty good. Armory 3D is showing a lot of potential, but is not quite ready for prime time. Panda 3D was first released 16 years ago and is showing its age. Irrlicht requires integration with 3rd-party software for sound. It's been around for 12 years and is also getting old, but during that time many unofficial language bindings and supporting 3rd-party software have emerged for it. The Blender Game Engine is lacking some features and may not be a good choice for your final game engine (but may be OK for rapid prototyping). Spring RTS is specifically geared towards making RTSs. Several snazzy RTSs have been made with it, but it may lack flexibility.

Thanks for sharing your thoughts! Although I'm interested in a somewhat darker portrayal of Equestria, parts of the Equestria Divided universe are a little too brutal for my liking (like house Earthborn cutting off the horns of unicorns and the House of Moon and Star employing slave labor). I do find the background story and setting engaging. Everyone has a goal that pits them against each other, and there's a lot tied to the religious question of whether the royal sisters still control the Sun and Moon or were always lying about it. Each faction has its own style/strategy that sets it apart from the others. Perhaps I could work with a slightly lighter version of this universe, or borrow components from it. I'll think about it some more. I absolutely love the unit designs. If nothing else, I'd definitely like to borrow/steal some of those. Do you happen to know whether PoorYorick still around somewhere? I like the way heroes are handled in LOTR: Battle for Middle Earth. Hero units level up and acquire more powerful abilities as they get more kills. I assume Warcraft 3 has a similar thing going on (I haven't played it). You make a very good point about hero units not always being an advantage if they have a niche role, though. Perhaps I'll limit their appearance to campaigns, then. I like to think this game would be somewhere between building/economy-focused and unit-focused. Something like AOE2 or Starcraft. What do you think of this idea: changing the style of matchup depending on which civs are playing. For example, when the matchup is Equestria vs Equestria we have a "rock-paper-scissors" setup, but when it's Equestria vs Changelings, we get a "static" matchup?

I've made a tentative decision about which civilizations will be playable for this game: The Crystal Empire, The Changeling Swarm, and Equestria. There are several reasons why these particular civilizations work well together: 1. Many units will be ponies of one kind or another, so models can more easily be re-used. 2. There is potential for completely different styles of play. Equestria will have its 3 balanced pony races; the Crystal Empire will have more airships, no winged units, and its magic units will work differently (I'm not sure exactly how yet), and I like to think that the Changeling style of play will somewhat resemble that of the Zerg from Starcraft. 3. All three civilizations have interacted with each other before in the show, so there is a rich lore to draw from when creating campaign storylines. I've already begun developing a storyline for 3 campaigns (one for each civ) that naturally flows from one campaign to the next. But before I go any further with that, I'm going to deeply explore all the possibilities for types of units and styles of play and make sure that this selection of civilizations would work. Also, writing/scripting is certainly not my special talent and I should maybe put that task into the hands of a more talented writer. Another idea that's recently come to mind is the possibility of choosing a hero unit that has an impact on your civilization. For example, if you are playing as Equestria and you choose Luna as your hero, perhaps this could unlock batpony units, dress all your units in nightguard armor, and give your units and buildings other specific benefits. Perhaps Luna would also have a "Raise the Moon" ability to boost the morale of your units. Choosing Celestia could unlock, say, phoenixes and dress all your units in "normal" armor. Celestia would have a similar ability, "Raise the Sun". I think people would have a lot of fun playing out battles between the Solar Empire and New Lunar Republic this way.

That is a very interesting idea. I had always assumed I would be building this game from scratch, but if there are open-source RTSs out there already, I suppose I could just use one of those. I do know C++, so I'll definitely look into this possibility. Thanks for the idea!

I've been thinking some more about the fact that most civilizations in MLP contain either all flying creatures (Griffonstone, Hippogrifia, changeling swarm) or all non-flying creatures (Zebras, Crystal Empire, Storm kingdom). There's a more significant balancing issue I've realized recently. Walls do not stop flying creatures, so the effectiveness of your static defenses would be tremendously impacted by which civilization you're up against. I do not consider this acceptable. Therefore, I've decided that all playable civilizations must have a combination of flying and nonflying units. Furthermore, there should be incentive to train nonflying units in order to prevent flying units from dominating the game (a simple counter-unit to flying units might be enough). As I mentioned in an earlier comment, Zebras could build airships. This results in a nonflying + flying combination. The same goes for The Crystal Empire and Storm Kingdom. Griffons, Hipogriffs, and Changelings, however, should not be playable civilizations on their own. Instead, they would need to be paired with a non-flying ally. Perhaps one playable civilization could be "The Northern Alliance", consisting of crystal ponies, yaks, and griffons. Since such an alliance is not canon, I'm not sure how I feel about it. I also suppose it's not impossible that there are non-flying types of changelings (we don't see any in the show, though, do we?). Perhaps the changelings could be playable after all if non-flying types are included.

New Topic: Balancing types of units

D'oh! I guess I really should have looked in there earlier. I see there's a couple of good game engines recommended. Cryengine looks amazing graphics-wise, but they're not really open source. Panda3D is another viable option; it's interesting that it was initially developed by Disney. I don't like the way the graphics look in games developed in Panda3D and Godot, though. I've looked around a little more, and it seems there's quite a few open source 3D game engines out there. I'll need to do some research (and write my findings in the Button Mash Code Library) New Topic: Flying Units One thing about ponies that works really well with the RTS concept is the existence of three specialized pony races that easily translate into three categories of units. It seems natural to have a Barracks to train strong, grounded earth pony units, a Flight Academy to train flying pegasi units, and a Magic School to train magic unicorn units. But what about other playable nations? Zebras could have no naturally flying units, whereas ALL the units of a Griffon kingdom would be flying. This presents a balancing problem I've been thinking about lately. Airship units could serve as an equalizer. Zebras could build airships and perhaps zebra airships should be stronger than Equestrian ones to compensate for their lack of non-airship flying units. Likewise, perhaps griffons would have weaker airships and/or a smaller selection to choose from. Alternatively, the game could involve only the 3 primary pony races and the playable nations could be The Solar Empire, The Lunar Republic, and... perhaps the Crystal Empire (and let it train pegasi and unicorns)?

I have prior experience with the Unity game engine, but for this project I'm looking to go open source. Godot is looking fairly promising to me. Does anyone know of a great game engine they'd like to recommend? It doesn't have to support every system under the Sun and Moon; as long as it can export to the major Desktop OSs (Windows, MacOS and Linux), I'd be happy with that. Support for a commonplace language (such as C#) would be a plus but is not necessary. I've decided that the game should be done in 3D. Although I could mimic the show's style better with 2D, I feel that 3D assets would be significantly less work. With 3D animation, only 1 walk cycle, 1 attack animation, 1 death animation, etc. needs to be created for each unit. In 2D, the same animation would have to be re-made for each perspective (front view, side view, 3-Quarters view, back view, and Back-3-Quarters view). Any experienced game devs or animators out there with a differing opinion? I've only done a little bit of 3D animation myself, although I'm experienced with 2D animation.

Thanks for your input! I like the idea of four eras and the names I came up with for them, but the second progression system makes more sense when it comes to campaigns and multiple playable races. For instance, if there's a campaign dealing with the banishment of King Sombra, it wouldn't really make sense from a story point of view for the player to ever advance to Era Luminis (which is supposed to correspond to Celestia's reign after the banishment of NMM). So the player would have to be limited to Era Disharmonia and Era Sororibus during that campaign, but that sounds very limiting from a gameplay point of view. Furthermore, the eras only make sense for the pony races and don't really apply to, say, griffons or changelings.

Hello everypony. I'm thinking about making a pony-themed RTS. If I decide to go through with it, I would like to aim for top-notch quality. I've come to this forum seeking input from the community and to gauge the level of interest in such a game. So what would you like to see? Have any cool ideas you'd like to share? Are just ponies OK or would multiple playable races be mandatory? How do you feel about hero units? Keep in mind, though, that the more complicated the idea is, the longer it will take to develop. Speaking of which, I expect development to take on the order of a couple of years. The tentative name I've come up with for this project is "Era Equestria". In my initial vision for this game, the player advances through 4 "eras" analogous to "ages" in Age of Empires: Era Disharmonia, Era Sororibus, Era Luminis, and Era Magicae. However, I'm considering discarding this system in favor of a more Starcraft-style progression in which the player must construct particular buildings before being able to construct others. I look forward to your input!