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

MobileOak

Members
  • Content count

    31
  • Joined

  • Last visited

Community Reputation

158 Neutral

About MobileOak

  • Rank
    Member
  1. Quote:Original post by Twist wish Now I'm using a Vertex Buffer Object to have all the vertex data,normals and colors and then I read it to draw it like triangle strips. Ok. I actually haven't used VBO's, and didn't know about glBindBuffer before, so I don't really know whether its faster or not - probably would have to post in the OpenGL forum. I'll have to pick up the new blue book on the spec sometime soon.
  2. 1. There are many terrain formats. It really depends on what you want to do and what area you want to show. Is it a physical location, or randomly generated? 2. Since you're using OpenGL, I highly recommend using triangle strips in Display Lists. That will give you the best performance. 3. That really depends on how you want your camera to work. Do you want it to follow the terrain a certain height above it, or have one that's free form (able to fly above the terrain at an arbitrary height). There are two terrain file formats I'm familiar with: 1. DTED (Digital Terrain Elevation Data) files of low quality are freely availible from NIMA, and the format specification is availible here. 2. STRS/DEM is another format similar to DTED, and you can probably get free low-quality files for that as well. I don't know a whole lot about the 3DS format, but unless it has a special terrain format, it probably doesn't support actual physical locations. That might not be a problem depending on what you want to do with it, however. You should also check out the Virtual Terrain Project.
  3. When you pass in a pointer to a function, that allows you to modify the data that it is pointing to, but not the actual pointer itself. It's like doing this: void foo() { int myInt = 3; bar(myInt); cout << myInt; } void bar(int myInt) { myInt = 5; } and expecting the output to be 5. Unless you're passing by reference, or passing a pointer to the data you want to modify, you're only manipulating a copy of the data. Try: unsigned int C_TextManager::buildFont(const char * fontName, int fontHeight, float **charWidth) { ... (*charWidth) = fontVector.back().getWidths(); } I *think* that's right, but I haven't compiled it.
  4. Can you explain what you're doing with the code you posted a little better? Why all the calls to min and max? If you have some ship with an X and Y coordinate, and some speed coordinates, and every iteration you want to add those speeds to the coordinates, you could just do some bounds checking: shipX += speedX; shipY += speedY; if(shipX < 0) //out of bounds on the left { shipX += 500; } else if(shipX >= 500) //out of bounds on the right { shipX -= 500; } if(shipY < 0) { shipY += 400; } else if(shipY >= 400) { shipY -= 400; } Of course if you want to make it easier to change the size of your screen later, you'll use a constant for your screen size: const int SCREEN_WIDTH = 500; const int SCREEN_HEIGHT = 400; shipX += speedX; shipY += speedY; if(shipX < 0) //out of bounds on the left { shipX += SCREEN_WIDTH; } else if(shipX >= SCREEN_WIDTH) //out of bounds on the right { shipX -= SCREEN_WIDTH; } if(shipY < 0) { shipY += SCREEN_HEIGHT; } else if(shipY > SCREEN_HEIGHT) { shipY -= SCREEN_HEIGHT; } Hope that helps.
  5. Hey, One way I was thinking about with it was if you stored all the positions in an array, in the order you'd like the AI to play them. Something like this: int AI_Locations[9] = { 5, 9, 3, 7, 1, 6, 8, 4, 2}; And the way you'd traverse this is you'd have some index into the array: int AI_Index = 0; Whenever it is the AI's turn, you could check the locations array at the current index, and move there if it's open, otherwise advance the index and check the next spot. so you'd have something like this in your AI_Turn() function: int AI_Turn() //returns where to put the AI's next piece { while(AI_Index != 9) { int location = AI_Locations[AI_Index]; if(board[location] != human) { return location; } AI_Index++; } //error, should not get to here } Of course this always makes the AI do the same moves (and doesn't play very smart). You can try to rearrange the order of the numbers if you want, but really you need a more complicated strategy to 'react' to the opponent. If you think about this long enough, you should be able to figure out a way to get more moves by making the array larger and jumping around inside it (not just going to the next element necessarily).
  6. I think you've kinda got the idea. It could probably be implemented easier/better though. Just to clarify what you're doing/going for here: Picture your basic tree structure: // + <-- turn 1 // / \ // + + <-- turn 2 // /| |\ // + + + + <-- turn 3 Now, assuming that the AI goes first, you could set it to always go at location 5. This would be your turn 1 move. The human then goes, and he can go in 8 different places, so at turn 2, you would have 8 child nodes. For each of those child nodes you would have the best response for your AI, so 8 more child nodes. Each node in the turn 3 layer would have 6 children where the human could go in turn 4. So your tree might look something like this: // 5 <-- AI starts at 5 (turn 1) // // / / /| \ \ \\ // 1 2 3 4 6 7 8 9 <-- human can go to any of these spots (turn 2) // | | | | | | | | // 3 9 9 9 1 1 1 3 <-- where you want the AI to go in response (turn 3) Unfortunately there are some problems with this - it starts to get incredibly large very quickly, and if you program it all with if/else statements, your code starts to become HUGE. So what can you do? There are several options: 1. Store the decisions in an array or other structure. This will simply your large if/else statements down a bit. 2. Store the decisions in a text file that you can read in when the game starts (learn some File I/O) - this will make you have to type less code 3. Try a different approach. I'd give you a rundown of how to store things in an array to make it easier, but I'm out of time now and have to run - I'll check back later. MobileOak
  7. Quote:Original post by kingpinzs Does any one else have any ideas on how to setup AI for this type of game? That really depends on how 'smart' you want the AI to be. 1. One approach is the one described above by Zodiak, where you look at the board and try to make the "best" move for the situation. The challenge here is to program something that can't be beaten. 2. Another approach, which I think was described in a different one of your threads is one that randomly chooses a place to play. This is probably the 'dumb' AI version. It should be the easiest to implement. 3. The third approach would be one that combines the two - it doesn't always do the best move, doesn't always do the worst. That would probably be the most fun to play against. If you code the first two approaches, this third approach, you would randomly choose whether to use approach 1 or 2 for any given move.
  8. > If(board[ row + column ] != 'O' || 'X') This is the wrong way to write it. You need to write it like this: if(board[ row + column] != 'O' && board[ row + column] != 'X') The way you had it above makes sense to a human, but to the computer, it gets confused and tries to OR the O and X together, and then see if the board[row+column] is not equal to that. Hopefully that fixes your original problem. (If not reply with more code).
  9. Another thing to keep in mind is that you're allocating array dimensions of size 5. That means there are 5 positions, 0, 1, 2, 3, and 4. You seem to be forgetting the zero position.
  10. Quote:Original post by snk_kid Quote:Original post by MobileOak Even after ignoring the difficulties in understanding your post due to run-on sentances, mispelled words, and overuse of bold/italicized words, I'm having a difficult time understanding your reply. Due to your use of the phrase "sin of satan", horrendous misspellings and general grammar errors, I would normally have ignored your post. If that is how your going to respond then you can find out the hard way and keep hearing the same thing over & over (trust me this will more than likely not be the last time you hear it by others) until you do get it, if you really think i'm so un-helpful then perhaps you should look at some of my last replies at some-one elses thread Honestly it seems like some of you have seen nothing but bad designs, once you start reading & learning about design patterns, refactoring you will begin to see or see it better. I've made my point, if you don't get it, oh well. Hey man, calm down. I'm not trying to rile you up over this. Like I've stated before: 1. This is the beginner's forum - don't assume I know all these design principles and issues. 2. In your first reply to my question, you stated a bunch of stuff I don't fully understand, and it was hard to figure out what you were saying even when I looked up some of the terms. 3. I'm just trying to get a well-reasoned explanation for your line of thinking. Luctus has done a pretty good job of explaining why, and I appreciate his help in explaining this. But now someone's gone and down-rated me over trying to figure this out. I was not trying to be a jerk about this, I'm just trying to understand your reasoning. I'm not using derogatory terms for anyone, anyone's code, or their coding practices, but somehow I'm the bad guy here. So once again, I'm sorry if I came across wrong on this, I'm just trying to figure things out.
  11. Quote:Original post by Luctus Stuff... Under this scheme, is there any situation where you would place something in the protected section, or is it all public/private?
  12. Quote:Original post by Raymond_Porter420 I think your missing my point. Some stuff does need to be wrapped. Some vars need to be accessed through a function call because you might wana change them later. But some stuff is just data, just memory that you are using to hold some stuff. Since when was accesing a var such a bad thing. being object oriented has its advantages but it is possible to take it overboard. Telling someone private data is "the sin of satan" is what i consider overboard, exspecialy if the guy is still trying to learn what the "private" keyword does. Until he can adequately explain the benefits of his position, I agree with you.
  13. Quote:Original post by Miserable Quote:Original post by MobileOak [Lots o' stuff] Does that make sense? It makes sense, and that's one justification for it, but don't go overboard. Sometimes, all you need is a POD struct. That's true. I was merely trying to explain to him a reason for data encapsulation, since it's not intuitively obvious that its beneficial.
  14. Quote:Original post by Raymond_Porter420 an example of the most retarded code ive ever seen class Point { GetX() { return x; } GetY() { return y; } SetX(int X) { x = X; } SetY(int Y) { y = Y; } private: int x; int y; }; I understand that this looks like 'retarded code' to you. You're wondering why you should have to write all those accessor functions. The reason behind it is to protect the data from outside classes modifying it. If x and y were public, then any other code could modify a Point's x and y values without the Point knowing about it. Having the code written this way allows you to control that access. Suppose that you have a game that always displays a Unit's location (represented by a Point class) in the GUI. If something other than the GUI modifies the location of the Unit, the GUI would like to know that. So let's say you add a function to SetX: SetX(int X) { x = X; notifyGUI(); }; Now you are guaranteed that any time that Point's X is changed, the GUI is notified. Coding like this will prevent you from having to remember to notify the GUI every time you publicly access Point's X. Does that make sense?
  15. Quote:Original post by snk_kid Quote:Original post by MobileOak Quote:Original post by snk_kid Making data members with protected access is most often "the sin of satan" and very contradictive, generally a sign of bad design unless there is real rationale for there use and there truely is such a tight coupling between parent & child types, in most case there isn't so don't fall into bad habbits. Care to explain in more detail? I don't understand why derived classes shouldn't have access to their base class's member variables. Because it's an implementation detail that doesn't need to be known, it should be pretty obvious why its called an abstraction, i even high-lighted the main terms coupling and also to enforce state invariants, polymorphic types and type inheritance in general is mainly about extending behaviours/operations not extending implementation, i'm not saying never, i'm say in most cases its abused without any rationale it may aswell be public. I'm not gonna go into any more details, just google it and you will get millions of hits about it. In theory public virtual member functions considered are bad aswell but that is beyond the scope of this if you want to know more then google up on non-virtual interface idiom. Even after ignoring the difficulties in understanding your post due to run-on sentances, mispelled words, and overuse of bold/italicized words, I'm having a difficult time understanding your reply. Due to your use of the phrase "sin of satan", horrendous misspellings and general grammar errors, I would normally have ignored your post. But since your rating is high, and you seem to know the terms involved, I thought you might have some insight into the situation that I could learn from, but all I've been able to comprehend from this most recent reply is "it's an implementation vs interface issue", and that I should "just google it". This is hardly helpful, as googling phrases in your post leads me off on wild-goose chases. Googling for facts is great. Googling for the reasoning behind an argument is futile. Once again, I don't understand what you're talking about. Can you show me an example of why accessing inherited protected member variables is bad? I have used it many times, and if there is a better programming practice I would like to learn the reasoning behind it and how to use it. This is the Beginner's forum. Most of the people reading it aren't going to understand your post, so please try to explain yourself better. [Edited by - MobileOak on March 8, 2005 4:13:06 PM]