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

Joakim Thor

  • Content count

  • Joined

  • Last visited

Community Reputation

212 Neutral

About Joakim Thor

  • Rank
  1. Perhaps something like BoxedApp is what you're looking after? It packs files into the executable and unpacks them in a virtualized environment for your game.exe to use. I'm not security expert at all (really, I haven't got the slightest idea what I am talking about!), but as far as I am concerned it gives you basic protection against DLL-injections and hides your resources from public view. Also you get a single binary for shipping. No installation required, just click the exe and run the game. Registry-values is saved in a virtual registry.
  2. What others have mentioned, you usually don't use SDL_Delay() too regulate framerate. While this is a quick and easy approach to fix a game running to fast, the results will vary on slower and faster computers than your own.   Usually velocity is measured in pps, pixels per second. You want something to move 10 pixels per second, you set velocity = 10. deltaTime how long time it took to run a frame. If your game takes 1 second too run 1 frame, you get:   velocity * deltaTime = 10pps * 1000ms = 10ppf (10 pixels per frame)   0.5s to run 1frame would be:   velocity * deltaTime = 10pps * 500ms = 5ppf   So if your game runs faster, your character moves shorter per frame. If your game runs slower, your character moves faster. If the game run double the speed, the character only moves 5ppf. If the game runs 1s/frame he moves 10ppf. This should make sence. This makes gameplay run equally fast on different computers, but with altering framerates. This is what many others said before, but no one mentioned pixels per second or frames per second which, IMHO, makes this subject more easy to think about.   Tip: When using SDL everything is measured in ms, NOT seconds, hence why I used ms in my explanation. When calculating deltaTime you would do something like:   Uint32 getDeltaTime() {    Uint32 deltaTime = SDL_GetTicks() - previousFrameTime;    previousFrameTime = SDL_GetTicks();    return deltaTime; }   This would return 1000 if the time between each frame is 1sec. Doing position += velocity * getDeltaTime() will scale your velocity by 1000 if you defined your velocity as pps. You must either define your velocity as ppms (pixels per milliseconds) or divide deltaTime by 1000:   Uint32 getDeltaTime() {    Uint32 deltaTime = SDL_GetTicks() - previousFrameTime;    previousFrameTime = SDL_GetTicks();    return deltaTime / 1000;              //Seconds instead of milliseconds }   Division is an expensive operation you might say, but considering the circumstances its a piss in the ocean (as we say in sweden, instead of "it doesn't matter"). Dividing by 1000 once every frame isn't gonna cause your game to meltdown. New game programmers tend to prematurely optimize everything, including myself, and it's easy to think dividing by 1000 every single frame is bad code. It isn't.
  3. Components are objects stored within a class as members, components are not inherited and thus it's not a component based system.   Assuming Foo is inheriting SolidObject and GameplayObject you could do something like:   vector<Foo> solidsAndGameplayObjects; //A container of the class inheriting from SolidObject and GameplayObject ... for(auto foos1 = solidsAndGameplayObjects.begin(); foos1 != solidsAndGameplayObjects.end(); ++foos1) //Iterate through all foos { for(auto foos2 = foos1+1; foos2 != solidsAndGameplayObjects.end(); ++foos2) //Nestled for-loop to compare all Foo's with eachother exactly one time { if( collision( foos1, foos2) == true) //Check for collision { foos1.hitpoint -= foos2.collisionDamage; //collisionDamage lives in Foo foos2.hitpoint -= foos1.collisionDamage; } } }   While I wouldn't recommend this approach since you will find yourself programming HORRIBLY TERRIFYING CODE which is not maintainable whence you create more classes inheriting from SolidObject, as you would need another vector for each subclass of SolidComponent...   This is a simple and direct approach to solve your issue though, but I wouldn't recommend it as it will be difficult to maintain.
  4. How about foo[20*20*20*40] ;)?   Also, easy to understand picture:  
  5. As previous posts suggested an entity is pretty much everything. It's for sure to complicated to explain in one post, articles are more suited for the job. I'm not gonna try explain to you what an entity is, but I want to give you an advice - everyone has different opinions about what an entity is, why you need one, how it is implemented etc etc. Everything you read about the matter should be read with a pinch of salt (and in some cases a handful of salt!). You can't read an article and assume what that article explained to you is true in another article, that I learned the hard way.   The most common approaches of Entity Systems have unofficial labels that you will come across whence you lurk more... People talking about, for example, T-Machine ES (Entity System) are generally talking about the same approach of entity system. You might want to memorize the unofficial labels names each type of ES has been given and what's special about that entity system, it will help you from mixing up the different concepts of different entity systems.   Here's some helpful articles that helped me understand ES:   http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/ (T-machine entity system) http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/ (Objects (entities) as pure aggregation)   While it might be mind-boggling to read get into ES-concept, it is well worth it. I personally feel Entity Systems give the programmer much more freedom and it becomes easier to structure your game. Decoupling is very easy to manage.   I can answer your questions very briefly how I did it:   1. An entitiy is an integer, GUID (Globally Unique IDentifier), that is used to index arrays for it's components (data-collections). In my implementation it is NOT a class. 2. The entity GUID index arrays to access it's components. 3. Systems has access to relevant components. My moveSystem have an update function which can iterate through all positionComponents and velocityComponents and do the logic upon these, altering the component values.
  6. In  Dwarf Fortress you can basically keep on going forever without reaching the ending due to the nature of procedural content. In practice the only viable way of creating broader RPGs is with procedural content, or spending shitloads a lot of money on content-developers.. As for procedural content, existing games have definitely not done the most out of the concept. Terrain heightmaps and vegetation is to some extent generated procedurally during development to ease the burden for world designers, I think Skyrim did this. Other than terrain generation not much has been done on procedural content generation in game development, which is somewhat sad since I am convinced it can be done without making the worlds and its events and content to artificial.
  7. In many  cases you can figure out complexity of a game by yourself. Look at what features a game, and what prerequisites these features have. IE: Pong, two paddles and a ball. All of these move, basic physics is needed. Collision-detection is also needed. There's no way to rate the complexity in any sequence, it'd be arbitrary.
  8. I looked through your code briefly but didn't find anything. You might want to google SIGSEGV and see how too solve and prevent these kinds of issues. SIGSEGVs is basically access violation.   I also recommend you to use some kind of debugger, (GDB for example). Finally taking a look at your call stack can also provide you with some hints.
  9. It's definitely interesting. I've never had iOS or Android so I can't tell whether this has been done before or not, but it sure is interesting. 
  10. As for both Space-partitioning and Quadtrees, they seem very much indeed to be the answer to my question! I'll definitely look into it further. If anyone have any other suggestion how to solve the issue I'd be glad to hear more. And about the inapt try to put a smile on your faces humour, it was purely for the sake of merriment and I didn't mean to offend anyone :).
  11. Hi there Little Coding Fox.   If you make your pathfinding Unit 1x1 in width and height, does your pathfinding issue persist? Or does he seem to navigate correct, not getting stuck in stuff?
  12. Why hello there! How nice of you to come by. Have a seat.   My game is 2D-topdown and made in C++. Zeldaish. Love that game. ANYHO, I am trying to figure out how to make a vector contain only relevant Units. You might wanna skip this part and answer my question at once. No f*** you, read my wall of text. I'll try to explain with collisiondetection as example (have in mind this issue is not collision-specific, that's not what I am getting at..). I want to check if any Unit has collided with another Unit. I currently achieve this by doing this:   1. Create a vector which contain all Units. 2. Iterate through it so that all Units have checked collision with each other only once.   Now what if I have 30 Units in my world? If all 30 are to compare with each other only once, we got a total of 435 collisionchecks per frame, y = (x2 - x) / 2. This is inefficient. If there is 40 we get 780 collision checks.. It scales terribly. For some calculations the terrible scale isn't to much of an issue since the operation isn't complicated, but overall this will slow down my game if I don't come up with another way of comparing objects.   Instead I figured I'd like to create a member vector of relevant entities within the Unit - not a vector containing all Entities. This would greatly reduce the need of collisionchecks. Relevant entities would be entities that are close to the unit. I can take advantage of indexing, storing pointers to all Units in a 2-dimensional array that would represent and be identical to my 2-dimensional worldmap-array. Then it would be easy to grab some pointers to relevant, physically close, Units via indexing by coordinates and push them into a member vector of the Unit. Now this vector only contains other Units that is physically close to my unit and the result is that each unit only need to check collision with at most 4-5 Units, instead of all present Units.   In theory this would work out, assuming that creating the index isn't more inefficient than iterating through the vector of all Units (or items, or enemies or whatever object I have to access), but creating the index and maintaining it with moving objects etc is always slower when I try to implement it.   This issue persists with all kind of stuff within my game - not only collisiondetection. I actually got to write this thread since I'm currently at making Items storable within an inventory. When the Unit, my character, should pick up an item that is in front of him I only iterate through a vector of all items and check which one are within range. It'd be unealistic if my character could pick up an item from 100 meters. Well Slenderman has long arms, but this guy is more of a Gnome Urist McTransracialGnome. Same issue here - I want a vector that consists of relevant objects, not all of them. When combating enemies I iterate through a vector containing all enemies to check if the spoon sword hit any, instead of iterating through a vector containing all enemies that are likely to get hit. It's oblivious! Perhaps I shouldn't even iterate through a vector?     If you still haven't grasped my issue I'll make a final try: In Mount&Blade there is lots of players. When I shoot an arrow I can't imagine it iterates through all players every single frame and check if the arrow has collided with any of them? Surely there must be a more efficient way?! What way would that be? What alternatives to that way is there? Any design-pattern I should look into? (I did read GoF: Design Patterns but I grasped approx 10% of it the English language is inferior and nothing could be explained properly. Perhaps anyone have a Swedish translation of it?)   Seriously now, thanks for reading and I'd be REALLY happy if someone could point me in a good direction !
  13.   for (vector<zombiesClass*>::iterator i = zombies.begin() ; i != zombies.end() ;) { if( (*i)->Dead ) { delete zombies(i); zombies.erase(i); } else ++i; }     Perhaps something like this? (argh, cant get rid of italic text..)   Im not to sure this works thou. It deallocated the object and removes it from the vector without invalidizing the vector. Atleast that's what I intent to do with this code.