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

AlexWalters22

Members
  • Content count

    6
  • Joined

  • Last visited

Community Reputation

762 Good

About AlexWalters22

  • Rank
    Newbie
  1. I just want to ask, are you a Wheel Of Time fan?
  2. Lazy Foo man. http://lazyfoo.net/tutorials/SDL/index.php       It goes through many of the things you will need to know about the basic game loop. Input handling, image loading and rendering, sound, basic collision detection, and some things that are more difficult to understand like frame-independent movement. It also goes over things that are included in common games like a game camera and background tiling. It gives you a full(ish) understanding of basic 2D games. It's also a native C library (which means native C++ too). So yeah, that's good.       Books probably won't help you too much until you understand the basic game loop.They tend to be somewhat unfocused in some places because when your an expert, you can forget what was difficult for a beginner. Also, I wouldn't worry about coming up with amazing solutions to problems(or any solution without research), or copying others code(as tonemgub said) as long as you try(really try) to understand it. Eventually you will get to a point where you do understand, and then you will really want to change copied code or rewrite poorly understood code (because you can do it better).I struggled with the frustration at not being able to come up with a solution on my own for a while before I realized I would just get there eventually with some perseverance and a touch of diligence.   I hope Lazy Foo helps you and if you have some specific questions I would love to answer them, send me an email or a PM on here, and I will get back to you! Much luck to you on your journey.
  3. Thanks for the feed back guys(Ravyne and EDI). FIrst of all, I will fix the 256x224 resolution to say SNES (woops). I understand that it is probably a bad idea in most situations to scale to fit the screen no matter what and it definitely produces scaling artifacts and distortion. I'll add a disclaimer at the top of this article identifying those drawbacks. For the most part, the reason that I created the article is that it was suprisingly tricky to figure out the rights steps to take to actually get rid of letter-boxing if one wanted to. It is a fairly simple (albeit crude) way of supporting any size thrown at it without letter-boxing it. It is definitely a temporary fix and not a long-term solution. I thought I would show how I did it after reading this:   http://comments.gmane.org/gmane.comp.lib.sdl/61628
  4. If you're making a game that you want to be used on a wide variety of systems, your game has to be scalable, especially if it is in a very small resolution. This is usually pretty straightforward. Most graphics libraries and the like have things built in for doing the scaling for you. SDL2 does, but only to a certain extent. If you want your game to be scaled without letter-boxing, you have to write this yourself. It took me a while to figure out, so I though I would spread the knowledge. Using this form of scaling can create some serious distortion as well as introduce scaling artifacts to the game with different aspect ratios. The code included is written in C++ and uses SDL2, which can be found here: http://libsdl.org/. The documentation which describes the functions that I use is located here: http://wiki.libsdl.org/CategoryRender. And to set up SDL2, some easy instructions can be found at the awesome site LazyFoo Scaling On Up The theory here is this: You don't want letterboxing. You want the game to be taken from its original size and stretched to fit the window no matter what. So you just render everything to a back buffer by setting the target to it, instead of to the window's buffer, then at the end of your rendering cycle, switch the target back to the screen and RenderCopy the back buffer onto the screen, rescaling if neccessary, then set the target back to your back buffer and repeat. It's slightly trickier than it sounds. Enter The Code So in order to accomplish scaling without letter-boxing, we will need some SDL rectangles variables. SDL_Rect nativeSize; SDL_Rect newWindowSize; One is for storing the original size of the game, nativeSize, and one is for storing the size of the window when it changes size, newWindowSize. float scaleRatioW; float scaleRatioH; SDL_Window * window; SDL_Renderer * renderer; SDL_Texture * backBuffer; SDL_Texture * ballImage; bool resize; We also will need an SDL_Window, an SDL_Renderer for that window, and last but not least a backBuffer for rendering everything to before copying it, properly scaled, to the window's buffer. Also there is ballImage which will be used to demonstrate the actual scaling. The two floats, scaleRatioW and scaleRatioH are optional. They are used if you need to scale the values of certain things that rely on the coordinates of the mouse, e.g. a button. You would multiply the x coord and width of its bounding-box by scaleRatioW and the y coord and height by scaleRatioH. resize is used to tell the render function to call the resize function. It is neccessary to do it this way because there is a stall in the program after resizing the window that can sometimes cause problems if you call the resize functions immediately upon receiving a resize event. So I have set up a fairly simple main function to run the program. int main(int argc, char * argv[]) { InitValues(); InitSDL(); bool quit = false; while(!quit) { quit = HandleEvents(); Render(); } return 0; } InitValues does what you might expect it to do, gives all the variables their starting values. InitSDL does most of the importnat work, setting up the window and renderer as well as set up the back buffer and load the ball image. HandleEvents returns false if the user clicks the x button on the window, however it also captures the window resize event and resizes the screen using a function called Resize. Render handles a very important part of the process, changing from the back buffer to the window buffer. I'll explain each of the functions in turn. void InitValues() { nativeSize.x = 0; nativeSize.y = 0; nativeSize.w = 256; nativeSize.h = 224; newWindowSize.x = 0; newWindowSize.y = 0; newWindowSize.w = nativeSize.w; newWindowSize.h = nativeSize.h; scaleRatioW = 1.0f; scaleRatioH = 1.0f; window = NULL; renderer = NULL; backBuffer = NULL; ballImage = NULL; resize = false; } I set the native size to that of the SNES, 256 by 224. void InitSDL() { if(SDL_Init(SDL_INIT_EVERYTHING) < 0) { cout
  5. If this is to be the first game you create on your own or ,especially, if it's your first game period, I would say that it's overly ambitious. Very few people actually want to let pong or Tic-Tac-Toe be the first game they make, but if your just starting that's exactly what I would reccommend. Trying to complete a large project when starting out is pretty discouraging, coming from trying to make a large game early on myself. If you are experienced in making games, however, forgive me for assuming . I would have to second Unity in that case.
  6. So, I have been trying to familiarize myself with the Separating Axis Theorem by doing a very basic collision test AABB vs. AABB. In this one I am only testing against the x and y axes. Now this code works, I tested it from every direction, but I don't know how. I messed up the naming or did some math wrong and it worked right, which is fine, except that I would like to know how to apply this to OBB vs. OBB and Triangle vs. OBB etc. Any help would be greatly appreciated. I will try and comment on things for clarification.   This function is much slower than it should be, but I created it to be very readable(Or so I thought)   //The functions returns an int because eventually I want it to return the penetration distance int BoundingBox::IsAABBColliding(BoundingBox * i_Box) //The i prefix is for distinguishing that it is an input variable {     // c1                c2     //  ----------------     // |                  |     // |                  |     // |                  |     //  ----------------     //c4                 c3     //     // c = corner     //The corners and centers of the rectangles     Vector2D c1A, c1B;     Vector2D c2A, c2B;     Vector2D c3A, c3B;     Vector2D c4A, c4B;     Vector2D centerA, centerB; //No reason to calculate these(until OBB)     //Center of first     centerA.X = xCenter, centerA.Y = yCenter;     //Center of second     centerB.X = i_Box->xCenter, centerB.Y = i_Box->yCenter;       //w is width, h is height     //Corners of first     c1A.X = x, c1A.Y = y;     c2A.X = x + w, c2A.Y = y;     c3A.X = x + w, c3A.Y = y + h;     c4A.X = x, c4A.Y = y + h;     //Corners of second     c1B.X = i_Box->x, c1B.Y = i_Box->y;     c2B.X = i_Box->x + i_Box->w, c2B.Y = i_Box->y;     c3B.X = i_Box->x + i_Box->w,  c3B.Y = i_Box->y + i_Box->h;     c4B.X = i_Box->x,  c4B.Y = i_Box->y + i_Box->h;     //Left normals of top and right     //These are the two axes(in this case) that I need to check against     Vector2D rightNormalA = c2A - c1A;     rightNormalA.Y *= -1;     float tempX = rightNormalA.X;     float tempY = rightNormalA.Y;     rightNormalA.X = tempY;     rightNormalA.Y = tempX;     Vector2D topNormalA = c3A - c2A;     topNormalA.Y *= -1;     //Do the left normal     tempX = topNormalA.X;     tempY = topNormalA.Y;     topNormalA.X = tempY;     topNormalA.Y = tempX;     //  ^     //  |     //  |     //  | P topNormalA     //  |     //  |     //  |               Q rightNormalA     //  |---------------------------------> //At this part I though I had them right at first. It only stopped the box when it was completely inside of it. So i messed around with the order of //the corners and it worked from every angle( I don't know why). Also the numbers represent which box the projection is for.   min = minimum max = maximum proj = projection     //The minimum and maximum projections of box 1     float q1_min_proj = Vector2D::DotProduct(c2A, rightNormalA); //x axis     float q1_max_proj = Vector2D::DotProduct(c3A, rightNormalA); //x axis     float p1_min_proj = Vector2D::DotProduct(c3A, topNormalA); //y axis     float p1_max_proj = Vector2D::DotProduct(c4A, topNormalA); //y axis     //The minimum and maximum projections of box 2     float q2_min_proj = Vector2D::DotProduct(c2B, rightNormalA); //x axis     float q2_max_proj = Vector2D::DotProduct(c3B, rightNormalA); //x axis     float p2_min_proj = Vector2D::DotProduct(c3B, topNormalA); //y axis     float p2_max_proj = Vector2D::DotProduct(c4B, topNormalA); //y axis     bool separate_p = p1_max_proj < p2_min_proj || p2_max_proj < p1_min_proj;     if(separate_p)     {         return 0;     }     bool separate_q = q1_max_proj < q2_min_proj || q2_max_proj < q1_min_proj;     if(separate_q)     {         return 0;     }     return 1; }
  7. Unity

    If you want to design a 3D game engine, I would reccommend getting the book Game Coding Complete 3rd or 4th edition. You can download the source code for the engines that he creates throughout the books here -> http://www.mcshaffry.com/GameCode/.
  8. I always find that a whole lot of prior planning helps when creating a game, even one thought to be very simple. It gives you a clear destination and direction along with a more definite number of steps to get there.
  9. I have been working on a simple space shoot em up and I have been having some trouble with the movement of my ship. It moves fine when you use the directional keys except that when your first hit them the ship jumps then begins moving fluidly. Another question: whenever I have a direction key presssed down and then hit any other keys, then my ship ceases movement and no longer picks up the key being pressed. I would greatly appreciate help and thanks in advance. p.s. If you need more information don't be afraid to ask