Jump to content
  • Advertisement

Leaderboard


Popular Content

Showing content with the highest reputation on 05/10/19 in all areas

  1. 1 point
    Because that is what makes a perspective projection have perspective. The division is what makes things shrink as they move further from the camera.
  2. 1 point
    I've had the pleasure working with @Brain on his game: Mr Boom's Firework Factory by assisting with some graphics as of recent. I'll post a link to his blog and gallery at the end so you can go and check it out. Long story short, @Brain had a container which he could use but it was over 260,000 Tris and had 5 texture sets, and 4 decal textures all 4k each. I offered to optimize everything but realized the meshes were too messy so I ended up just re modeling it all while maintain most of the same look (structure wise - not texture). I then baked, re-textured the container, and added the decals supplied by @Brain. The final mesh is only around 20,000 Tris, 1 texture set which is 4k (includes the decals within) which is a major reduction from the original. I did two different lighting setups to show case the containers. The first is more outside cloudy type HDR, the second is a clear blue sky one. Check out @Brain's blog, gallery, and project page below:
  3. 1 point
    Really nice assets, guys. Art looks pretty cool! Keep working!
  4. 1 point
  5. 1 point
    And now, with the scripting tool ready to be tested, and the beautiful placeholder as the main protagonist, it's time for some cinematic action. Remember: our goal was to make an rpg with a deep combat system and an entertaining story to follow (what else?!). The first thing you need to tell a story is having a story to tell. So, with a limited scope for lenght and complexity, I wrote two short scenes in my best adventure/fantasy parody style. The idea was connecting both scenes through the gameplay, making a short demo of what could be a game developed with these tools. The script is something along the lines of a couple of soldiers travelling through a desert to accomplish their super important quest, facing all kind of problems to continue their journey. What super important quest could that be? The omission of it makes it far more interesting than anything I could make up. I decided that two levels (two big scenes) was enough for a good demo. The first one being a desert, which I had to design. As the main goal wasn't a good level design, I didn't put much effort in it (altough in the next level, I tried hard making an interesting one). Even though, I think it's cute enough. So, in the intro cinematic we see these two soldiers talking about past adventures as they cross the desert. Of course, an enemy appears and then they have to fight it. The focus was not in originality, but entertainment. When I was happy enough about the script, I started translating it into the scripting tool. I splitted the work in two tasks: - Making the cinematic itself (controlling the behaviour of all characters and events in the scene). - Using a Unity plugin (Cinemachina) to "film" what the script was playing. So, on the one hand I had two characters talking for 30 seconds, and on the other I had to control from within Unity the camera behaviour. In retrospective, even if I liked the final result, I must confess I wouldn't do it like this again, mainly due to editing reasons (a living hell). Having the camera control independent of what's happening in the screen means that if I change anything (ANYTHING!) in the script, I must synchronize the whole cinematic again. That's a lot of testing and debugging. A LOT. In the following cinematics I made, I controlled the camera transitions and behaviour from nodes within the tree script, so unrelated changes usually don't affect camera behaviour. And after some work (the whole process took me a couple of days, I blame the camera issues), I finally had my first cinematic. Feel free to comment about it. So, we now have a combat system, a scripting tool, a silly story and a cinematic. The following step is using all of these things to make an actual game.
  6. 1 point
    The decision is mostly about what is most fair to players in different scenarios. If one person is on a low-resolution screen and one is on a high resolution screen, what is fair for your game? Should they show the same geography but the high res player see more detail? Or should they show the same detail and the high res player see more geography? If there are three different views, one is landscape, one is portrait, one is square, what is fair for your game? Should one see more data to the sides, one see more data up/down, one be clipped on both sides? Or should all of them be constrained to the same geography? Once you've decided those, you can implement different features. That can mean adding different quality settings based on the display, or it can mean implementing black bars (or decorative borders) so different screen sizes see the same window of the world. Exactly what is fair depends on the game. Displaying a different view, displaying more buttons or data, displaying a different shape, displaying higher resolution images, each can affect the fairness of different games, or have no difference at all in different games. Bars and borders plus a scaled viewport inside that constrained area can give you the same display on each screen, but that is also the most unpopular way to do it. Many people absolutely hate bars and borders, others will scream at you for scaling the viewport since it can blocky on their high resolution screen. Open and flowing to the screen size tends to be least fair across multiple players since bigger monitors and smaller pixels reveal more of the world. Fewer people complain about them, except in highly competitive games.
  7. 1 point
    A brief follow-up. After considerable snooping around it turns out it's possible to use Direct Manipulation in client mode - eg as a standalone source of gesture (zoom, scroll) inputs (for example, the code that comes as part of the Windows classic sample pack uses DM in conjunction with D3D and separating the two appears impossible at first). Since it took me considerable time to figure all this out, I thought I'd share how you can accomplish this: 1. CoCreateInstance an instance of IDirectManipulationManager (CLSID_DirectManipulationManager) 2. Get its update manager - you'll be using this from now on (I'll refer to it as the manager from hereon) 3. Use the manager to create a dummy viewport with some arbitrary size 4. Set the viewport configuration and call SetViewportOptions(DIRECTMANIPULATION_VIEWPORT_OPTIONS_MANUALUPDATE) 5. Add your event handler to the viewport (derive it from IDirectManipulationViewportEventHandler) 6. Activate the manager 7. In your message loop listen for DM_POINTERHITTEST. When you receive this message and the message comes from a touchpad, start polling the manager by calling Update() (the frame info provider can be NULL). Respond to the OnViewportStatusChanged() and OnContentUpdated() functions in your handler 7.1 I think polling is only necessary for touchpads since there's no event that would tell you when the user places their finger(s) on or removes their finger(s) from the pad. DM handles this internally and lets you know via OnViewportStatusChanged(). In order to tell whether DM_POINTERHITTEST is from a touchpad, get the GetPointerType() from user32.dll (it has the signature: BOOL(WINAPI*)(UINT32, POINTER_INPUT_TYPE*) ) and see if the returned type from GetPointerType(GET_POINTERID_WPARAM(wparam), &type) is PT_TOUCHPAD 8. If it is, call viewport->SetContact(GET_POINTERID_WPARAM(wparam)) 8.1 Stop polling when you receive the current status DIRECTMANIPULATION_READY in OnViewportStatusChanged() 9. In OnContentUpdated() call content->GetContentTransform() to get the floating point transform 9.1 You can make the transform relative within a gesture by calling ZoomToRect() on the viewport and resetting the coordinates in response to DIRECTMANIPULATION_READY A couple of notes: In a naive implementation scrolling by clienting DM like this seems is less smooth than what the MS-provided compositor does. However, the latter is purely DirectX-based and handles drawing/input handling in some complicated mulithreaded way If you don't want to wrap the DM code, it should be possible to use something like ANGLE to relatively easily get your GL FBO into D3D (or I guess you could manually download->(convert?)->upload the frame buffer). However this still requires your display surface to be DX-based. My knowledge of DX in general is poor so I won't comment further. Have a look at the link above for an official example how to do this if you're working with DX natively I wrote my own input accelerator on top of the data received from DM. However the results should get better once I transition away from WM_TIMER-based polling, optimize the draw code (framerate/smoothness really matters for a natural scrolling experience) and implement a floating point scroll accumulator that feeds directly into my accelerator as opposed to marshalling DM input through WM_MOUSEWHEEL messages (which only supports integral coordinates) If you have some time for a fantastic read on a topic that seems extremely simple and mundane, have a look at the article Scrolling With Pleasure by Pavel Fatin I hope this helps saves some poor soul a few days of in the future.
  8. 1 point
    Thanks! I remember having a Magic the Gathering port done on my graphing calculator. Good fun!
  9. 1 point
    PC too? Not only mobile? $100K is too low. Expect it to be 5 times that, at minimum.
  10. -1 points
    I have a game idea. Is there anyone willing to make it for free? You may sell it! So, My friend and I have been fantasizing about a villain name Kick Nilley who is extremely fat and the size of the empire state building and eats everything in sight I want it to be about a crew named the Otings who train and fight to finally one day defeat the great Nick Killey. Their leader is Lord Oting and Lord Fatape who is basically King Kong but fat. What do you guys think? Is anyone willing to do this game for free? You may sell it!
  • 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!