Jump to content

  • Log In with Google      Sign In   
  • Create Account

EarthBanana

Member Since 18 Mar 2013
Offline Last Active Yesterday, 11:56 PM

Posts I've Made

In Topic: Double Dragon 2 (NES) - Physics and collision

23 July 2015 - 07:28 PM


In the 2.5D areas, can you move to the front and back instead of only to the left and right?

 

In double dragon, and in most arcade style games for NES (ninja turtles comes to mind), in the 2.5 d areas you can move front to back and side to side. There is a draw order here too - you will be drawn in front if you are closer - no surprise there really. These "2.5d" areas are part of what made these games so fun, especially for multiplayer.

 

To handle this movement I would just keep track of the sprites ground position and for the 2d parts of the map only allow x movement and for the 2.5 d parts of the map allow x and y movement and restrict your y range to the ground platform width. Then use your players and enemies ground position y coord to tell which should be drawn first.

 

As mentioned earlier, when something jumps you can predict where they should land at any given point in time and use that ground position y coordinate to do the depth sorting of sprites.


In Topic: Placing Things in a (Kinda) Voxel World

23 July 2015 - 12:24 PM


What kid of editor did you make? When I was writing the editor for my engine, I just used the standard 3 arrows in the XYZ and did the math for that. IMO thats the best solution, but I feel like that wouldn't be immersive enough to give to a player.

 

Yeah for a engine editor - I would agree the object handle widgets are probably the best. But.. for object insertion this method works. In some editors, the object will just be inserted at 0,0,0 when you add it to the map. In others, an intersection is determined between the target vector and the scene and the object is inserted somehow according to this (as Servant of the Lord mentioned).

 

I chose this method for insertion because my map editor aims to have a feel that is less 3d editorish and more like a painting program or something similar. Once the objects are inserted in to the map, the normal rotation, movement, and scaling widgets are available but just for the purpose of inserting in to the map I use this brush approach. 

 

I think it works well though - If I remember I think in the unreal toolkit you drag and drop items in to the map and placement is done somewhat like Servant's post, or this may have actually been TES construction set. I remember when I was first trying to figure out how I wanted stuff to be inserted I downloaded a whole plethora of different editors and tried them out to get a feel for what I wanted to do.

 

I ended up at the brush idea mostly because I wanted the user to be able to "paint" hexagon tiles using different brush shapes. And I wanted it to be easy for them to see where they could insert or not insert stuff in to the map.


In Topic: Placing Things in a (Kinda) Voxel World

21 July 2015 - 02:05 PM

The way I handle this in my editor is to

 

1)    Create a copy of the object that is to be inserted and make it 60 to 70 percent transparent

 

2)    Insert this object a set distance away from the camera (using the look/target vector)

 

3)    Set all mouse movement to project the objects move in a single plane - The plane is determined by the camera's horizontal angle.. IE if the camera's target vector is greater than 45 degrees away from the xy plane vector, then the movement is in the xy plane.

 

4)    After drawing the transparent version of the object, draw the object twice more using a stenciling mechanism to only draw the outline of the object - make this outline some solid color. On the second draw turn off depth checking so that the outline is always drawn.

 

5)    Change the overall object color to transparent red if the user cannot insert the object at the current location.

 

In essence, you use whatever object you are trying to insert as an "object brush" that moves in a single plane following the users mouse movements. You can then set up a key (or a couple keys) to allow the user to change the plane of movement.

 

The outline of the "brush" will always be shown in the editor even when behind other stuff so the user is not confused, and you can change the color to red (or whatever color) to indicate that the object is not insert-able at its current location. When the user clicks in a valid location, you create an object in that spot and snap the object's position to whatever grid you want to use.


In Topic: Has anyone got a feeling of this when you were starting as game developer?

20 July 2015 - 01:28 AM


Im already on my 20s.
Brain keeps developing until 25.

 

Oh man... Im 26

 

Its all over


In Topic: typeid operator

16 July 2015 - 04:19 PM


Example:

 

I think this is the route I will take. Then I can get rid of typeid all together and just require that someone makes TypeID public static member of derived classes. It will be enforced because in the create<ObjType> code I will use ObjType::TypeID to get the factory. If its not part of the class it won't compile.

 

Is there any good reason to make it an integer rather than a string? Is it just for the sake of quicker lookup? (ie unordered_map rather than map)

 


That last one is nice for tools that automatically build the boilerplate and insert the new file at the right places in all the build scripts and project files.

 

It would be really nice to have something like this - my project is probably still too small for this to really be worth it. I only have, for example 16 or so components right now, and I think 9 or 10 "resource" types.

 

My goal is really to make a library that others can include and use with minimal effort - even though I'm aware that theres plenty of other engines avialable and there is no really good reason to pick mine over them. I just enjoy the challenge.

 

That being said I basically am trying to get a setup where the user includes the engine as a static or shared lib, decides they would like a new component type and new system type so creates the system and component classes deriving from the base classes, registers them with the engine, and voila they are good to go.

 

Of course part of writing the component subclass means you have to create your own pup (stands for pack unpack) function to serialize and deserialize, but the engine takes care of the everything else - including making any entity with that new component attached still saveable and loadable without changing any engine code.

 

I have a similar setup with "resources" and "resource managers". You register a resource type along with its manager type, and now you can use that resource.

 

Anyways, thanks for all the input! I'm glad to hear that this is actually a thing that has to be considered by other developers and I'm not just missing some huge "DUH - just use X and Y for that!"


PARTNERS