• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

Postie

Members
  • Content count

    324
  • Joined

  • Last visited

Community Reputation

1559 Excellent

About Postie

  • Rank
    Member

Personal Information

  1. Not bad. The biggest issue I see is not providing the player feedback on certain game events. For example, when the player or enemies take damage. Because the game is about dodging, it is not immediately obvious if you were hit or managed to get away. You could briefly flash the player red or play an appropriate sound effect (or both). Another suggestion I have is to add inertia to the player's avatar. So instead of just updating the x,y positions of the player when you hold down the movement keys, you use an acceleration vector to adjust the player's velocity and apply a dampening effect when no keys are held to bring the player to a stop. This can be quite effective in making the controls seem smoother, just don't over do it :).
  2. Your calculations seem correct. Definitely sub-optimal, but ok for a "reference" implementation as you mentioned. I think the problem is with the final step where it converts the distance data to the bitmap for visualisation. Your technique scales the entire distance field based on the maximum and minimum distances.  I've found that clamping the values to a certain range produces better results. For SDF's the important information is generally around 0, so I kept my distance values to the range (-64 to 64 pixels), anything higher or lower is clamped. Then you map that range of distances to your grayscale. Another thing I just thought of, is that your algorithm may not permit a minimum range of 0, since its always looking for texels that are opposite to the current one. Therefore the minimum distance may always be 1, which would explain the discontinuity as the gradient would go directly from -1 to 1.
  3.   That's pretty much what I was saying. Serialise the properties that are dynamic. Assume the properties that are static.   For a more concrete example, I had an "EdibleComponent", which was given to entities that could be eaten. I also had an "EdibleComponentTemplate", which defined the food and water values you'd get from eating it. These values are static, so I didn't serialise them. The edible item can spoil over time, so there was an Age property in the EdibleComponent which ticks at different rates depending on how it is stored (refrigerated vs not etc). Since that property is dynamic, it is serialised.    So a mocked up example of how the serialised file might look:   The entity template: Name = core.entities.redberries <Edible>     FoodValue = 15     WaterValue = 20 </Edible> Serialised Entity: Template = core.entities.redberries <Edible>     Age = 123 </Edible> Obviously these can be stored in whatever format you like, this is just in text for clarity. You can replicate the properties from the template in the component or have the component reference the template. Eg:   entity.GetComponent<EdibleComponent>().Template.FoodValue; vs entity.GetComponent<EdibleComponent>().FoodValue; I prefer the former as it makes it easier to tell which properties you should be serialising in the EdibleComponent class. Hint: everything! :) In the latter you have to remember which is which.
  4. I've previously tackled this by having components and "component templates". Think of component templates as the properties of an component that do not change during the course of the game. For example, how much health a power up gives, or the dexterity requirement of a weapon. The component templates are bundled together into an entity template with a unique identifier.   When instantiating an entity, you pass in the entity template and create each of the components it requires, using the relevant component template.   Then, on serialisation you only serialise the dynamic properties defined in each component. Eg: transform, current health value etc. None of the properties in the component template can change, so there's no need to serialise these. But what you do need to know is which entity template was used to create the entity. So, you also store the unique identifier for the entity  template. On deserialisation you read the entity template identifier, instantiate a new entity exactly as it was orignally spawned, and then deserialise the components' properties into it.   A note on unique identifiers: I found using a string ID that resembles a namespace was much more flexible and robust than using an integer. For example: "core.entities.longsword" rather than "123".    It's easy to assign meaningful id's and also handy if you want to offer content expansions or themed content. In my example, I used "core." to represent the core (always included content), and you could use "halloween." to include content that should only exist if the game is played during halloween. Enabling/disabling this content at runtime is then trivial.   I also wanted to support modding, and having a namespace like structure makes id collisions almost impossible. Eg: "mods.mikesweaponsmod.rifle" vs "Id = 4567". How likely is it that a mod creator is going to be able to guarantee the Integer Id's they've picked can never conflict with other mods?    In addition, a saved game may reference entity templates that are defined in a mod that is no longer installed, and you have a much better chance of handling the situation gracefully if the templates are identified by a string rather than an Id. eg: missing entity : "Id = 1234" vs missing entity : "mods.extratrees.birch".  
  5.   +1 for Amit's tutorial. One of his strengths is visualising algorithms, and his A* tutorial is great. 
  6. Well, I just learnt something new. Thanks! :D
  7. This behaviour looks a lot like something I was dealing with myself about a month ago. If the joint rotation's origin isn't correct, the vertices of the mesh stretch rather than rotate around a common point. In my case it was due to how I was composing the final Translation Matrix for the bone.   The bone has a bind pose translation matrix and I needed to apply the desired local rotation. For it to work correctly I had to decompose the bind pose translation matrix into separate Rotation and Translation matrices and apply the local Rotation in between the two.   Eg: If the Bind Pose translation matrix is made up of R x T, and the desired local rotation is Y, the final transform needed to be R x Y x T, not Y x (R x T) or (R x T) x Y.    It's confusing, because none of the sources I consulted mentioned the need for anything like this, but without it, I couldn't get it to work properly.
  8. In my opinion the biggest issue is the eyes. He's not quite looking directly at us, but he's not really looking away either. It's a little weird.
  9. I'd recommend the tutorial based approach at least initially, to give you something to start from. Starting from scratch without guidance can quickly lead to frustration.   Once you're comfortable with what you've learnt, by all means go "off script" and try things out on your own! :)
  10.   Heheh. I remember when I made that exact statement about my game project almost 5 years ago. I also remember 6 months ago when I suddenly realised why it was a bad idea and spent a few months refactoring everything to remove all globals.   Globals are seductive because they are easy to use and let you share information between different objects very easily. But you eventually end up in dependency hell, where to test a small system you need to recreate the entire game state, since object A references systems B and C, and they rely on D and E and F.. etc   The best thing about the mindset of passing dependencies instead of referencing them through globals, is that poor design stands out like a sore thumb.
  11. We've adopted new methodologies at work which I've carried over to my hobby projects, and similarly I've used hobby projects to learn new ideas that I've then suggested we adopt at work. There's more formality in place at my work, eg: Continuous Integration, Gated Checkins, the occasional code review, but there's not a "Work" and "Home" version of me as a developer, there's just me. :)
  12. I struggled with Raknet for a few hours just trying to get it building. At the suggestion of a friend I ditched it in favour of Lidgren. It was easy to use and I was up and running with simple client/server comms in no time, so I'd definitely recommend Lidgren over Raknet. I recently discovered that Lidgren has a nuget package which makes getting access to it even easier than the github way if you don't need the source code. 
  13. If you're not doing console game quality, it opens up the floor a bit more, so alternatives to c++ become viable. I'm working on a game project at the moment which is a mixture of C# and Lua.   To answer your question, the "best language to use" is probably going to be whatever language *you* are most proficient in that has a Lua implementation. 
  14. I second Alvaro's suggestion re: the Heap. I remember reading about A* and not know how a heap worked it seemed pretty scary, but once I had a crack at implementing it and it started to made sense, my A* implementation became several orders of magnitude faster. 
  15. Unless you have an infinite map, you have to do some kind of test to make sure you don't go outside the map bounds when looking for neighbours at the edges of the map. If you treat impassable terrain the same way, it will never be processed.    Also, remember, high cost is not the same as impassable. If the numbers align, that node may be considered a viable route.