Haha, the coders are an endangered species around here. True dat. I wouldn't know much about starting forums, or advertising (besides creating giant posters and sticking 'em across campus). Honestly, I don't think you'd find much coding help around these forums. Chaos Project is probably the best collective coders place that I've seen for RMXP. Maybe they could help out with other stuff too. Who knows. But I'd recommend searching for those people away from Pokecommunity, lol.
People are certainly welcome to contribute. The problem is, around here, the "contributions" will usually be along the lines of "I can make a tileset for you" which doesn't really help. Maybe it'll be different because it's an engine (endorsed by me, for all that means), and the coders will appear from the darkness and help out. Maybe.
This project really needs to start off well. I'm thinking a new forum, an editable-by-anyone design document (Google Docs? I've not used that kind of thing before), and plenty of advertising (although I'm rubbish at that last point). That's the first major hurdle. The point is to get coders in, or at least people who know many things about game engines who can flesh out the design document and come up with solutions to problems and data file layouts and features and such. That alone is a lot of fun to work on, at least for me. I'm just concerned it'll only attract the "keep it up" guys and other spectators.
I understand. Making an engine from scratch, no matter how small or big, is still a large task. Anyway, whatever you do, if people still wanted to build upon it, they could always learn to code for themselves Finding a team would also help you in the process so yeah. I'm sure that once you open a topic about it, you'd find people willing to contribute. So, we'll see what happens :D
Yeah, I just said I don't really want a border. It'd feel inconsistent if it was only there for overworld stuff.
I'm sure there'd be improved camera options in the engine for 2D (scroll, zoom, tint, etc.) compared to RMXP and Essentials. I suppose there could be some camera controls in 3D mode too. If you wanted to go crazy, there could also be a modern free movement system with chase camera mode.
This is still all hypothetical, of course. I for one am not going to invest any time in 3D without much more experience of C#, a team to collaborate and figure out what to do with, and an existing 2D engine (which is what the engine was originally intended to be: a free copy of Essentials with a custom map maker). It's a big step.
Maybe you could find something along the lines of "single-screen" and DS style. By that I mean, you could have (the OW) to be a single screen but with borders, to cover the map. That way, for the interfaces, the borders could just go away and you'd have that extra screenspace. Kinda like a screen in a screen. Don't know how you feel about that though :D
If the engine did feature some sort of 3D, why not open the camera position/angles instead of locking them? I mean, being able to manipulate the FOV would allow for better cutscenes/events. I think that'd be a feature attractive to the users. I know I'm working on having panorama (fake 3D) cutscenes for my game, and I did some when I was working on Blue Chrome. Changing up the camera angle, instead of having to recode it would be cool. Also, I always want/ed to be able to do things like zoom on the map, alongside being able to scroll it. Something the current version of Essentials lack. I think it can be used to create a dynamic in the overall game. What do you think?
Redesigning the GUI to work with a mouse and to suit a larger screen wouldn't be a problem. As you say, the problem is the maps. While a person's mapping style can change to accommodate the larger viewable area, it may not be the best solution to simply increase the screen size. I considered stepping the tile size up to 48x48 pixels, which would result in a screen size of 768x576 (or 800x600, rounding off), but I'm not sure if that would be best either. I really don't want a border or a dual screen-type arrangement just to try to hide the extra visibility.
The engine wouldn't bother allowing anything other than the standard camera angle and FOV, so I don't think it'd be worth having such complex tree models. My suggestion meant that you could probably get away with very simple models (either the DPPt angled plane, or a box sandwich), and if you could, then it probably wouldn't be that hard to let the map-maker create them as part of the map geometry (there could even be preset geometries for use in making trees and things). It was just a suggestion of what I thought would be a more user-friendly option (insofar as the user wouldn't need any models of their own, just tiles, and it'd be easier to create custom-shaped buildings). Your model suggestion is just as valid.
Of course, 3D mode is a pipe dream anyway, and toggling between 2D and 3D even more so. Maybe that'll be in Essentials 3, if that's ever going to exist.
Definitely. Mouse input, and WASD movement, were actually one of the first things I was considering when making Blue Chrome, and were one of the early features I implemented. So that is definitely something to consider. The input on the PC is much less restricted than it is on Nintendo's console, so straying away from the official games in terms of input is a must (I always considered this). These would include things from basic WASD movement, to Text Entry via Keyboard. A bigger screensize though, is something to seriously consider, as using the currently available tiles and graphics which were drawn in 16x16, of which all Pokemon fan-games are made, can make the big screen awkward. I mean, for a test, you could just increase the screensize of Essentials, set the resize factor to 0.5 and then see what the ideal screensize would be. Problem with a screensize that is too big, is too much of the map becomes visible, which can spoil the game in some instances, and makes it harder to properly map like that.
With regards of 3D, I think that just sticking 3D models on tiles would be easier, than distort the tile into a shape. Imagine now complicated it would be to make trees like this, 3D objects/models would definitely give you an advantage in such a case. It's up to you, but I feel using 3D models gives you better precision over your 3D environment, when compared to tile distortion.
The engine being free (and open source) would be a definite goal for the engine, not least because it wouldn't be as customisable as Essentials is (e.g. being able to add extra settings into pokemon.txt) if the source wasn't accessible... although I would push for more flexibility and options than what Essentials has (e.g. being able to define any number of abilities for a species rather than just up to 2). I definitely approve of the free part of it.
I'm sure it would be possible to have a 2D/3D toggle, although I'm not sure if it's worth trying. The first thing is to decide how the 3D would work, and for the easy-to-use method I'm thinking about (where you just paint tiles on distorted terrain rather than actually import models) the 2D/3D toggle wouldn't really work.
I do like my "distort the ground then paint tiles on it" idea (which now that I think about it is much like H-Mode7), because it'd be simple to use, and only uses tiles and no models (making it easier to have custom graphics). It also means you could skip the ground distortion part of map-making and simply paint tiles onto the ground instead, thus resulting in 2D maps (the rendering of these maps can then be set to orthogonal bird's-eye rather than the 3D camera, which shouldn't be too difficult).
The ground distortion wouldn't just be changing the heights of a 2D landscape like H-Mode7, though. You can also add in additional polygons, such as ones at a 45 degree slope which you can paint tree tiles onto (thus they work like how DPPt trees do), and overhangs on rooftops, and snow layers. All level geometry would be grid-based for convenience. Perhaps defining a set of tiles as an object could be a thing if it was necessary.
The complexity of this 3D idea is spiralling way up as I think about it more and more, and try to figure out how to make it work with 2D as well (like 3D map-making is just 2D map-making but with a few more options, even if you couldn't easy toggle between one and the other). I do think geometry and tiles are the way to go, though, at least for the casual user. There could also be support for models for those who want to use them. Again, complexity
I'd actually like for this new engine to veer away from perfectly mimicking the official games, in favour of making it work better as a PC game. For example, mouse support, larger screen size (without making Pokémon sprites correspondingly larger, to give more room in battles, etc.), WASD+mouse controls option, things like that.
Yeah, the userbase that's on current Essentials, would not be at a disadvantage for a future Windows-based engine. Actually, if the engine was free in the end, they'd be at an advantage, since RMXP is restricted to Windows, and is paid software. With regards to the 3D, I was thinking something like this: You'd have a general 3D ON/OFF option in the settings. If the settings was on, the game map would be skewed in a direction, and tiles such as buildings would have models instead of sprites/tiles rendered. These tiles could be defined so that a tree (for instance) is not composed of multiple tiles, but is a tile itself, that is then properly placed on the map grid. If the 3D setting was on, the 2D tree would be replaced with .obj or something. Dunno, just thinking out loud here. I'm sure it'd be a hassle, but it doesn't sound impossible. That way, for those that don't know how to make custom 3D models, they could still be able to make a game, using the graphical skills they have.
C# is definitely the crowd's favourite around the net. And it really is powerful. The thing I liked most about it, is the integration of so many of the Win32API, which make them super easy to use, and hence you can make some really good stuff. I started doing a lot of Win32API work in RGSS recently, and so much stuff needs to be custom/scratch coded. I mean, the best example I've worked with is probably the Mouse stuff. In RMXP you have to write an entire Win32API module and a custom Mouse class to be able to have mouse input. In C# you just have Input.getKey("mouse 1") or whatever. So yeah, C# definitely yields many many advantages.
I'm unlikely to play XY anyway, but it's interesting to hear what new features there are and to form sweeping opinions of them based on no experience at all. Like Pokémon-Amie, which is clearly rubbish.
Mapping is the downfall of Mode 7 and the like. There's definitely no way to make it convenient to use - you'd have to force the user to be really careful with their tile placements and settings, and with only three tile layers to work with, it's way more hassle than it's worth both for the Mode 7 developers and the users. I can't imagine the version that Essentials has is any good to work with; I've not looked at it, so I don't know how it works.
3D support would definitely be attractive. However, it'd most likely make it harder to use custom graphics, such as map tiles and especially fakemon. I wouldn't ever consider 3D battles anyway because they'd be just so complicated and unmodifiable. However, using just a few simple 3D shapes in mapping would make it easier to do - almost as simple as it currently is with tiles (create a 3D map mesh out of the simple shapes, then paint tiles onto them). Custom graphics would also be easier to handle there, since they're only tiles. My main concern is always to make it easy to use, often at the expense of making it awesome.
I'm learning C# at the moment, and I chose it rather than C++/Java/Python/whatever because it seemed popular and powerful without being overly fiddly (no pointers and whatnot). It's quite similar to the other languages too, and makes for a good entry language. The only argument against using it for the hypothetical Essentials 2.0, as far as I can see, is that it's Windows-only. Of course, so is RMXP so it's not like any of the current userbase would be denied; plus there's probably more stuff out there to make C# usable in Linux than there is for RMXP.