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

TehOwn

Members
  • Content count

    34
  • Joined

  • Last visited

Community Reputation

134 Neutral

About TehOwn

  • Rank
    Member

Personal Information

  • Location
    Sussex, England
  1. Personally I started with text-based games to help me better understand C++ and games programming in general. Then I learned some DarkBasic to help me quickly iterate some games ideas and processes, but I wouldn't advise using DB, it's awful. Eventually, I moved to SDL but quickly learned one thing... SDL is SLOW!!! The only way to get things rendering fast using SDL is to learn to combine SDL and OpenGL and since I was trying to make everything cross-platform I was loading everything in via SDL and converting it over to an OpenGL-ready format. This was just convoluted as hell, so I dropped SDL all-together. Currently I use OpenGL with GLUT. This allows me to create 2d and 3d games quite easily. These do, however, not provide everything on their own but it's enough to get your project started and the game logic prototype done. Then you can start adding other libraries such as physics, sound and networking libraries as well as libraries to load in different types of media. If you're interested in doing cross-platform non-commercial games then I can't recommend Java enough. A lot of people say, "Well it's not what games developers use" but that just isn't true. While most AAA games are written in C++ that is not to say that Java can't do any game you'd like to create as well as C++ can! Also, Java is, in my experience, a LOT easier to learn. And you can avoid having to send your game with redistributable packages as apparently there are already 3 billion devices with Java installed. Then, of course, there's the fact that Java can run on almost any modern computing device invented and can even be embedded into a web-page.
  2. [quote name='Trienco' timestamp='1329370542' post='4913575']I also don't see any point in doing collision detection for projectils, until you seriously want towers to be able to miss. All these games I've seen so far never miss, so nothing but the distance of the bullet and its target matters (or even just the precalculated "time til impact").[/quote] Yea, mine aren't going to miss but the towers in 'Dungeon Defenders' can. Just a quick reply as I'm at work. I understand the don't fix it if it isn't broke argument, but I really want to establish my limits now so that I can incorporate that into the design. Sure, it'd never be a problem if this was a single-player game but I don't intend it to be. I wanna see what kind of limits I can push in terms of scale, i.e. How many max players a server will be able to handle with it computing all the logic server-side. Obviously, that's a long-term goal but I like to be well-researched in the meantime. I'm going to write multiple algorithms anyway and compare them. I plan to post my code and results on here once I've done a prototype.
  3. [quote name='ankhd' timestamp='1329375737' post='4913588'] now back to the problem at hand. See the cliff at the left top the cell covers the top and the wall of the cliff how should I handle that sort of thing besides making smaller cells. I want the units to go up there if they need to. thanks. [/quote] If you want to deal with variable size pathfinding nodes then perhaps it's worth looking into using Quadtree nodes for pathfinding. This isn't a completed algorithm (and it's not my video either) but this demonstrates the idea well: [media]http://www.youtube.com/watch?v=95aHGzzNCY8[/media] This may or may not be helpful: [url="http://www.stanford.edu/~smenon/professional_files/publications/pathfinding_in_open_terrain.pdf"]http://www.stanford....pen_terrain.pdf[/url] Essentially, from the sounds of it, you're looking for pathfinding on a variable-size grid. If not, then I can think of only two other options. Place custom nodes manually or make the grid finer.
  4. I thought I'd hate C# but as far as being able to create simple games quickly, it can really excel. I'd never switch over to it primarily, but it's a fantastic language to learn game concepts with! Java is also perfect for this, with the added benefit that I actually feel Eclipse is better than Visual Studio. I originally learned with VB and I'm so glad I left it behind. Even back then, when it was still supported, it was simple but terrible at the same time. [u]In summary...[/u][list] [*]Visual Basic (VB) -> RUN AWAY!! [*]C# or Java -> Time to make some gamez! [*]C++ -> Time to hit the books for a few weeks! [/list]
  5. [quote name='Christopher Murray' timestamp='1329334262' post='4913438'] Thank you everyone, got it working now = ) [/quote] You're welcome.
  6. [quote name='Jonazz' timestamp='1329336212' post='4913447']If i remove SDL_Rect mob then the two monsters i have created get stuck together and the velocity is doubled.[/quote] That's because you used globals in the first place. The easiest way to fix this, without rewriting a lot of the code is to simply have a single enemy. Before you understand object orientated programming, you're not going to be able to process enemies the way you want to. This is all possible with procedural programming, but you're stuck half-way between the two, hence the confusion. I'd love to write an example for you but unfortunately I'm already in the middle of a R&D project prototype as well as my full-time job. If I had more time, I'd help more! Have you studied this? [url="http://www.aaroncox.net/tutorials/2dtutorials/sdlclasses.html"]http://www.aaroncox....sdlclasses.html[/url] If you wanted a quick fix to your problem. I'm afraid there isn't one. With the mix-and-match structure of your programming you're always going to run into problems until you go back to basics and actually learn the language. This may sound a bit harsh, but you need to understand the elements of the language before you can use them to solve problems.
  7. [quote name='Jonazz' timestamp='1329331243' post='4913425'] [left]DOT_WIDTH and DOT_HEIGHT has the value 20. TehOwn, sent you a Pm.[/left] [/quote] Looking through your code, it seems you are having some trouble understanding the use of objects in object orientated programming. Also, you have several unnecessary #includes. I'll get round to the collision detection, but mostly the cause is due to your code being very difficult to understand. Where have you been learning SDL and C++ programming? Your problem with the actual mob / player collision is simple. You define the collision box for the "mob" as a global in Globals.h and Globals.cpp, then you redefine it under Enemy like so: [code]class Enemy { private: SDL_Rect mob; int xVel, yVel; public: Enemy(int x, int y); bool Status_left; void show(); void move(); };[/code] A quick fix would be to simply remove "SDL_Rect mob;" from class Enemy and use the global instead. But this doesn't handle the inherent design issues with your style of coding and you'll likely run into problems again. Hopefully, we can give you a good reference to study from and learn some of the object orientated concepts before you end up bashing your head against a brick wall trying to figure this out. You're on the right PATH, you just need some better education before going any further.
  8. The problem lies on two lines... [code] do { unsigned short int options; // <-- THIS ONE[/code] and [code]} while (options == 1); // <-- AND THIS ONE[/code] The problem lies in something called SCOPE. Lets look at this... [code]do { int options; //... other code here... } while (options == 0)[/code] Now options is contained within bracers, these control the SCOPE of the local variable. The variable options ONLY EXISTS within the curly bracers in which it was defined. [code]// options doesn't exist { int options; // options exists } // options doesn't exist anymore.[/code] Since you are trying to check your do/while loop with a variable that goes OUT OF SCOPE before the conditional statement, the compiler should flag an error and it DOES on Visual Studio 2010. The easiest fix is to simply define options BEFORE the do-while loop. [code]//Program that allows a user to maintain a list of his or her favorite games. #include <iostream> #include <string> #include <vector> using namespace std; int main() { vector<string> gameList; vector<string>::iterator myIterator; vector<string>::const_iterator iter; // DEFINED BEFORE THE DO-WHILE. unsigned short int options; do { cout << "Select an option:\n"; cout << "1 - Add a game to your favorites list.\n"; cin >> options; string game; cout << "\nAdd a game to your favorites: "; cin >> game; gameList.insert(gameList.end(), game); cout << "\nYour current list:\n"; for (iter = gameList.begin(); iter != gameList.end(); ++iter) cout << *iter << endl; } while (options == 1); char theEnd; cin >> theEnd; return 0; }[/code] You'll find this code now works. If you still don't understand, please let me know and I'll try to explain it more clearly. Can someone please recommend/write a decent tutorial that explains scope in C++? There used to be a perfect one on about.com but I'll be blasted if I can find it now...
  9. Your main problem is that you've got a block of code floating in your dot.cpp. [code]if (check_collision( box, mob)==true) { box.y =240; box.x =320; hp--; dot_score-=5; }[/code] Is this really just sitting at the bottom of dot.cpp? If not, you've missed out some important code that we need to see. For instance, where it exists in code or the function it is contained within. It should be being checked every frame or two. If you wish, I'd be happy to look at your entire code for the game and comment areas that you might need to look into. Feel free to send me a private message.
  10. Indeed, it did occur to me that using quadtrees for static entities is more optimum than using it for moving entities. As such, perhaps a combined method will be what I end up with. It would be easy for me to subdivide/update the quadtree whenever a tower is placed or destroyed and would be very inexpensive. On the same train of thought, it occured to me that using a Quadtree for high-speed projectile collision wouldn't make much sense (correct me if I'm wrong?) as I'd spend more time updating the tree than I would spend checking for collisions. As for mobile enemies, it is entirely possible for them to check against the tower quadtree and inform all towers within n range that they are targettable. Then once a list of towers was formed, they could proceed to acquire targets. As far as parallel programming is concerned, I'm afraid I'm a newbie in that field but I understand the sentiment. Simple systems can be implemented better and safer. Thanks for your insight.
  11. Why does it always have to come down to math?! *shakes fist*
  12. Lets break down what you're asking for.[list] [*]User must stop when they hit a wall [/list] For this, you need to learn about [b]Collision Detection[/b]. This literally means, "Detecting when an object collides with another" and usually involves some action which occurs when there is a collision (bouncing off, stopping, exploding, etc) There are many simple ways to do this, especially in Tile/Grid-based games. One of the simplest ways of doing this is what I used for collision in my PacMan clone. When you first create games, your player will simply have an [b]X position[/b] and a [b]Y position[/b]. In a tile-based game, you can use this to detect the player's position in relation to the tiles and the grid on which they lie. Imagine that your player lies on a chess board, if the squares on the board are 64 pixels wide and long, then if your player was at (32,32) then he'd be considered to be in the top-left square. If he was at (500,500), he'd be in the bottom-right square. Now, each tile in your game must be considered [b]passable[/b] or [b]not-passable[/b]. Grass would usually be passable, but Walls would not. This allows you to define which tiles players CAN and CANNOT walk on. With this information together, you can work out which grid-space the player is attempting to enter and check if it is passable or not. If it is not passable, prevent the player from entering that space, but position them so they are immediately outside it. That is the theory. Hopefully someone can provide you with useful articles to help you implement it yourself. Secondly:[list] [*]Directional bullet firing [/list] For this, you need to create objects that will move depending on a velocity. This is updated every frame and you can also do collision checks on the bullets to detect if they hit anything (like a wall or player). These concepts are explained quite simply here: [url="http://www.rodedev.com/tutorials/gamephysics/"]http://www.rodedev.c...ls/gamephysics/[/url] Thirdly:[list] [*]Mouse input [/list] Depending on which engine or API you are using; getting and using mouse-input can have a varied level of difficulty. What are you using? p.s. Hopefully my explanations were easy to follow. Giving advice to others is quite a new thing for me.
  13. Wow, thanks guys! This is some really useful stuff. Beer, you've got me thinking and I'll certainly share anything I come up with. Shooter, I'm reading through that article and I'm hoping to find time in the next couple of days (full-time job after all!) to write a quick proof-of-concept. I'll then post that on here and hopefully you guys can let me know if I'm doing it right. I'll throw it together using GLUT, love that library.
  14. I'm sorry but I've seen way too many people acting as if this community owes them their time. This is FREE advice you're getting here, try to respect it a bit better. One reply is better than none. His advice is sound. There is nothing wrong with it. Perhaps if you provided a little more information about your A* implementation then people would be able to tailor their answers better to your... ability... to comprehend. I sounds to me like you're using an A* algorithm that was coded by someone else and you don't really understand how it works. There is a great section on pathfinding here: [url="http://theory.stanford.edu/~amitp/GameProgramming/"]http://theory.stanfo...ameProgramming/[/url] Specifically to costs: [url="http://theory.stanford.edu/~amitp/GameProgramming/MovementCosts.html"]http://theory.stanford.edu/~amitp/GameProgramming/MovementCosts.html[/url] This is all I needed to write any pathfinders I've ever wanted.