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


  • Content count

  • Joined

  • Last visited

Community Reputation

150 Neutral

About stevo86

  • Rank
  1. I'm not sure exactly how you handle your textures, but if you're not already using PNG, I'd recommend using it as this will probably be easier if you do. Anyways... To do flashlight lighting, you'd want to create a blank image (as in transparent background) in your paint program. Then just draw a spherical gradient from white to transparent in the center of the image. Save that as the light. In your code you then load the image and enable blending (glEnable(GL_BLEND)) and set the blending function to glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA); and draw your light quad with the light texture on it. Probably want to set the transparency down on it too, maybe set glColor4f(1, 1, 1, 0.7f); or something so the things underneath it still show through. I could be mistaken on the exact parameters for the blend func, I haven't played with it in a while and I haven't started implementing the lighting in my current project so I'm not totally up on it, but a quick Google on glBlendFunc can list the different choices and if you just plugin a few different combinations you'll find the one you're looking for.
  2. This is a very strange problem that I cannot seem to resolve. I've created an absolute basic windows program along the following lines: WNDCLASS wc; PIXELFORMATDESCRIPTOR pfd; int format; memset(&wc, 0, sizeof(WNDCLASS)); memset(&pfd, 0, sizeof(PIXELFORMATDESCRIPTOR)); wc.hbrBackground = GetSysColorBrush(COLOR_3DFACE); wc.hCursor = LoadCursor(NULL, IDC_ARROW); wc.hIcon = LoadIcon(NULL, IDI_APPLICATION); wc.lpfnWndProc = os_proc; wc.lpszClassName = "BaseWindow"; wc.style = CS_OWNDC | CS_VREDRAW | CS_HREDRAW; if (!RegisterClass(&wc)) { return false; } if (!(gwnd = CreateWindow("BaseWindow", "Window", WS_VISIBLE | WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, CW_USEDEFAULT, width, height, NULL, NULL, ginstance, NULL))) { return false; } gdc = GetDC(gwnd); if (!gdc) { return false; } pfd.nVersion = 1; pfd.nSize = sizeof(PIXELFORMATDESCRIPTOR); pfd.iLayerType = PFD_MAIN_PLANE; pfd.iPixelType = PFD_TYPE_RGBA; pfd.cColorBits = 32; pfd.cStencilBits = 8; pfd.cDepthBits = 24; pfd.dwFlags = PFD_DOUBLEBUFFER | PFD_DRAW_TO_WINDOW | PFD_SUPPORT_OPENGL; format = ChoosePixelFormat(gdc, &pfd); if (!SetPixelFormat(gdc, format, &pfd)) { return false; } grc = wglCreateContext(gdc); wglMakeCurrent(gdc, grc); glViewport(0, 0, width, height); glMatrixMode(GL_PROJECTION); glLoadIdentity(); gluOrtho2D(0, width, 0, height); glMatrixMode(GL_MODELVIEW); glLoadIdentity(); glEnable(GL_DEPTH_TEST); glDepthFunc(GL_LEQUAL); glClearDepth(1.0f); glClearColor(0, 0, 0, 0); int ret = glewInit(); if (ret != GLEW_OK) { return false; } if (!GLEW_ARB_vertex_program) { printf("Vertex shaders are not supported\n"); return false; } else { printf("Vertex shaders are supported\n"); } unsigned int id = glCreateShaderObjectARB(GL_FRAGMENT_SHADER_ARB); Now the odd part about this is that even though I'm calling glewInit() and verifying that it works, and verifying that I do have shader support, the second I run the program, I get the following error: "Unhandled exception in program.exe: access violation at 0xC0000005" When I hit OK, Visual Studio highlights the following line as the cause of the problem: unsigned int id = glCreateShaderObjectARB(GL_FRAGMENT_SHADER_ARB); Anyone know the cause of this? I'm using an HP Pavilion d2035us laptop with an Intel 945 Express chipset.
  3. The UDK is already the best engine out there right now for 3D game development (in my opinion). The toolset is extremely easy to master, at least it was for me. After a few hours mucking about with it, I was able to create some fairly complex levels (geometrically speaking) and the lighting engine is second to none with the possible exception of the Crytek engine. I've never really spent time developing a full game with it, but I have used the scripting engine, the editor, etc., and found them all extremely simple to use, especially if you're already using a programming language like Java or C++ or C#. To be fair though, I've never used the Torque or Unity engine yet.
  4. It's a lot easier to get other developers involved from a professional stand-point when you flesh out as much as possible so that it doesn't look like you simply had a whim to make a game and typed up a 1000 word description. Design documents can certainly be flexible when a feature turns out to be wrong for the game, but the fact that it's documented and described makes the coding/content-creation/etc so much quicker and easier. The easier it is to visualize YOUR idea, the quicker the realization and the more accurate the interpretation will be. If you say stone-age RTS, I may think Fred Flintstone and you may think Jurassic Park, but by fleshing out exactly what you want, it's a lot easier to distinguish between the different ideas. And as I said, there's always room for improv.
  5. The simplicity is fine for broad strokes and getting people interested, but if you expect people to join a team and help develop the game, you're going to need to flesh out every single little detail, down to the way the user interface will look and which mouse button will select units and which will move them. If you're just running a design idea by the people of gamedev.net, it looks good. It sounds interesting that's for sure.
  6. I've never been a big believer in the 8/8/8 day for a few reasons. First, if you are one of the few people who land their dream job, chances are good you wake up and read your industry news, maybe do a little research on something, then work. And you don't keep an eye on the clock waiting for it to strike 5 so you can run out the door, you generally get lost in your project and look up and realize it's 5AM, the next day, jump up, call your wife and apologize like hell. Also, sleep is for pussies! Game programmers make everything happen. If you want to get creative and make earth's gravitational pull reject you and push you away, you'll need to program that. If you want trees in your game, you need to program them and give them properties. Want them to catch on fire when you shoot them? Program it. Programming games is definitely not a 8/8/8 job because if you treat it like one, you won't get a job in the industry. Give it a shot before you sign anything.
  7. It could go either way really. I could argue that Dink Smallwood turned out to be a great game despite having an 11,000 line header file and a single source file for the whole game, or I could argue that Unreal Tournament (the original) defined every object, even redefining objects like classes. It all depends on your experience level and style. Carmack accomplished the same thing Sweeney did using a mash-up-hack C method of coding while Sweeney used design patterns and object-orientation. Both games turned out to look, feel, and play about the same. This is what makes me argue that it really doesn't matter. When I say you're overdoing it I just mean that someone with less experience should be focusing on the core game itself, not complex design patterns and object-oriented programming. They're just weapons in a coder's arsenal, and like weapons, you should probably learn to use the basics before moving onto the complex. Things generally get ugly if someone thinks that because they can use a knife they can use a gun. And I'm definitely running this analogy straight into the ground so I'm gonna stop myself here. So for now, just keep in mind what you're trying to do and how it will affect the end-result. Keep It Simple, Stupid (KISS), is another practice that many famous programmers have religiously advocated. Its hard to tell you how you SHOULD do it because based on the code you've shown, I doubt the Bullet class is the only one being over-complicated. I personally just create an array during initialization, drop a projectile in it when needed, then set it's state variable to DEAD when I'm done with it. I do a little more than that but it's not much more complicated than a simple array.
  8. People often overuse inheritance and code-reuse because they're taught from the beginning that it's pretty much the holy grail of software development. Problem is, in my experience, your first few attempts at creating a technology are not going to be good enough to merit reuse. What's worse is that you spend 8 months trying to figure out if you should create a hierarchy that stipulates Base->Renderable->Dynamic->Bullet or just Base->Object->Bullet or however and forget that all you're trying to do is make a handful of pixels zip across the screen which will probably only be visible for a quarter of a second anyway, and then clean up the memory used for it. One of the most intelligent things I've ever heard was, "A good engineer can estimate the difficulty of a problem and choose the correct set of approaches to consider as solutions..." That was Jay Stelly from Valve, discussing one of the technical problems they had when creating Half-Life. His point was they found a good middle ground devoting just enough time to solve the problem in a way that would be acceptable but they didn't spend 3 years working out how to solve something that most players wouldn't notice. MY very long point is this: will your player notice a difference if your bullet that flashes across the screen is inherited from 8 base classes or just 1 base class? If you're trying to create a reusable engine and this is your first attempt at such a project, I'd say drop the "reusable" part and the "engine" part for that matter and focus on the end-result. Once you can complete a whole project it makes it much easier to break down how you want objects to interact in the code.
  9. This is gonna get ugly. The problem is an indie developer very rarely has a ten million dollar budget to feed himself with while he tweaks and optimizes his code. Usually he has a few hours a night in between shifts at the day job which pays for his food and rent. Releasing it always takes priority. Would you rather starve for an extra month while you optimize your engine so that it runs at 8000 FPS on a 133 mhz PC while still using all the latest technology hard-coded in assembly, or would you rather accept that 20-30 FPS with some neat effects and fun gameplay and a release-date are worth settling for so you can get some sales and be able to afford eating more than once a day? It's not so much that indies are lazy or stupid it's that they're new and need to be able to get a game out the door as quickly as possible so that they can get some cash flow. I think you'll find that if it's an indie developers third or fourth SUCCESSFUL game release, it's usually much better optimized. Once you have a little bit of a cash buffer, it's a lot easier to say, "Ok, we'll spend two months optimizing the engine so we can get it up to 60FPS on our lowest target specs." When you're eating those cheap pasta-in-a-cup things for breakfast and skipping lunch and dinner because you have to ration your pasta-in-a-cups, you're going to be kicking the game out the door as quickly as possible. Is it the right way to handle it? Probably not, but I can't say I would handle it differently. So I guess what I'm saying is that I'm confused by what you're saying. There's nothing special about the game development industry, it looks like the standard for any accessible industry. Lots of slightly knowledgeable people who've read a few books, a decent number of people in the middle-range, and then the handful of extremely talented folks like Carmack or Sweeney. The only difference is with the internet it's very easy to create a company and release your product to the public. This means you're going to be seeing lots of poorly written code with a good gameplay mechanic (think Braid) selling millions of copies and a couple of well-written projects with good engine mechanics selling millions of copies (Serious Sam, Unreal, Doom).
  10. Little off topic but I would probably work a little on cleaning up some of the names in your code. For example, you've got a function called draw() and another called render(). What's the difference? On to your dilemma. I haven't used SDL_ttf too extensively so I can't be of too much aid on why the text isn't drawing, but I can say that from the looks of it, it's probably a setting. Are you rendering to the correct, visible coordinates? Does m_fg contain a 4 floating point values and is the alpha component at least 0.1? Little things like that are usually a good place to start. Another thing I noticed is that you don't have any calls to glEnable(GL_TEXTURE_2D). Without that you won't render whatever texture you have loaded in your loadTexture function.
  11. I'm not sure if GLUT can do this. If you just use OpenGL and Windows it's simple: ShowWindow(hWnd, SW_MAXIMIZE); UpdateWindow(hWnd); And if you want to lock it at a maximized state it should be just a simple event processing message: LRESULT CALLBACK WindowProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam) { switch(uMsg) { case WM_SIZE: { return 0; } break; } }
  12. My goal is to take an MD2 file, extract the information I need (essentially just the individual frames) and perform all the calculations necessary to get to the ACTUAL vertex information (not the compressed-encoded-bit form of the vertex index(I know I'm in a forum of overly-logical and analytical programmers so just to clarify, that was an exaggeration)), and write a new file using only that information. And if it turns out to be a nightmarishly large file I can always work on compressing it down later on. We're selling terabyte external hard drives for less than $100, I don't need to compress every single bit to 1/10000th of it's original size like we needed to for Quake or Quake 2, and I don't need the added complexity of skeletal animation or separate meshes like the milkshape format has, just the plain old vertices frame by frame that I can interpolate between and stuff into a vertex array to throw at the GPU. If anyone could try and help explain how all the indices work together and how I would need to arrange them to make them VA-friendly, I'd greatly appreciate it. Or if you've got another suggestion that would be more speed-friendly, I'm open to suggestions.
  13. I know I'm going to sound harsh, but I was forced to go to a christian church for 18 years of my life so I have to touch on this. I understand the desire to be unique but the fact that you're asking for ways to design a game that traditionally uses magic (which it uses because it's a fun gameplay mechanic) and replace it with something functionally equivalent to magic but with a different name in order to impress your friends? This is like me asking how I could murder people without the nasty consequences like death and a lifetime in prison. If you're just doing it to keep your pastor around, your stupid. If you agree and don't like the concept of magic and feel it goes against your religion, that's fine. Just don't tell me that you're not going to design a game with, of all things, magic in it because your pastor won't hang out with you anymore. Which brings me to my next point. Isn't the point of magic to basically obliterate anything thats in your way (not counting the one boring healing spell that every game HAS to have)? With murder being a sin and all, wouldn't that just as easily offend your friends? /rant On a more productive note, break magic down to it's core and it's simply something that we don't understand. Electricity was once considered magic. The sun was once considered a god and actually still is in some parts of the world. Any magician can tell you that the "magic" they do on stage is simply something that people don't quite understand or can't explain. It can be anything really. Common example from... well just about all RPGs: throwing a fireball from your hand because you said some special incantation or whatever. You said some weird things and fire flew from your hands. Why? Don't know. You read from your Book O' Magic and your friend suddenly notices his pain is gone and injuries have healed. Why? Just because. Just get creative and think of a pretty way to package up the unknown or unexplained. That's all magic is. The good thing is you're going for different now so you have no predefined rules to adhere to and can pretty much make anything happen to anyone from anywhere.
  14. 1. Start with C#, you'll make be making things quicker. Once you understand how a language works, it's normally easy to learn another one. 2. It's not something you're going to learn overnight. It's going to take a lot of repetition before you're to the point where you can easily remember most of the language. Even then, you'll still have quite a bit to learn. They say it takes 10,000 hours to become great at something, so make sure you want to become great at this. You're looking at a long haul. 3. Start with something small that you can complete in a day at most. Think screensaver, Pong, etc. Something that is maybe a 1 or 2 on a scale of difficulty to make. Then move onto a 3 or 4, such as a game with more sophisticated rules like Tetris or Asteroids. One of the best things I read was that your first 10 games will suck. Get to the point where you can make them, make them, and be sure to complete them! Completing projects adds tons of experience. It's real easy to say, "I can learn to program sound later, when I really need it." When you're finishing a project, you actually have to force yourself to do all the monotonous, repetitive things that nobody really wants to do, and if its for one of your first 10 games, good chance it will be nice and easy to work through it. EDIT: you don't have to start on boring topics such as console projects when you first start. Just simple ones. And while a text-based RPG may sound simple, it's not I assure you. It's the same as an RPG, you just don't have to draw things for it. Stick to SIMPLE game concepts (Pong, Tetris, Asteroids, etc) and you'll be fine.