Xlithan
-
Posts
311 -
Joined
-
Last visited
Content Type
Profiles
Forums
Calendar
Posts posted by Xlithan
-
-
Well that's ok then.
-
Just tell them you're using it in RPG Maker, otherwise they might not issue you with a refund lol
-
Don't see why you can't get your money back. As with any business if you're not happy with the product you're entitled to a full refund. Contact the website and ask about it.
-
I dunno why you bought that pack to be honest I never liked it. Even the page where you can buy it shows one crappy video in battle mode and no screenshots of much.
I bought Fantastic Buildings and some other matching resources.
The Medieval packs look pretty good if you want a 3D/Isometric style game but keep with a top-down 2D graphic system.
But there's a bunch of packs for it at roughly the same price so it'd cost you a few dollars to get them all. But probably worth it to have something different to what everybody else has here -
Hey, it's your game, you design it how you feel it should look :)
-
Forums are now up for PlayerRealms, located on the DragonSource forums.
http://source.draignet.uk/forums/ -
I second what Daro said.
-
Put some random little flowers all over the grass area, make it look less bland. Otherwise good job
-
With source code you can do whatever you want. So if you wanted full screen, then add it :)
Things like this will be available in PlayerRealms if people want it. The idea of PlayerRealms is to build a universal engine that suits the needs of everybody, and the great thing about PlayerRealms features is the ability to turn them on or off if needed.
I had an idea to create a plugin system. You download PlayerRealms, which is the basic version of the engine, and there will be a system in place where people can use VBScript to make plugins, and release them to the community. -
Finding the right engine to use is half the battle. Rushing the game and using an engine which doesn't quite suit your goals will only result in a poor game experience. PlayerRealms won't be ready for another month, but it will be worth the wait.
-
It's worth a shot. It's a shame PlayerRealms is so far off from release, I think you could have made a really good game with it when it becomes available. It will be very flexible, and have the option for using 32x32 or 48x48 tiles with 4-8 directional movement. it's also a much better engine than Eclipse with some very nice features. And no programming knowledge will be necessary unless you want to use the external scripting to change a few things :)
-
1st post updated.
-
Use parallax backgrounds from RPG Maker if you need too.
Mountains only ever look like that from a distance, when you're physically on a mountain, it looks completely different to when you're about a mile away from it.
This is a good example of using parallax backgrounds.
 -
i've bought a few tilesets from there, the ones I was using for Nightmist 2 are paid for, and they are absolutely incredible. Worth the money if you are serious about your game. If you need any mapping tips I don't mind giving them. I may even write a tutorial on basic mapping. Here's one of my maps (Yes I have a mounting system ;) )
 -
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. -
What I'm saying, is that part of your tileset you're using RPG Maker graphics, and then you've got a tree that's blurred out, mountains that don't match the other tiles. The graphics are very inconsistent.
It's like Mozart writing half a piece of music and having Marilyn Manson finish it off.
This screenshot explains what I mean:
https://i.gyazo.com/0e258e9fa81f882f342d0c766557b7cd.jpg
You have a house that looks completely out of place in regards to the rest of the graphics, and a bare naked tree surrounded by trees that have full green leaves. Unless there's a story around why the tree is that way, it makes no sense. Having consistent graphics and consistent mapping is important.
And the mountains... Are they supposed to be mountains? If so... why is your character sprite almost half as tall as them? -
I like the idea of a religious adventure game. I personally am not religious, but it's different, and I haven't ever seen this idea been put into development on a Mirage-based game, ever.
However, one criticism I have, is mixing tilesets and graphics is never really appealing. If you can find a decent graphics pack, and add or modify parts to suit your religious theme, that would be more appealing to the player. -
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.
Screenshots
in Realm Of Faith
Posted