• 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.

Sandman

Members
  • Content count

    4866
  • Joined

  • Last visited

Community Reputation

2210 Excellent

About Sandman

  • Rank
    Contributor
  1.   Currently, I don't think Turkey meets the requirements for EU membership. I don't think that is likely to change so long as Erdogan is in charge. Once they do, I wouldn't really have a problem with it. The way Turkey's membership has been talked up and exaggerated by the Leave campaign is just an example of how they appeal to the racist elements in society.
  2.   Those contributions are small compared to the value of being a member of the single market. And if we want to be part of the single market, we'll still have to make those contributions to the EU, except we won't get any rebates, or say in how it is spent.   The majority of the strain on public services is a result of chronic underfunding. Any strain placed on them by immigrants is more than compensated for by the contribution those immigrants make towards them, either from paying tax or by actually working in them. 
  3.   Yes, if we ask the EU very nicely, and they don't feel too inclined to make an example of us to deter other nations from leaving, then in a few years we might get a deal that's worse than the one we've just thrown away. 
  4. Wait until Merkel gives away visa-free travel to 75 million Turks. Then you'll thank Nigel on your knees...     Is there a particular reason why? Or is this just racism and fearmongering? Bear in mind I actually live in an area which has quite a large number of turkish immigrants.
  5.   If we want to remain a member of the single market and/or do any trade whatsoever with the EU (which we do) we still have to comply with those regulations, except we just threw away any influence we had over how they are made.   I struggle to see any positive side to this result, it's more a question of how terrible it will turn out to be.
  6. Why use an ArrayList? Dictionary<string, Archetype> would seem more appropriate here.   Also, this may not be a particularly great use of inheritance. Inheritance is appropriate when the derived classes share their interface with the base class. However this doesn't seem to be the case here, which is precisely why you're having this problem. I'd be inclined to flatten the hierarchy, kill all the subclasses and turn Archetype into a generic grab-bag of properties which can contain appropriate values for any objects in your game. 
  7. I don't really understand what this has to do with Coroutines either.    The issue seems to be a fundamental issue with using a stack (a graph is a better model for state transitions).
  8.   As Ludus says, this is quite similar to what RPGs have been doing for a long time. To be honest, I've never felt that the depth you describe above ever really emerges. All too often it boils down to learning which weapons are good vs. which enemies, and swapping out equipment accordingly. And that's just inventory management.   For me, depth is more likely to come from weapons which could affect the battlefield in much more strategically interesting ways. A napalm weapon for example, might set a unit on fire which can spread to other units. Perhaps you could also use it to target the ground, creating a patch of fire that damages anything moving across it and acting as an area denial type weapon. And of course, it could burn away vegetation, turning dense cover into open ground.   You could still have special resistances and weaknesses, but I still think they can and should be more interesting than just "takes 10% more damage from fire". Suppose there was a bombardier unit - perhaps they explode when killed with napalm, putting out nearby fires, but doing blast damage at the same time. Now things are starting to get interesting - killing a bombardier unit with napalm might kill other nearby units, but it might damage your own/put out some of your area denial fires, etc.
  9. A common mechanism in infinite runner type games is to put something nasty behind the player. Perhaps a giant steamroller is chasing him - not especially fast, but fast enough to discourage backtracking or standing around.
  10. From my experience, watching a bunch of numbers get higher is not very exciting. When I level up, I want some new toys to play with.   By toys I mean: special abilities, spells, weapons etc. Things that provide more meaning and utility to my character than raw numbers.    Even better, ensure that there are a wealth of synergies and interactions between those abilities. Designing a 'build' and watching it come together over the course of the game, testing it out each step of the way, can be a motivator in itself.
  11.   No, you shouldn't have a getter/setter for everything, and if you do, it's only a marginal 'improvement' in encapsulation over just making everything public. For 'POD' classes, I wouldn't bother. For most classes though, all member data should be private (protected is no better than public) and accessors should not really be necessary.   All of these guidelines exist to try and help develop 'cleaner' code. Code which is easier to maintain, easier to read (well, sometimes) easier to test, and generally less prone to bugs. This is especially valuable in a team environment where people may have to poke about in each other's code from time to time and won't necessarily want to understand every line of it in order to be able to use it without breaking things.   Ultimately, if you are working alone, then do what works for you. If you can manage 70,000 lines of code in one file, if you can keep track of who is modifying your globals and where, if you're happy using public data all over the place, then go for it. Of course, if you decide later on that you need additional programmers to help with the project, they're going to face a steep learning curve - but until then, all that really matters is that it works.
  12.   Thanks Sandman for your reply.   Are you using Unity and its Terrain feature?      Sorry, I wasn't clear... yes. Unity + Regular Unity Terrains as tiles. The noise generator is my own though.   I don't think you can create the terrains ready made - I think the best you'll be able to do is create them disabled, generate them, and then enable them when ready. The generation process might take a reasonable amount of time, so you have to give yourself enough time to generate them.   My system basically sets up tasks to generate a heightmap, then a series of splat maps, and then detail maps, and (when I get around to implementing it), tree instance lists, plus a few tasks to do things like copy stuff back to the terraindata object. When that's all done, it just sets up neighbours, refreshes prototypes etc. and enables the terrain.   One thing to be aware of, is that I don't believe you can dynamically set up base texture maps. This means that the base texture map for your terrains will always come out as their default black (IIRC this is particularly noticeable in release builds). As far as I know, the only workaround is to effectively disable the base map by setting the basemap distance to something implausibly huge so they are never used.
  13. I have something very similar working, although the architecture is a little complicated, and a bit messier than I'd like. But it works reasonably well - the main cause of lag in the project so far is actually more to do with the dodgy stock water implementation doing a render-to-texture than the speed of the tile generation, although I have a sneaking suspicion that might change once I get tree generation in... :(   In my system, I don't actually destroy the terrains. I create a pool of terrains on startup, initially disabled. Processing work is split up into sequential tasks which are then split again into parallelisable tasks which can be offloaded to another thread - you can only start the next sequential task when all parallel tasks are complete.   Once everything is complete the terrain is enabled and pops into view. When you've finished with a tile, it just gets disabled and added back to the pool for recycling.
  14. You could try asking around here: http://www.cartographersguild.com
  15.   Surely these apply to deterministic games as well? Just because a game has deterministic mechanics doesn't mean it can be played optimally according to a script.   For that matter randomness doesn't necesarilly mean you can't. Dominant strategies are just as likely to occur as in deterministic games, and risk management techniques could be applied to mitigate unexpected results and create optimal strategies.