For 2D which uses the Z axis (height) as the Y, you need to create a rather complex sytem.
The first needed system is the actual 3 world route system. This converts points in your 2D world onto points on 3D WC3's map. This allows for stuff to be handled much more easilly as you can program the rest just like any 2D game. Part of this system is an acutal route plan, which allocates how the X axis converts into X and Y points on a WC3 map to allow for more impresive and smooth routes. Such a system will be properly coded when you are able to fully exploit the 3D capabilites of WC3 to allow for users to physically not move in a straight line yet seem to gameplay wise (eg walking around a corner on a wall, or winding through a forest around trees).
With the basic system dones, you can work on your 2D engine. For this it has to be capable of clipping 2D objects so as not to waste system recources, be able to handle whatever you want in the game and allow for collidable objects. For ease of programming, you can use the WC3's terrain height as the "flat" level as realistically, nothing can be placed below it and seen. Colidable areas are simple square based checks (as your previous system handles 2D - 3D conversion you can treat these as squares) whereby you check if another square is within it (that square is the collision of your unit or bad guy), and if so it displaces it to the nearest position so that it does not contact. Ofcourse you will be performing a huge number of these checks, probably in the region of 30-60 at once depending on complexity of terrain (how much Z ise used), thus clipping is a must to assure that unnescescary computation resources are not wasted. For clipping the easiest probably would be a sector based system, whereby your 2D environment is broken up into sectors of a certain length and only secotrs within a certain range of your character (slightly larger than screenwidth) are loaded and used to compair with assuring on a nescescary number of checks. Remember that collision areas are theretical, and not at all attached to the terrain of the map, so terrain may still be rendered if needed be even after the collision used for it is no longer used. Finally is your actual character object, which basically contains an X, Y, Xvelocity and Yvelocity, collision rectangle information and an attached graphic for it (probably via unit) so that it is capable of being seen. The objects should be updated between 50 (SP) and 20 (MP) times a second for resonable system recource useage. When pickin objects within a square, you do more collision based calculations (useful for something like an attack).
Finally you have your level system, which should have a highlevel interface system for easy and efficent useage as well as manage the loading of all badies, movement paths and collision areas your map may use. For most efficency this would probably be one or two functions per stage, each which modifies arrays which act as data sources for the systems.
Overall, a quite plausable task, even if not capable efficently. I can imagine such a system working fine in SP as long as your code it correctly and could allow for some graphics worthy of independant games, especially if good terrain is used with attention to detail. A possiable graphics loader extension could be made for even better framrate for more impressive graphics by creating high detail stuff close to the screen only when near that sector of the movement system and thus reducing graphic usage when viewing the path from afar.
Should be doable within a few weeks such a system with enough planning, however it is near impossiable without JNGP and without using JASS as GUI is nowhere near suited for such a high quality system.
