Xlithan

This is a project I have been working on recently. I am converting SkyWyre v10 to isometric for my game Era Online 3. I've always wanted an isometric 2D engine for many many years now after being inspired by Dark Ages several years ago. This project isn't an engine I will be releasing, the project is purely a system within an already existing project but I felt that it deserved it's own thread as it's a feature that a lot of people request all the time, and I'd like to share my progress with it, and hope to shed some light on how to do this in your own engine. I will split this project up into stages, and discuss the processes, whether they are right or wrong. I am learning as I go along, and I hope you will learn with me as this thread progresses. **Stage 1** Firstly, we need to establish the correct size of the tiles. For this I will be using 64x32 tiles. With the isometric angle, the width is always double the height, so whatever size tiles you are working with, the width is always double the height. If I was using a tile with the height of 48px, the width would be 96px. So, I go through the majority of the source code and update the bits that are important to the placement of tiles on the map. And that results in the following: I've placed a grass tile on every other tile so you can see it as a grid.  We can now work from this grid, and adjust the movement of the player. You need to bear in mind that tiles will not be placed separately like this, to get the true isometric system, tiles will overlap each other on each corner of the rectangle, but we will look into that later. Unlike the way the current system works on square grids, the player will move from the centre of one of those tiles, to only half way across, here is an example of WHY that is. If you were to place tiles normally, like you do now, you would get the following...  So in this case, we need to give a Y offset of 16px, and an X offset of 32px, so moving each tile half down and half across, which will produce the following result:  Now we have that system in place, we need to do the same thing with the player as they move. Since the player will move diagonal, rather than moving them 64px across, and 32px up or down, we need to half those measurements so they are centred on each tile. The following picture explains why we need to do this in more detail. The red dots show where the player stops each time they move, the red line is basically the correct line of travel. As you can see, the player doesn't just move to each grid, if they are in the centre of a grid, they only move half down, and half across, so they are in between grids, which makes this a little more complicated than normal square tiles, and this is why we use offsets, and we will use these offsets for various things in the source, such as finding out if we are standing on top of an item or event etc.  We are no longer using conventional square tiles, and every single piece of code in the source that references to the location on the map needs to be adjusted to take into account these new offsets we are using. So, now that we have our 64x32 tiles, and we've established how our character needs to move and what offsets we need, we can move onto Stage 2. **Stage 2** Stage 2 is all about getting the character to move correctly. Currently, the source code knows the sizes of your tiles. So in normal circumstances, lets use 32x32 as an example. Every bit of code that tells the character sprite how far to move, uses PIC_X and PIC_Y, which are your tile sizes, and it will move the character up, down, left, right the amount of pixels specified by PIC_X and PIC_Y. So right now, my character is moving from the left side of a tile, diagonally, then horizontally to the next position as seen below in the video, 32px up/down, and 64px left/right. This is no good... https://youtu.be/D0qX6SB_SoA So what we need to do here, is go through all of the movement code in the source (Which, as always, is scattered around in several places and you have to dig around trying to find it all), and half that movement. We also need to centre the sprite onto the grid, otherwise it won't look right. "Where do I find all this code to adjust the movement?" Good question, I have no idea. So the first thing I will do is start right from the beginning, the moment we press the movement keys. In this case we have vbKeyW/A/S/D, so we will search for that key press procedure, and follow the code through until we find the bits that focus on how the sprite is moved across the screen. So first of all, we already know that the Eclipse Engine is tile-based movement, and not pixel based movement. This makes getting isometric to work much more difficult, because throughout the code, almost everything in terms of tiles and sprites wants to use PIC_X and PIC_Y to decide where everything goes. You'll notice that throughout the code, we have GetPlayerX/Y and SetPlayerX/Y, now, the X and Y values are based on the tile number you are on, rather than the amount of pixels. So if you moved down twice, your Y would = 2 (number of tiles), rather than 64 (Number of pixels) As far as I can tell, the current system only deals with whole numbers, and has absolutely no idea how to comprehend the fact that the sprite needs to move half a tile... so 0.5, 1, 1.5, 2, 2.5 simply isn't going to accomplish this task. This is where offsets come in to play. We still want our 64x32 tile sizes, but we want our movement to be half those values. So we now need to figure out how to get this done. We could add a pair of new variables called MOV_X and MOV_Y which would be used to calculate movement in replacement of parts of the movement code that use PIC_X and PIC_Y, or we could go to the movement sections of the code and divide by 2, where those values are used. Ultimately, we want the movement system to think that our tiles are 32x16. So after some digging around, we eventually come to Sub DrawPlayer, and it's within this procedure where it calculates the X and Y coordinates of where the sprite should be when we move. I decided to set up a couple of new Constants called TILE_X and TILE_Y which have values of 32 and 16 respectively. After replacing some of the PIC_X's and PIC_Y's with our new constants, we get a much more accurate movement in regards to our isometric system. Now we just need to centre our sprite and we have this result: https://youtu.be/hmgFpes3VGY You'll notice the movement is jerky, and that's because the sprite is moving up/down 16px, and left/right 32px, so it still has 16px left to move left/right by the time it has finished moving up/down. This is ultimately the reason I don't like this system being tile-based movement. I may have a solution to the problem but for now, sprite movement is more or less complete and we are heading in the right direction for a true isometric graphics system. **Stage 3** This stage involves editing the current tile system to work isometrically. Stage 2 and 3 do overlap slightly, as adjustments to some of the tile system need to be made in order to get movement working properly by adjusting the offsets. This is briefly outlined above by using 2 new constants, TILE_X and TILE_Y. At this stage, I'm unable to select my sprite, and I am unable to place tiles onto the map, well at least not in the right place. The cursor data is also inaccurate. I think the easiest thing to do here is go around the code and see what is using PIC_X and PIC_Y, and if it relates to the features that need to be updated, we can replace those constants with our new TILE_X and TILE_Y accordingly. However, we also need to consider that we want to try and get TRUE isometric, so the cursor no longer counts tiles by moving it left - right, up - down. And as you can see from the below image, we would also need to figure out a way of identifying the edges of the map. This shouldn't be any different from the normal tile system, however, the way we have managed to get isometric working so far is by what is known as "fake isometric", in which we still use the original square grid on the left, but we double the width of the tiles, and move the player up/down by 0.5 a tile, and left/right by 1 tile at the same time. This is where it gets incredibly tricky, as we're only moving half a tile up/down, but need it to count as one whole tile.  The problem with Eclipse, is that it uses the same data to calculate drawing, as it does positions of sprites and objects. We need to separate the 2 somehow and recalculate it. To simplify, we have 64x32 tiles, but we need to have 32x16 movement. So after some playing around I figured out that I can use TILE_X and TILE_Y for the map editor and other things. PIC_X and PIC_Y are set to 64x32, so we know to use this whenever we're talking about map tile sizes in regards to the graphics, and we use TILE_X and TILE_Y when talking about the movement of the player. So to adjust the code for the map editor, we just need to look at the MouseDown and MouseMove sub procedures and adjust them accordingly. This was really simple to do, and only required changing PIC_X and PIC_Y. The box that appears on the main screen when selecting a tile to replace, is called Tex_Misc (In SkyWyre v10), and draws the selection box, we need to go into *Sub DrawTileOutline* and adjust the code. The issue with this code, is that it uses the tile size for the position of the cursor, so we need to adjust some code here. After that's done the box draws correctly. Now we need to work on our map edges. I took a look at Dark Ages which is a popular isometric MMORPG, and it seems that they only have warp points at the edge of the map where a path is laid down, so I'm going to go with this concept and disable the feature that automatically teleports you to the next map. I believe they have done this because they have large maps, and certain parts of the same edge will take you to a different location. You can do this by simply not entering a map number in the map editor but I'll go ahead and comment out the code anyway as it's a feature I don't want. To establish the edges of the map we need to change how our X and Y locations work. Currently, if you move up on the screen, your Y value changes, and if you move across, your X value changes. Since our character moves diagonally, both the X and Y value change at the same time, but we don't want this. If you look at the above picture, we need to change our grid layout to recognise movement isometrically.

Almost finished with the Map Studio. For now I've made it so that you have to log into the server. It seems far too much hassle removing and changing everything so that it loads the maps from the server. * You log in on your normal account that has mapping privilages. * All interactive features have been removed (Attacking, chatbox etc.). * All other editing forms have been removed. * When you log in, you are invisible to other players, and they can walk through you. * When a player does /who, you will not appear on the online list. * All GUI has been completely removed. * There are 2 buttons, one for the maps list, and the other for opening the map editor. * Main menu has been set to be log in only. You can not create an account from here.

I keep calling it Creator Suite when it's called Creator Studio :\

There's no reason why you can't have the map editor, and creator suite open. And since the Creator Suite uses an MDI form, you can have every single editor open at once :)

The map editor shows the picture.... Normally a developer knows what NPCs he wants on the map, you wouldn't make a bunch of NPCs, then check the stats to see if you want to add them in a certain location, you would already know what NPC goes where, and then adjust it's stats accordingly. Even then, the map editor on SkyWyre doesn't show the resource image, so you'd have to quit the map editor and go into the resource editor to check anyway...

The map editor already allows you to place resources and npcs etc that you have already added. I may even be able to make it so that the map editor is offline also. You can run both pieces of software if you really want too, the map editor will have an option to reload resources if you added say, a new NPC. Eclipse is the only game engine I've seen where it has built-in editors into the client, and being that most of these games are run off a home PC, it doesn't make much sense to have them as it just slows the connection down if somebody is editing maps and resources, because it has to send all that information to the server each time they save. The server will have options to reload resources and maps, so you won't have to restart the server every time.

I've decided to remove all editing features from the game client and focus on an all-in-one application. The map editor will be separate though for obvious reasons. It will basically be a game client, with limited content. i.e. you will literally only be able to log in to edit maps, there will be no interaction, no chat box, and no other editing tools. There will be a default account and character that it will log into automatically. I may also have it so that other players can not see you or be blocked by you. If you want multiple people to use it at the same time, I may code it that way so that there are say... 5 accounts, and it will just log you into an account that isn't being used. This is the easiest way I can see to do it at the moment, as I've tried ripping out the map editor before and making a new executable and it just didn't work because there are so many little bits of code scattered around the engine and it takes ages to work through it.

Well, there's nothing stopping anybody from releasing it. You can use it as a base, but Sky doesn't want people to share the unmodified source as "SkyWyre" on the forums. Out of respect, that's not what I would do. But there's no reason I can't use it as a base.

I'll be on to that next. I'm still unsure how I want to design it

It's just going to be VBScript. At least this way people can learn some basic VB and later on get into programming. But I'm hoping this engine will flexible enough so that they don't have too :P

New menu interface: 

Just added support for scripting. Now I'm adding support for MySQL database support.

I may have to forget the idea of isometric, unless I stick with the idea of 45 degree isometric, but then I'd have to make my own tiles :(

 PlayerRealms is a compiled engine focused towards non-programmers. It will include several tools for making changes to the game to ensure it is flexible and has the ability to be completely custom. Before I touched on Visual Basic 6, I tried several game editing engines and while they were good, they all lacked that one common thing, and that was the ability to create your own custom interface, to set your game apart from the others. The PlayerRealms database will use MySQL, which will allow players to display stats on their websites, and also adds the support for web-based login and character creation, user control panel, admin control panel and much more. At this current time I haven't decided on which engine I want to use, but I'm leaning towards my edited version of Skywyre v10 due it's already amazing features, and I have already implemented 48x48 tiles which means higher quality and more detailed graphics. I'm looking forward to expanding on the engine and providing a suitable and feature-rich engine for those without the skills of programming. Stay tuned...

Is that just for making the character walk diagonally though? Because I already did that. Or are you talking about a real isometric system using real isometric graphics? Because the issue with the isometric graphics is that, for example, ground tiles have to over lap each other. The diamond shape of the graphic means that the actual tile has blank spaces in each corner where the next tiles would go.  The graphics rendering would have to be rewritten to solve this issue, so that the tile system is diamond shaped instead of square. Everything uses X and Y, and pixel width and height. That means straight across and straight down. The entire graphics system in EO is based on -------- and | The whole system needs to be rewritten to have this kind of shape

I was just trying to scare him into not charging for his game and making a horrible mistake of never getting any players lol. Everybody knows Consty or Shannara doesn't give 2 fucks about MS any more lol. Well, actually, Consty is re-making Mirage Online as a browser based game. https://twitter.com/consty https://play.consty.com/client.html

It's a lot of work. I'm not in a rush to release the game, I might give it a bash and see what happens but it'll be tricky to convert the current rendering system. It's nowhere near as simple as you think it might be.

Video displaying diagonal movement in SkyWyre v10: https://youtu.be/dlD-5NDSJOM

As explained in the shoutbox, server-side code adjustment is necessary. This happens in Sub PlayerMove. In **Case DIR_UP** where you have: *Call SetPlayerY(index, GetPlayerY(index) - 1)* You need to add under that: *Call SetPlayerX(index, GetPlayerX(index) - 1)* And then you do a similar process in the other direction cases. Otherwise the movement doesn't function correctly, as I did try it without. There is something else, called **Sub ForcePlayerMove**, which I adjusted but haven't tested it's functionality. This is only ever used **TILE_TYPE_SLIDE** which I doubt I'll ever use so haven't bothered testing yet. Apart from that, **Sub PlayerMove** is the only part of the server script that needs adjusting to work with diagonal movement.

Yeah, that works for the client side, but for server side in Sub PlayerMove, you have to more or less rewrite it. The code itself remains pretty much the same, but you're doing extra checks. For example, if you move up, it checks the tile which is -Y of the players current position. Since moving up is now -Y and -X, you now need to check the tile up and left of the players current position. As for how the graphics rendering system is "moving" the sprite, I'm as of yet unsure, as I don't think it'll be as simple as "Oh, the sprite is moving up and left at the same time, I'll just draw it so it's moving diagnonal", there will probably be some rewriting of that to show the sprite moving properly in the "new" direction. But we'll get to that. Once that's all done, I'll see what happens when the screen moves. If it's written the way I think it is, it just moves in the direction of which the sprite has moved, but whether it's move in 2 directions at the same time is yet to be determined. But we'll get there!

Yeah I was thinking that. I'm just editing some code to get the character to move diagonally and then I'll put in some iso graphics and see how it looks. I mean essentially it's the same thing from the players point of view, who really cares if the engine isn't true isometric? It'll make mapping a little more complicated, but if it works, it works. The main area of code that needs to be edited, is **Sub PlayerMove**. It more or less needs to be rewritten for checking the tile they want to move too but it's definitely, definitely achievable. I'll post a short video if I can get this functioning correctly.

Well, I've been giving it some thought and the idea of trying to make the engine Isometric appeals to me. I have absolutely no idea how I'm going to achieve this though, it may be way out of my skill set which is probably why it's never been done before. I could always go down the route of fake isometric and just have the character move diagonal, with normal tiles made to look isometric. We shall see.

b) Redistributions of the supplied source code must not be sold or traded without the sole consent of “Touch Of Death Productions”. No hardware per se is licensed hereunder.

Eclipse Public License -v 1.1 www.freemmorpgmaker.com ([email protected]) THE ACCOMPANYING PROGRAM IS PROVIDED UNDER THE TERMS OF THIS ECLIPSE PUBLIC LICENSE ("AGREEMENT"). ANY USE, REPRODUCTION OR DISTRIBUTION OF THE PROGRAM CONSTITUTES RECIPIENT'S ACCEPTANCE OF THIS AGREEMENT. 1. DEFINITIONS "Contribution" means: a) in the case of the initial Contributor, the initial code and documentation distributed under this Agreement, and b) in the case of each subsequent Contributor: I) changes to the Program, and ii) additions to the Program; where such changes and/or additions to the Program originate from and are distributed by that particular Contributor. A Contribution 'originates' from a Contributor if it was added to the Program by such Contributor itself or anyone acting on such Contributor's behalf. Contributions do not include additions to the Program which: (I) are separate modules of software distributed in conjunction with the Program under their own license agreement, and (ii) are not derivative works of the Program. "Contributor" means any person or entity that distributes the Program. "Licensed Patents " mean patent claims licensable by a Contributor which are necessarily infringed by the use or sale of its Contribution alone or when combined with the Program. "Program" means the Contributions distributed in accordance with this Agreement. "Recipient" means anyone who receives the Program under this Agreement, including all Contributors. 2. GRANT OF RIGHTS a) Subject to the terms of this Agreement, each Contributor hereby grants Recipient a non-exclusive, worldwide, royalty-free copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, distribute and sublicense the Contribution of such Contributor, if any, and such derivative works, in source code and object code form. **b) Redistributions of the supplied source code must not be sold or traded without the sole consent of "Touch Of Death Productions". No hardware per se is licensed hereunder.** c) Recipient understands that although each Contributor grants the licenses to its Contributions set forth herein, no assurances are provided by any Contributor that the Program does not infringe the patent or other intellectual property rights of any other entity. Each Contributor disclaims any liability to Recipient for claims brought by any other entity based on infringement of intellectual property rights or otherwise. As a condition to exercising the rights and licenses granted hereunder, each Recipient hereby assumes sole responsibility to secure any other intellectual property rights needed, if any. For example, if a third party patent license is required to allow Recipient to distribute the Program, it is Recipient's responsibility to acquire that license before distributing the Program. d) Each Contributor represents that to its knowledge it has sufficient copyright rights in its Contribution, if any, to grant the copyright license set forth in this Agreement. 3. REQUIREMENTS A Contributor may choose to distribute the Program in object code form under its own license agreement, provided that: a) it complies with the terms and conditions of this Agreement; and b) its license agreement: I) effectively disclaims on behalf of all Contributors all warranties and conditions, express and implied, including warranties or conditions of title and non-infringement, and implied warranties or conditions of merchantability and fitness for a particular purpose; ii) effectively excludes on behalf of all Contributors all liability for damages, including direct, indirect, special, incidental and consequential damages, such as lost profits; iii) states that any provisions which differ from this Agreement are offered by that Contributor alone and not by any other party; and iv) states that source code for the Program is available from such Contributor, and informs licensees how to obtain it in a reasonable manner on or through a medium customarily used for software exchange. When the Program is made available in source code form: a) it must be made available under this Agreement; and b) a copy of this Agreement must be included with each copy of the Program. c) you must have express consent from Touch of Death Productions. Contributors may not remove or alter any copyright notices contained within the Program. Each Contributor must identify itself as the originator of its Contribution, if any, in a manner that reasonably allows subsequent Recipients to identify the originator of the Contribution. 4. NO WARRANTY EXCEPT AS EXPRESSLY SET FORTH IN THIS AGREEMENT, THE PROGRAM IS PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED INCLUDING, WITHOUT LIMITATION, ANY WARRANTIES OR CONDITIONS OF TITLE, NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Each Recipient is solely responsible for determining the appropriateness of using and distributing the Program and assumes all risks associated with its exercise of rights under this Agreement , including but not limited to the risks and costs of program errors, compliance with applicable laws, damage to or loss of data, programs or equipment, and unavailability or interruption of operations. 5. DISCLAIMER OF LIABILITY EXCEPT AS EXPRESSLY SET FORTH IN THIS AGREEMENT, NEITHER RECIPIENT NOR ANY CONTRIBUTORS SHALL HAVE ANY LIABILITY FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING WITHOUT LIMITATION LOST PROFITS), HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OR DISTRIBUTION OF THE PROGRAM OR THE EXERCISE OF ANY RIGHTS GRANTED HEREUNDER, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. 6. GENERAL If any provision of this Agreement is invalid or unenforceable under applicable law, it shall not affect the validity or enforceability of the remainder of the terms of this Agreement, and without further action by the parties hereto, such provision shall be reformed to the minimum extent necessary to make such provision valid and enforceable. If Recipient institutes patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Program itself (excluding combinations of the Program with other software or hardware) infringes such Recipient's patent(s), then such Recipient's rights granted under Section 2(b) shall terminate as of the date such litigation is filed. All Recipient's rights under this Agreement shall terminate if it fails to comply with any of the material terms or conditions of this Agreement and does not cure such failure in a reasonable period of time after becoming aware of such noncompliance. If all Recipient's rights under this Agreement terminate, Recipient agrees to cease use and distribution of the Program as soon as reasonably practicable. However, Recipient's obligations under this Agreement and any licenses granted by Recipient relating to the Program shall continue and survive. Everyone is permitted to copy and distribute copies of this Agreement, but in order to avoid inconsistency the Agreement is copyrighted and may only be modified in the following manner. The Agreement Steward reserves the right to publish new versions (including revisions) of this Agreement from time to time. No one other than the Agreement Steward has the right to modify this Agreement. The Eclipse Foundation is the initial Agreement Steward. The Eclipse Foundation may assign the responsibility to serve as the Agreement Steward to a suitable separate entity. Each new version of the Agreement will be given a distinguishing version number. The Program (including Contributions) may always be distributed subject to the version of the Agreement under which it was received. In addition, after a new version of the Agreement is published, Contributor may elect to distribute the Program (including its Contributions) under the new version. Except as expressly stated in Sections 2(a) and 2(b) above, Recipient receives no rights or licenses to the intellectual property of any Contributor under this Agreement, whether expressly, by implication, estoppel or otherwise. All rights in the Program not expressly granted under this Agreement are reserved. This Agreement is governed by the laws of the State of New York and the intellectual property laws of the United States of America. No party to this Agreement will bring a legal action under this Agreement more than one year after the cause of action arose. Each party waives its rights to a jury trial in any resulting litigation.

You want people to buy the game? Hmm.