Jump to content
  • Advertisement


The search index is currently processing. Leaderboard results may not be complete.

Popular Content

Showing content with the highest reputation on 05/14/18 in all areas

  1. 3 points
    So I have finished the basic drag and drop to place various turrets in a level. This was easier than I thought it was going to be. But I'll give a rundown of what I did and how its set up. All I have to do is make it prettier. I'm going to make the default color very transparent and have some sort of color or material to make it look good. Then when the player drags a turret over a spot that can have a turret I will change the coloring and/or alpha to highlight which spot the turret will be at. The basic overview of UE4's drag and drop functionality is to override the OnMouseDown, OnDragDetected, and OnDrop functions and create a UMG widget to represent the item being dragged. That's about all there is to it. So I will get into the fun stuff now. There is a more in depth tutorial I followed that made this a little easier to understand. You want to override OnMouseButtonDown and OnDragDetected in the widget you want to drag. In my OnMouseButtonDown I first check to make sure the turret has been unlocked before dragging. This prevents the player from dragging a turret they have yet to unlock. Then we set an offset that will be used to offset the drag image from the mouse/finger. Then chose which input you want to listen to for dragging. I chose left mouse button as that is a normal drag and drop behavior and I also have my settings to map clicking to touching so this also works on mobile. As far as I know that setting is on by default. But if you want to make sure in Project Settings -> Input then find Use Mouse for Touch or just search for Use Mouse for Touch. Also in the widget you want to drag I overrode OnDragDetected which handles what to do when the system detects a drag has started. Again I make sure the turret is unlocked before continuing. Then create an instance of the widget you want to use to represent the item being dragged. For me its just an image of the turret slightly larger and with a small alpha applied to make it look a little different. Then using the CreateDrag&Drop function we create an instance of a blueprint we have to create that extends DragAndDropOperation. The Default Drag Visual is what the system will use as the drag continues. And the Drag Widget is a hook to the widget you actually want to drag. And this is it for the drag part of the operation. Now you must override the OnDrop function in whatever widget/HUD you want the item to be dropped in. I have a separate widget I'm using to handle the dropping. This allows me to place these where I want the player to be able to drop a turret and anywhere there isn't one, the player wont be able to drop it there. I set the locations in another place where I can manage each of the drop widgets in one place. So I spawn a PaperCharacter as the turrets will eventually need to spin/move and have an AI. Then I hide the drop widget so the player can no longer drop a turret there and return true to indicate the input was handled. And that's it for the basics for drag and drop. You look at the tutorial I linked to above for more detailed information but this should be enough to spark some ideas on how to use it in your project. After I make some minor visual changes to the dragging and dropping I will then move onto creating the first enemy ship and a spawning capabilities so I can put together a first demo level for people to check out and play. http://www.hunter-gaming.com/ https://www.facebook.com/indiehuntergaming/ https://twitter.com/HunterGamingInd
  2. 2 points
    Introduction In our 3D game (miimii1205), we use a dynamically created navigation mesh to navigate onto a procedurally generated terrain. To do so, only the A* and string pulling algorithms were more specifically used until our last agile sprint. We recently added two new behaviors to the pathfinding : steering and wall collision avoidance. In this article, I will describe how I achieved a simple way for agents to not walk into walls. Configuration 3D or 2D navigation mesh, as long as the 3D one is not cyclic. Navigation cells and their : polygonal edges, connections (other cell), shared edges (the line intersecting between two connected cells), centroids and normals. An A* and string pulled (not tested without string pulling) generated path consisting of waypoints on the navigation mesh. The Algorithm The agent is the pink low-poly humanoid and the final destination is the flag. The ideal algorithm (yet unoptimized) would be to cast an oriented rectangle between each consecutive waypoint where its width is the two times the radius. Think of the agent's center position being in the middle of the width. Anyway, this algorithm is too complicated, too long to develop for our game, too big for nothing and so I thought about another algorithm, which has its drawbacks actually. However, it's more suited for our game. Psss, check this article if you haven't seen it yet. The algorithm is the following : For each waypoint, pick the current one and the next one until the next one is the last. Iterate over the current navigation cell's edges, which is defined by the agent's 3D position. To do that, you need a spatial and optimized way to determine the closest cell of a 3D point. Our way to do it is to first have have an octree to partition the navigation mesh. After that, get all the cells that are close to the point plus an extra buffer. To find the cell that is the closest to the point, for each picked cell, cast a projection of the position onto each one of them. This can be done using their centroids and normals. Don't forget to snap the projected position onto the cell. After, that compute the length of the resulting vector and pick the smallest one. Convert each edge to a 2D line by discarding the Y component (UP vector). For each side left and right, which are defined by the agent's position and direction towards the next waypoint, cast a 2D line that start from the agent's position, that goes towards one of the two perpendicular directions related to the direction to the next waypoint and that has a length of the defined radius. If there's an intersection on a connection and that it's on the shared part of the connection, then continue with the connected cell's edges. If there are any intersections other than #5, create a new waypoint before the next waypoint. This new one's position is defined by the intersection's position translated by a length of two times the radius and projected towards the agent's current direction as a 2D line. The same translation is applied to the next waypoint. Cast two 2D lines, one on each side of the agent as described before, starting from the sides, going towards the same direction as the agent and of the same length between the current and next waypoint. Check for #5. If there is an intersection on a connection and that it's on the unshared part of the connection, then do #6 (no if). If there's an intersection on a simple edge, then translate the next waypoint as described in #6. Here's a video of the algorithm in action :
  3. 2 points
    Finally made a video: This doesn't have the terrain showing, I figured out it is quicker to make a build with terrain switched off, and it increases the filesize quite a bit so I might drop the terrain, not sure yet. I put in support yesterday for more than one enemy type, I have got a third type but haven't put in yet. These will have different strengths / health / speed. Also spent ages debugging yesterday from a nasty c# references bug, first time I've had to do any major debugging and it was difficult because I only have debug.log statements to rely on, as yet I have no debugging in monodevelop. The reason for the bug was because I'm using pooling for my game objects, so as not to new and create unity objects, they are just reused and position and visibility switched. So I have an intermediate 'reference' (another reference!) actor which stores which pooled actor of each type in is an actor slot. This makes it slightly more complex the adding and deleting actor code. Anyway when deleting an array element, I switched the last array element with the one to be deleted, then decrement the count. However, in c# the = operator does not copy the data like in c++, it copies the reference, so all kinds of unpredictable behaviour was resulting. Anyway, bug solved, crisis averted! I also put in some basic auto cameras. They work pretty well. There is an overview of the whole board, which does not change, a follow cam which zooms in on a particular actor, and an area cam, which treats all active actors as an area to focus on. The follow cam actually follows a point just ahead of the actor, because there is a delay from the smoothing. The area cam needs a little tweaking to get better. Next I need the other enemy type, and different tower types. And I need to put in a special big building or something for your base, maybe with some particle effects to show it being destroyed.
  4. 1 point
    Thanks guys! Been out all day today riding 200 miles in wales, should get some more done on the game tomorrow. Sound is working and music along with animation events on footsteps etc, and there is a 3rd enemy model now.
  5. 1 point
    I had a chance to watch your video last night and I'm very impressed with your progress. Keep up the great work!
  6. 1 point
  7. 1 point
    Hello everyone! From today and all week long you can vote for Pixelpunk XL in the Game Development World Championship. Here is the link: https://thegdwc.com/
  8. 1 point
    The new sprint is here, and we ticked off some work items during the last one, i.e. we finished modeling the furniture for Clearwater’s kitchen in his apartment. We also did UWV Unwrapping, and put a nice texture on all the cupboards and stuff. We imported the kitchen to UE4 and it looks fine. We also finished modeling the furniture for his home-office and did all the UWV-texturing-UE4-things we made for the kitchen. We fixed some bad looking things on the main-character Charly Clearwater himself. We adapted his cloth and skin materials, his proportions and so on. We bought him shirt buttons, a watch and a golden ring (as he is married to Amanda by the way). See the short video below. We adapted his walking animation like a thousand times before. We improved some other animations, too, that would be relevant for the new video. We continued modeling the world-outside-Charlys-apartment-window (replica of the concept art made by our concept artist as you can see below) and created approx. one billion pieces of polygons (at least it felt like…) to build houses for Clearwater’s friendly neighborhood. Are you interested in a new apartment? 😉 We haven’t finished it yet. It’s a topic for the current sprint. The book BIZARRE Episode I is getting longer and longer. The introduction to this book, called BIZARRE: Alltagskiller (that is already published), includes a book called Excess (the book-in-book-kind-of-thing). Excess is an erotic thriller that Charly Clearwater writes during the main story, i.e. during the fulfillment of these 13 bizarre wishes. So, the reader will read two books in one while reading the book BIZARRE Episode I. After having finished the writing of the main book, the writing of Excess begins. The book is going to be heavy! 😉 Furthermore, we made a design drawing of the evil Egyptian power (see below) that is causing the whole drama to the main-character and intends to rule the world. We’ll model her and the people of this culture sometime later, after we have completed a thousand other things. We have a lot of ideas regarding her appearance and that of the ritual and cultic objects of the people from Vï|IV. Our plans for the next sprint are (see the product backlog below): We continue modeling the houses for the world-outside-Charlys-apartment-window. We improve Charly Clearwater’s appearance by adapting his skin envelopes and vertices, again. We program some things in Blueprint to optimize the correct usage of the proper animations for CC. We program the shooting animation in Blueprint and test them till we drop. We test some facial animations for CC that didn’t work when we published the colored woman video last year. In case no errors occur this time, we’ll start modeling some nice facial animations for main-character Charly Clearwater, all relevant for the new video. The facial animated Clearwater is important for the new game blog that is still unpublished, as well as for some new full body 4k pics of CC that we intend to render any time soon. We want to paint another concept art of the next game scene that we’ll probably recreate after the completion of the apartment scene. By the way, do you remember the colored woman? 🙂
  9. 1 point
    Hey again. First off, I had to change the blog title. I won't be working on the 3d platformer anymore because my computer crashed. Short story: I was working on the physics in Unity and I was having trouble, so I tried to stream my work on Twitch. Well, with OBS, Unity, Blender, and the internet running, the motherboard on my Asus overloaded... or something. My screen went black and when I googled it on another computer, I got a few ideas as to how to fix the problem. Basically, I need to take my computer to the geek squad and see what they can do for me. Additionally, however, I just moved to a new place. I'm transitioning between jobs, and I haven't had the time or money to get my computer fix. Which brings me to my "new" project.... A while ago I was working on a 2D platformer that was in the style of Castlevania and Spelunky, but with a more interactive story line. This project was a way for me to practice pixel art. I was inspired by Mort Mort who is a great pixel art guru that I follow on Youtube, Twitch, and Twitter.(@MortMort) He posed a challenge for beginning artists: choose 4 colors to be the color palette and design pixel art for a small scaled project - like 16x16 or 24x24. So, this is how my 2D platformer came to be. During the creation process, however, I lost enthusiasm, and I eventually thought that my game was boring, uninteresting, and contained poor art, but since my computer crashed, I revisited my old project on my older computer and I think I could make it work. Now, the project that I will be blogging about it called Zero. It follows the journey of Marcus who must collect "orbs", or zeros, from undead creatures for Professor Fyle's experiments. Marcus must collect a certain amount of zeros per level to advance. Here is a devlog that I started in 2017 when I started this game. Video 1 Video 2 And here are some visual updates: Currently, I am working on giving the first levels a soundtrack as well as creating sound effects. So this upcoming week's focus will be sound and when I need to shift focus from FL Studio, I will continue on working on art for the game. The next blog will be more detailed. Because this is a project I am picking up on from the past, I didn't want to go through everything that I did in terms of development process, but if anyone has any specific questions, I would be glad to provide more information. Until next week! Happy Mother's Day!
  10. 1 point
    I understand, but typically that means layers are built for each agent radius. It's a trade-off of course, but it solves enough of the issues that it is usually worth it for most games out there. Especially when there are freely usable navigation mesh libraries out there like recast. I'm mainly curious what your reasoning is though. I have spend considerable time in the past on my hobby project experimenting with a manually built un-retracted navigation mesh, but it was annoying enough to try and handle the agent radius at runtime that I shelved it. That was many years ago though. For various reasons I've felt like trying to revive it recently, because for my particular use case(a bot in older quake based FPS engines, although I am parsing the collision of the map data to generate the navigation, there is a lot of noise and trash in the output that takes considerable effort to trim out, and still more manual effort to provide contextual information (team specific markup, etc) Here's a really old video showing the tile based recast driven traditional navigation mesh. https://www.youtube.com/watch?v=5qYgRA5oINs Problem is that although I can trim some amount of data from these maps(like brushes marked as sky boxes, etc, even so the resulting data set still contains enough collision data that I get for instance a lot of navigation on "top" of the world, where the brush flags can't be automatically considered relevant or not, even though the navigation inside the world is reasonable, there is a lot of of garbage navigation as well, and enough https://imgur.com/a/r3BbBxn (etf_2fort recast auto navmesh, without hiding a lot of top brush fases you don'e even really see the important navigation of the world) This is another old video of the non retracted navmesh I was experimenting with way back as well, once I got dynamic obstacle support working. There was a lot to like about where this was heading, even though the navmesh was manually built, but I ultimately burned out on compensating for the radius stuff at runtime. There are a lot of edge cases in a real world 3d game map. https://www.youtube.com/watch?v=UhSNwaTV3II I've recently gotten re-interested in my bot and am thinking about giving this approach another go, since after spending a lot of time on the automatic recast drive building, I'm finding that I still have to spend considerable time fixing up the data to trim out data where I don't want it, mark team specific regions, where the resulting time to produce a completed navigation doesn't save much, especially since the manual navmesh creation process is not only very fast with the way I have it set up, but it's very precise and results in far less regions in the resulting data set. Plus I have various shortcuts that take advantage of my problem space, such as the tendency for symmetry in the game maps the bot supports, so I can do half the map and then mirror all the sectors over to the other half. Here's a map where only the green areas have been layed out, and the cyan sectors have been mirrored for the other half of the map https://imgur.com/a/1r1qlYS
  • Advertisement

Important Information

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

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!