Jump to content
  • Advertisement

d h k

  • Content Count

  • Joined

  • Last visited

Community Reputation

439 Neutral

About d h k

  • Rank
    Advanced Member

Personal Information

  1. The Art of Dying has been released!     Thank you for the interest during development, now go over here to download the game, play it and let me know how you liked it!
  2. Here's my fourth video that shows off the level editor that is included in the game. Take a look please:     As always, please let me know what you think and, especially, if you could see yourself using this editor. Also, ask any questions you might have, I'm sure there is plenty of stuff I fotgot to explain. If you have improvements on user friendliness (that are reasonable, considering the scale of the project and given the limited engine I am working with) please let me know as well.
  3. Hey, thanks Hyperplane!   A level editor exists indeed and it's going to be available for everybody from within the main menu! In fact, I'm planning to record a fourth video explaining how the editor works!   A jetpack sounds interesting but it would complicate level design greatly :P Dinosaur enemies? Haha, I don't know!   Thanks for taking a look!
  4. Ignoring the complete lack of response whatsoever, I guess I will still post my new third video? This one talks a bit about enemy design and then goes on to show a selection of enemies from the game.     Please let  me know what you think, or if you have any questions.
  5. Here's a second video in which I talk about how attacking works in the game:     Take a look and let me know what you think! It's getting a bit more interesting now! The next video will introduce the various enemies in the game!
  6. Hey there!   Long time no see, GameDev! I wanted to share my new project "The Art of Dying". It's made with a software called "Adventure Game Studio" that I've been using and abusing for non-adventure game for ten years now. This is a solo project, meaning I'm programming the entire thing, I'm drawing all the art and animation and design the game. The music in the video is used with permission and is by the amazing Tom Woxom - found on the equally wonderful freemusicarchive.org!   The way I want to present the game is with short video segments: each one focuses on one particular aspect of the game. This first installment talks about the most important game play mechanic in any platformer: movement! Please take a look:       In the video I demonstrate the way I implemented movement, acceleration/deceleration on different surfaces (solid and slippery), jumping, double-jumping and ducking.   Let me expand a little on two of the points made in the video:   - Featuring smooth movement (with acceleration and deceleration) as opposed to hard fixed-pixel movement is very important. The former gives a much more modern feel to your game, the latter is more precise and exact. I went for very subtle smooth movement and put a lot of effort into finding 'correct' values so that you would just barely notice that there is smooth movement in the game but still keep the controls as tight as possible.   - Jump systems are a second, fundamentally important aspect of platformers. There are several different styles that you can follow: There's the simple way. You hit the jump button and it results in the same exact jump every time no matter what. Then there's the Mario way: the jump starts when you push the jump button and gets an upward boost for a limited amount of time if you hold the jump button. That gives the gameplay much more complexity as you can now have jumps that players need to be careful not to overshoot (down-facing spikes over gaps anyone?) and you need to master the regulation of the jump. And then there's the double-jump system that I went for. It's like the first-mentioned primitive jumping system except that you can, well, double-jump. I went for this latter approach because it allows the player to regulate the jumps and makes the gameplay more complex and, at the same time, it looks really cool to double-jump all over the place. Don't ever underestimate how important it is for core gameplay mechanics to just be straight-up dumb fun (and complete unrealistic from a physics point of view)!   I will be releasing a second video right into the thread here very shortly from now which will focus on the various attacks in the game! Please let me know what you think of my project, the ideas I talked about in the video and in this post and ask any questions you might have!
  7. Yes, w is included. Imagine x has the largest absolute value. Then you compute (y/x, z/x, w/x), which has each coordinate between -1 and 1. In that sense, it is a cube. Since there are 4 variables, you get 4 different cubes. This is similar to the situation with cubemaps, where you map a point in a sphere to one of 6 square faces. Okay so I see how I end up with a Vector3(y/x, z/x, w/x) if x is larger than y/z/w for example. Let's say the vector is (-1, -1, 1). I understand how this always lies within a unit cube around the origin. But then you say there are four variables, that means we get four of these cubes. This sounds, to me, like I need to then do the same procedure but not with Vector3(y/x, z/x, w/x) but Vector3(x/y, z/y, w/y) for example? Is this correct or am I misunderstanding you? If this is the correct procedure, then the largest absolute value part is confusing me, do I just let that determine the quaternion element that I start with? Lots of questions here, sorry! I hope you have (or someone else has) some time to explain the concept some more! Hmmm... Nothing for roll? In order to save memory we want to rotate the billboards via code ourselves! The 17 pitches also do not describe a full 360 deg turn, since we only need half a circle. Then the other half of pitches can be translated to a different set of pitches with a 180 deg yaw rotation, if that makes sense! So: 32 yaw angles = 360 deg yaw rotation, 17 pitch angles = 180 deg pitch rotation, no roll angles = rotating via code!
  8. That sounds intriguing, excellent idea!   I'm not exactly an expert with quaternions yet, but I do know the basics (x, y, z define an arbitrary axis around which we rotate by w). How does dividing the other components by the largest one (x, y, z, with w or without?) leave me with a 4 cube division? I don't understand that very fundamental step!   The 544 angles are 32 yaws and 17 pitches!
  9. Hello there!     The problem   I'm working on a retro space action game in Unity3D. I say retro because we do not use 3D models to visualize other ships in space but sprites, rendered from a total of 544 angles. I need to find the right sprite (ie. the right angle) for each ship in space, relative to my own camera orientation. Both the camera and other ships have six degrees of freedom.   While I made some progress using Matrix math and some help I've gotten in the past here on the forums a while back, we have since switched to Unity3D, which works with quaternions. I'm well aware of the fact that I can simply stick to my old attempts and convert unit quaternions to rotation matrices and back, but I would optimally like to hear if there may be a smart solution that works with quaternions throughout.     My attempt so far     Vector3 getEulerAnglesFromQuaternion(Quaternion q1) {         float sqw = q1.w*q1.w;         float sqx = q1.x*q1.x;         float sqy = q1.y*q1.y;         float sqz = q1.z*q1.z;         float unit = sqx + sqy + sqz + sqw; // if normalised is one, otherwise is correction factor         float test = q1.x*q1.y + q1.z*q1.w;                  float pitch, yaw, roll;                  if (test > 0.499*unit)         // singularity at north pole         {             yaw = 2 * Mathf.Atan2(q1.x,q1.w);             roll = Mathf.PI/2;             pitch = 0;         }         else if (test < -0.499*unit)         // singularity at south pole         {             yaw = -2 * Mathf.Atan2(q1.x,q1.w);             roll = -Mathf.PI/2;             pitch = 0;         }         else         {             yaw = Mathf.Atan2(2*q1.y*q1.w-2*q1.x*q1.z , sqx - sqy - sqz + sqw);             roll = Mathf.Asin(2*test/unit);             pitch = Mathf.Atan2(2*q1.x*q1.w-2*q1.y*q1.z , -sqx + sqy - sqz + sqw);         }                  return new Vector3(pitch, yaw, roll); }     // in Ship::Update():   Quaternion q1 = Quaternion.LookRotation(Camera.main.transform.position - transform.position); Quaternion q2 = transform.rotation; Quaternion q = q1 * q2; Vector3 eulerAngles = getEulerAnglesFromQuaternion(q) * Mathf.Rad2Deg; // use eulerAngles to pick the right sprite   My idea was to combine the ship with the camera rotation by multiplication and then use a standard formula to retrieve euler angles from the resulting quaternion. This, however, simply does not yield the expected angle values. I'm not sure if my problem can even be solved in this fashion.     In short   I would like to know if anybody has an idea how to solve my problem of finding the angle at which a camera is looking at something, combining that with the orientation of the entity itself and using the result to find the right sprite to pick for it. I have access to what seems to be very good and complete math functionality in Unity3D and would like, if possible, to find a solution following the engine's quaternion-based approach. Are quaternions even usable in this case? Or am I forced to use matrix math here?
  10. d h k

    Input nowadays

    I use SDL with Direct3D 9 (or OpenGL if necessary). It creates my window and handles my input, so I don't have to mess with ugly, scary windows code as much! Been using this for, I believe, five years now and it's always been a good choice in my book, I'm fairly confident this is one good way of doing it.
  11. Ah, got it! That was the missing piece of information. I have gone ahead and changed my game loop, Firestryke31's loop did not work out of the box, using the article I came up with this which seems to work fine and caps my update calls (ie. the game simulation) at 50 times a second (every 20ms)! [source lang="cpp"]// update the scene every 20ms (50 times a second) const unsigned int UPDATE_STEP = 20; unsigned int total_time = 0; unsigned int current_time = SDL_GetTicks ( ); while ( window->IsActive ( ) ) // game loop { unsigned int new_time = SDL_GetTicks ( ); unsigned int frame_time = new_time - current_time; current_time = new_time; total_time += frame_time; while ( total_time >= UPDATE_STEP ) { Update ( ); total_time -= UPDATE_STEP; } Render ( ); }[/source] Does this look better? Works fine from what I can tell!
  12. I understand the beauty of that game loop design, I'm really just wondering what's wrong with the way I'm trying to do it (where updating and rendering the scene is coupled)! If I can't sort this out, I can always switch to the version with fixed timestep for updating the scene but for now, if possible, I'd prefer to stay with the framerate independent updating and find out what is going wrong. Any further ideas? EDIT: last_frame_tick, this_frame_tick and time look okay to me. last_frame_tick is 17619 after about 17 seconds, this_frame_tick in the same frame is 17745, time is 127.0f that frame. Next frame, last_frame_tick then is 17745 of course. This looks to be perfectly fine to me!
  13. Will do and edit results in in a second. I'm just bruteforcing the conversion as such: [source lang="cpp"]float time = ( float ) uint_time;[/source] I didn't consider this a problem, whether the time value is 500 as unsigned int or 500.0f as float? Is this were I'm going wrong? Thanks for the response!
  14. Hello there! I'm working on a game where I use this basic game loop design: [source lang="cpp"]int main ( int argc, char* argv[] ) // main entry point { Load ( ); while ( window->IsActive ( ) ) // game loop { // update the ticks for this and the last frame last_frame_tick = this_frame_tick; this_frame_tick = SDL_GetTicks ( ); // update the scene depending on how long // it has been since we last updated Update ( this_frame_tick - last_frame_tick ); // render the scene Render ( ); } Destroy ( ); return 0; }[/source] So I update and render the scene as much as possible (with VSYNC off). SDL_GetTicks ( ) is an API function that returns the number of milliseconds that have passed since the API (ie. the game) started. In my Update ( float time ) function, I then multiply every speed (that is, a bullet moving forward for example, but also a character turning their head to one side) by that time. In theory, this should give me a framerate independent gaming experience - if we're running on an older machine, we might just get 20 fps so the time it takes to render each frame is 50 ms, on a modern machine we could get 200 fps (5 ms per frame). A bullet moving forward at an original speed of 2.5 units per frame will move at 2.5 * 50 = 125 units per frame on the slow machine and 2.5 * 5 = 12.5 units per frame on the fast one. In 1 second, on the slow machine (since it renders 20 fps) the bullet will have moved 125 * 20 = 2500 units total, on the fast one (at 200 fps) 12.5 * 200 = 2500 as well. No matter what speed the computer can run the game at, all the action will always be going on at the same rate, it's just going to look and feel a lot smoother on a better system for obvious reasons. This is the (very basic) theory from what I understand reading tutorials such as this one. But for some reason, this doesn't work for my games, when I set everything up as explained, my bullets (etc.) will still move a lot faster with a higher framerate! [source lang="cpp"]// in Update ( float time ): // GetForward ( ) returns a normalized forward vector for the projectile bullet->SetPosition ( bullet->GetPosition ( ) + bullet->GetForward ( ) * 2.5f * time );[/source] What am I doing wrong or misunderstanding here? Is the entire game loop design faulty? The article linked makes it sound like this should work (albeit saying that speed prediction methods are better, stuff I'd rather not get into without it being necessary). Any help would be greatly appreciated, as always! I'm lost!
  15. Thanks a ton, this greatly helped me sort this out in my head! I've often been thinking about how point/spot/directional light types are really just three simplified models, similar to how polygons are a model (ie. a simplification) to describe actual (oftentimes round) three-dimensional shapes.
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!