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

adt7

Members
  • Content count

    470
  • Joined

  • Last visited

Community Reputation

751 Good

About adt7

  • Rank
    Member

Personal Information

  • Location
    United Kingdom
  1. Yeah, that's true. Even most of the small libraries I use are using CMake, and you're right, for something like Lua it's trivial to write one.   I didn't realise option could be used that way, that's so much easier than what I've been doing. I've been using set like this, which is a real pain as the description has to match exactly. [source]set(SDL_SHARED false CACHE BOOL "Build a shared version of the library" FORCE)[/source] I think I'll go for using git submodules for anything open source and then for the few non-open dependencies I have I'll just bundle the binaries in the repo. Thanks for the help.
  2.   That maybe true, but as I'm only aiming to support a very limited set of platforms to begin with (not myriad Linux distros) I'm less concerned about this. My aim is to have the process of on-boarding new people as easy as possible, but also to have everyone working from a "known good" state, to rule our library version issues, etc.     I like the sound of the ultimate solution, and using these types of systems is what I've done in the past... if only one existed for C++.   As for the submodule approach, how do you handle dependencies that don't have their own CMakeLists.txt (to pick a well-known example, Lua), do you find a fork with a CMakeLists.txt (e.g. LuaDist/lua) or is there a way I can get CMake to figure out how to use their makefile (even as I'm typing this it sounds insane)?   EDIT: Further to that, how do you handle all of the set calls that need to be made to turn off features in your dependencies builds (e.g. building tests), doing it in the CMakeLists.txt is fine, but messy, is that just something you have to live with doing it this way?     From what I've seen of your posts around here you've got a pretty impressive job history and been involved in some big projects, so if that's how you've worked in the past it's making me think that whilst it may not be the ideal world approach, it's probably the best one.
  3. I've been working on a C++ project using CMake as my build-system generator and I'm about to get a second developer on board.   I work on OSX with dependencies installed using Homebrew.   They are going to work on Windows (they are going to work on some of the cross-platform issues, so this choice is deliberate).   What I'm struggling with, is how to manage the dependencies in the project so that it's as easy as possible to onboard this new developer and any future ones (agnostic of platform).   The approaches I've considered are as follows: Make developers install all dependencies using brew/apt/downloading them and letting my FindX.cmake scripts sort it out (with special environment variables for Windows). Include pre-compiled dependencies in a folder within the project and link to those (for all supported platforms). Use git submodules to include the source of the dependencies in the project and use add_subfolder in CMake to compile them.   I think the second approach is the "right" one, as it's the least friction for new developers and means that the dependencies don't have to be compiled the first time.   The only concern I have about this is that at some point (before I'm ready to distribute the project) I want to switch to static linking (is this even a good idea?). This is fine for simple dependencies with no dependencies themselves.   However, what about the more complex ones like SDL? Do I then need to include static versions of all it's dependencies (OpenGL etc.), that doesn't seem great. I noticed SFML does this (in the /extlibs folder), but it doesn't include everything is depends on, only a few (for example OpenGL is not included), how do I know which ones I need to include and which I don't?
  4. tilecount is populated which would suggest that your tiles are getting parsed properly. What do you see if you expand the tiles node in the debugger?
  5. This is one of the best explanations of continuous collision detection using bounding boxes that I've seen: https://www.youtube.com/watch?v=V_Np1aqgrwI   You don't need to use 2 bounding boxes, nor do need to do the splitting into top/bottom and left/right boxes if you don't want, this technique works equally well with a single bounding box and I've used it to great effect in games that I've written.   Doing the same with a single bounding box is explained in this video, although it's explained mostly through code rather than diagrams: https://www.youtube.com/watch?v=pTtG55YTgSU   In case the video isn't clear enough, the basic steps (regardless of how many bounding boxes you use) are as follows: Calculate your desired move distance. Choose an axis to resolve first (I tend to go with x) Take your desired move distance in the chosen direction and extend the bounds of your bounding box by that much in that direction. Get all of the tiles within your new bounding box. Check for collision in the direction of travel against only the tiles within your new bounding box. If there is no collision, move your full desired move distance. If there is a collision, do whatever your collision behavior is (most likely, move as far as you can then stop) Repeat for the other axis.
  6. My current project is a 2D platformer where the whole game is made up of a series of "rooms" (like a level of Shovel Knight, but without a world map to split it up).   My rooms are currently defined like this (pseudo code): room = {     tilemap = "tilemap.tmx",     init = {          // Perform the initialisation of anything not in the tilemap, e.g. enemies and collectable items     }, // Other irrelevant stuff } Each time you enter a room, the init code is run and all of the enemies/collectables you killed/picked up/whatever are all back in their original place. This is exactly how I want this to work.   At the moment saving the game is simple, I just serialize out the state of the player, which room they are on and that's it.   The problem I'm having is that I'm now at the point where I want to add one-off collectables (like the morph ball in the Metroid games) or one-off enemies (e.g. an extra hard one that spawns only once), once you've collected/defeated them, they are gone - and when you enter/re-enter a room they shouldn't be re-spawned along with everything else.   I'm struggling to come up with a concept to handle this without some kind of global manager to look after everything which feels a bit wrong to me.   I'm working with an ECS architecture (as a purely educational exercise, I don't want to go into the merits of ECS vs. non-ECS), and I know that I shouldn't try and force everything into it, but it feels like this is a problem that I should be able to solve with it.   As a rough stab at it I was thinking of the following: a Persistence component which stores a key a PersistenceSystem which keeps track of these keys and their state when a Persistence component is added to an entity, if the PersistenceSystem says the entity shouldn't exist anymore, destroy it (this is to handle the case when I reload a room) when I save the game I serialize the keys and their states from the PersistenceSystem along with my other data Is this is a sensible approach? Is this something that should sit outside of the ECS? How have other people tackled this problem?
  7. This is how I do this in my project. On Windows I populate CMAKE_PREFIX_PATH with the paths to the various library directories, and on OS X/Linux it "just works". if(WIN32)   # Tell CMake where to search for includes, libs and DLLs on Windows   set(CMAKE_PREFIX_PATH ${CMAKE_PREFIX_PATH}     "${PROJECT_SOURCE_DIR}/extern/glew"     "${PROJECT_SOURCE_DIR}/extern/SDL2"   ) endif(WIN32) find_package(OpenGL REQUIRED) if(NOT OPENGL_FOUND) message(FATAL_ERROR "OpenGL not found!") endif(NOT OPENGL_FOUND) include_directories(${OPENGL_INCLUDE_DIR}) target_link_libraries(${PROJECT_NAME} ${OPENGL_LIBRARIES}) find_package(GLEW REQUIRED) if(NOT GLEW_FOUND) message(FATAL_ERROR "GLEW not found!") endif(NOT GLEW_FOUND) include_directories(${GLEW_INCLUDE_DIR}) target_link_libraries(${PROJECT_NAME} ${GLEW_LIBRARY}) find_package(SDL2 REQUIRED) if(NOT SDL2_FOUND) message(FATAL_ERROR "SDL2 not found!") endif(NOT SDL2_FOUND) include_directories(${SDL2_INCLUDE_DIR}) target_link_libraries(${PROJECT_NAME} ${SDL2_LIBRARY})  
  8. Have you tried making use of SDL_GetPerformanceCounter (alongside SDL_GetPerformanceFrequency) rather than SDL_GetTicks? It should give you a more accurate timing value.
  9.   Wait, is that actually representative of your actual code? Those calls to sleep (especially in the physics thread) will not be doing you any good. The accumulation loop you posted is design to run as quickly as possible (i.e. in a while(true) style loop) and fire the Physics events at the correct time. With the setup you have now the simulation will not be being called at the correct frequency due to differences in sleep time and the fact that your time deltas are going to be huge.
  10. The clock() function gives you the ticks elapsed since the program was launch. PhysX expects its delta times in seconds. Try dividing your clock values by CLOCKS_PER_SEC and working in seconds rather than ticks.
  11. A lot of methods/constants have been changed/removed for SDL2. For example, SDL_GL_SwapBuffers() is now SDL_GL_SwapWindow(). You need to update your code to use the new SDL2 methods.
  12. Without seeing any code it's hard to give any advice on how to fit it into your existing setup. Coudl you post snippets of the relavent parts of your Sprite, SpriteManager, UserController and ProjectileSprite classes? Or at least the parts that seem to be causing you difficulty?
  13. For my latest (small) project I thought I'd try out a slightly different way of doing things, namely I've decided to try using MVC for a game.   I've got a reasonable handle on it in terms of observers and events in the model and communicating these to the view (and controller), however I'm having a bit of difficultly in figuring out how to completely eliminate data about the graphical representation from the model.   Take this (massively simple) example of a fairly basic RPG. Since my model is data-driven, I have a single "Unit" class which contains information about the units (no need for Troll, Goblin, etc subclasses).   class Unit { string name; //Friendly name, e.g. Dave int hp; int damage; int range; Unit(string name, int hp, int damage); } Then in my model I keep a list of these Units as well as a method to retrieve them so the view can access them.   class Model // LevelState or similar would be a better name for this { Unit[] units; Unit[] GetUnits(); }   The problem occurs when I come to drawing the units, as far as my model is concerned it doesn't care about if the unit is a goblin, an archer or a giant salamader, all it cares about is the unit's stats which define it's behavior.   However, the view very much cares about if the unit is a goblin, an archer or a giant salamader as it will have to draw different sprites for each of them.   What is the best way to solve this? I could add an enumerated "type" field to the Unit class, but this feels wrong as it's polluting the model with data that it doesn't care about, but I really can't see any other way of doing this.   Am I just overthinking and getting too concerned with what is "right" and "clean"?
  14. It exits unexpectedly because the following lines of code need to be moved to onCreate, after the call to SetContentView.         TextView textField = (TextView) findViewById(R.id.textField); TextView result = (TextView) findViewById(R.id.resultView); EditText gameObjective = (EditText) findViewById(R.string.gameObjective); Button button = (Button) findViewById(R.string.submitButton);