Jump to content
  • Advertisement


Popular Content

Showing content with the highest reputation since 10/15/18 in all areas

  1. 3 points
    I work on a walking ragdoll driven by pure physics simulation, which is one step ahead and much harder than procedural animation, but the thing's i've learned there would be useful to make animation realistic. Because humans are upright all their motion is dictated by balancing. The COM is very high, and the support polygon is very small, so we end up balancing all the time. The game discussed in the video certainly misses to capture this. (Although i consider it very good - that's progress and interesting, and fun too. Great Work!) So, balancing works by keeping the center of pressure (COP) inside the support polygon. (Support polygon is the 2D convex hull around the feet, projected to the gravity plane.) We have control over COP position by ankle torque, but it requires planning ahead and ends up to be a difficult control problem, the equations result in very complex calculus. I've learned some things from robotics papers, but they did not really knew solutions and ended up at approaches that are unable to utilize what's possible, resulting in slow robots, e.g. that cute Honda robot. Exception is Boston Dynamics - they solved this, but they do no longer publicate (they did when it was a university project). The main problem in practice is: Assume you can not take a step, but you have to move your COM to a target position, e.g. move the pelvis to the right. To do so, at any point you would need to calculate the necessary deacceleration so you are able to stop, which means the COP can bu hold within your right foot. If you accelerate too fast to the right, the contact point that could stop that motion moves outwards the foot. In this moment your COM is till in the support polygon, but tipping over or making a step to keep balanced in the future is already unavoidable, which means you already lost balance. The most efficient motion you can do at all is to move the COP forth and beck between the edges of your feet. Try swinging your pelvis sideways as quick and wide as possible and observe the forces you apply to the ground from your feet. You see you can not do this very fast, and the forces are big. So, after you've gone through implementing IK (which is just a necessary detail), you may want to approximate this behavior and add it as a constraint to any procedural target motion, then the result should be realistic. The usual way to do this is to use an inverted pendulum model, which is set up to have equal mass, center of mass, velocities, moment of inertia then the sum over all rigid bodies of the skeleton (if we would talk about physics simulation). I can not list any resources, sorry, but google for Center Of Pressure, Zero Moment Point and Inverted Pendulum Model. For now you are probably interested in IK, which is about calculating joint angles to reach target positions with feet and hands, bending spine in curves, looking towards a target... stuff like that. You will also have to think about the speed and form of motion. What works pretty well is to move with constant acceleration (not constant velocity - that's robotic). Se when grabbing a health pack with the hand, the hand becomes faster as it moves to the midpoint, then starts to slow down and ends up at zero velocity on the target, speaking simplified. (You can model this with matching parabolic curves.) Good luck!
  2. 2 points
    Hello there, welcome the 18th edition of your favourite weekly update! 😃 Last week was really intense. A lot of things were going on at once, so without any further ado, let's cut to the chase! Pieces of equipment First, there's now pieces of equipment in the game. Players can now stumble upon t-shirts, runnings shoes, gloves and baseball caps during their run. Here's a picture of pieces of equipment in malls: In essence, pieces of equipment give the player unitary stat bonuses (things like +1 or +3) when worn. Pieces of equipment can also have a focus alignment: when worn by the player, his focus will be progressively pulled towards its focus alignment. There'll also be additional stats bonuses (and even capacities) when his focus is aligned with a piece of equipment. This means that managing your equipment is critical to have a good run. The player can hold different kinds (or slots if you want) of pieces of equipment. These are: Headware (caps, hats and whatnot); Neckwear(necklaces, neck chains, etc.) Chestwear (T-shirts, chest plates and so on); Handwear (Gloves, rings, etc.;); Footwear (boots, shoes and whatnot). The player can only hold one piece of equipment per slot. He can, however, replace his equipment by simply grabbing another one. GUI refactored Second, I've also done a big GUI overall. Although often forgotten by both gamers and developers, the GUI has an important role in games: they are often the primary way for games to tell their player critical pieces of information like their current health, money or current stats. The GUI was actually a copy-paste from the game's previous iteration with Lemur and JMonkeyEngine. With this refactoring, I've tried to use Unity's GUI components at their fullest. I personally think I've cut the mustard with this one. Status Screen Let's take a look at the status tab of the pause menu: As you can see, everything was kinda bare. There were no ways to tell where everything was, and quite frankly it was all over the place. Here's a look at the newly redesigned one: Now that's prettier! Things are nicely labelled, aligned and positioned. There are even components that were previously hidden, like the Relics section and the Focus section. There's even an Equipment section, along with a new Item section. Also, the status screen is more interactive than ever before! Some components have tooltips, showing useful things like name, description and many more. Relics Let's take a closer look at the relic section: This is where all collected relics go. If no relics were collected yet, a placeholder text is displayed. Each relic is displayed using a nice pictogram from my custom Open Type font. As a bonus, the section is scrollable. This means that if there's a whole lot of relics the view can be truncated and controlled using a scrollbar. (Keep in mind that I've enlarged the icons sizes to show the scroll bar) Equipment The display is quite simple: it's a minimal silhouette of a human body. Each equipment slots are placed according to their type (e.x. the headwear is on the head, etc.) When a slot is empty, a pale "X" is displayed. Otherwise, a glyph representing the grabbed piece of equipment is displayed. Each of these has tooltips attached to them, showing the pieces' name, description and quality. Focus This is a barycentric coordinate component rendered as a triangle representing the player's focus. The only thing new is that it's now properly aligned and labelled... (Now look how happy it is with its proper title!) Item This component shows the currently hold activatable item. Not unlike equipment slots, having no held activatable items yields a pale "X". It also has a tooltip displaying the item's name and description. Foods Previously, foods timers were rather obnoxious: their timers were displayed right in the middle of the screen. If many foods were eaten at once then all their timers would overlap. Now, food timers are properly displayed with tooltips. When the player eats a food item it will place itself to the right of the pause menu in a vertical stack. This is not unlike how Minecraft deals with its potions effects. Once a food timer runs out, the component is removed. Dialogue box Previously, dialogue boxes were of static sizes. They were really big with a whole lot of empty space everywhere. Now that I use Unity's GUI layout at their fullest, dialogue boxes can be resized according to their content. Gone are the static sizes! Here's how it looked before: As you can see, there was a lot of wasted space. It also arbitrarily breaks its text for no other reason than to keep its dimensions. And now look at the new one: Now there's almost no wasted space. Everything fits snuggly now and feels more believable. Restroom I've previously added a restroom room but it wasn't functional yet... With the inclusion of pieces of equipment, the toilet can now fulfil its role as intended. The idea is that the player can discard one of his equipment by flushing it down the drain. The toilet will obviously clog afterwards, as generally speaking toilets aren't made for this kind of stuff, making it a one-time use. Flushed pieces won't appear later on in landfills so this is permanent. Here's a look at its dialogue box: Within the dialogue there are some similar components to those used in the pause menu's Equipment section, but with a twist. Each of these components acts as toggles (or radio toggles if you want). When the player chooses one of his equipment to flush a visual queue is displayed within. Below that, there's a bit of text that indicates which piece is currently selected. After everything is said and done the player can then click the "OK" button at the bottom of the box. This will spawn a confirmation popup: The player can then just confirm everything by pressing "yes", after which the equipment is flushed and the toilet is clogged. Minor Updates Random collectables are now chosen by asserting how much the player needs a particular collectable: We then can do a luck test to see if the player actually gets to have what he needs or not: Yes, this is cruel for some, but also rewarding to others. Fixed some shader stuff; Optimized the GUI (Dhu 🙃😞 Previously I wanted to reuse dialogue boxes. This was however kind of hard and cumbersome, especially for dialogue boxes that were rarely used at all: It was also a pain to deal with this with the Restroom's dialogue (because the whole process uses TWO boxes). Abstracted GUI window controller classes: Horray for abstraction! 🙏 Re-added the Clothes Mall, which was removed due to lack of equipment; Added a bunch of placeholder notification everywhere: These would be polished later on. foreshadowing??? 😶 Added a whole lot of localized text: Now begone "Localized text not found"! 😉 New Music I've also had the time to compose some stuff during last week. Take a look: I'm not quite sure where to use this, even if I titled it as "Tutorial", I'm not even sure if there's gonna be one. Next Week Boy, this was a mouthful! But when it rains it pours, and this was really a necessary evil. I doubt the next one would be as filled to the rim as last one. However, there are still things to do. It ain't over till the fat lady sings. I think I'll work on notifications next: They are in a dire need of polish. I also need to continue the polishing of GUI: I didn't walk the whole nine yards. Afterwards, it's the usual suspects: Rooms, Relics, Capacities, etc. But then again I have bigger fishes to fry. 😉
  3. 2 points
    This is a concept for the layout of the equipment room. In the centre will be a reclining, operating chair with a spotlight about it. This is where the player will sit to get their spacesuit repaired. Lasers will shoot out of the light attachment from above and repair the suit with its futuristic technology. There are shelves at the sides of the room holding general space equipment: helmets, space suits, boots, and oxygen tanks. This room will have the same background music as the game, and the laser beams may have a sound effect. - Kristen
  4. 2 points
    You will have to iterate multiple ways (depending on your skill level) on your system's api before you get to a state where it's clean and easy to understand what that system needs. I would advise AGAINST an explicit message system between systems, and I would focus more on cleaning the API of the system you're currently working on. So For example, if one of your renderer's call is: void DrawCube(GameWorld* world, GameAssets* assets, GameDatabase* database, Vec3 position, Vec3 dimension, Vec4 color) Then you should probably start investigating why that call needs the world, the assets and the database pointers, as logically a renderer wouldn't need those. Probably you need just some parameters taken from them, and so your call can then become: DrawCube(DrawCubeParams params, GameAssets* assets, Vec3 position, Vec3 dimension, Vec4 color) where the caller sets all the necessary params. I personally think that this is the only way one can get to clean and good api. Leonardo
  5. 2 points
    Moderation note: We're here to recommend books and resources to help Maledict to write 3d code. What is or isn't included in specific degree courses, or you have learned in your personal education is not really relevant. Please stay on topic. To that end, it's not specifically a maths resource (although it does include some relevant maths), but Scratchapixel is a great free online resource if you're interested in computer graphics.
  6. 2 points
    That looks about right for any rotation order.
  7. 2 points
    What about: Current operation: Copy A to B. Operation failed: Copy A to B. Operation succeeded: Copy A to B. Confirm operation: Copy A to B No problem with irregular verb conjugation at all Also works for localisation into languages where verb tenses aren't formed similarly to English, etc.
  8. 2 points
    I once wrote a shader to try and measure this and got numbers of around: K$ (Constant Cache): ~16 cycles L1 Hit: ~116 cycles L2 Hit: ~170 cycles
  9. 1 point
    Well, I dunno now.. this seems to be saying I was right. from: https://open.gl/transformations "To create the view transformation, GLM offers the useful glm::lookAt function that simulates a moving camera. The first parameter specifies the position of the camera, the second the point to be centered on-screen and the third the up axis. Here up is defined as the Z axis, which implies that the XY plane is the 'ground'." But this is not my area of expertise, so I will leave you with that. Hope it helps somehow.
  10. 1 point
    Can you play a card only at one time? For example, if a card can be played "before the turn", does that mean that it can't be played during the turn or after? I guess if you are playing a card game, it makes sense that you play cards during the turn. So you only need explanations for the other two rules. If you don't want icons on the cards (and I assume this is a video game and not a game with real cards), you could have the cards that can be played at the moment be brighter, have an outline or shine. Similarly, you could make cards that can't be played at the moment dimmed or dark. For example, before the turn only cards that can be played before the turn are shining. When the turn starts, the cards that can be played during the turn start shining, and so on.
  • Advertisement

Important Information

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

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!