• 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

382 Neutral

About kaysik

  • Rank
  1. I think you'll find that your polygon is upside down and hence backwards, so its getting back face culled. It turns out that with OpenGL and Ortho2D() the bottom left corner of the screen is (0,0), with y going up the screen, and x to the right. As such if you've planed your polygon with top-left as the origin your winding order is probably backwards and hence pointing away from the screen at a guess.
  2. The way we've done it is by useing imposters. The idea is that you really only draw the front couple of objects, and for anything further away all you draw are particles, textured to look like the object. So you render your oject to a texture, then for anything too far away, or after say the firstly 100 objects then you just render quads with the texture. It'll break any fancy shadow algorithms or special shaders, but if they're far away then they probably don't need that stuff to begin with. If you have animating objects then you can have a couple of different frames rendered out, then pick the closest one. As long as you update the objects closer to the camera properly, you can get away with only updating the objects far away pretty rarly! Like once or twice a second. If you have 20k objects update say 1k per frame. The closest 500 objects every frame, then the next 500 objects out of the queue based on how close they are and how long since last update. Everyone gets updated sometime, but the further away they are the less it happens. Edit: Its important to note that if you impliment this, the objects that don't update often will stand out to *YOU* really badly. Ask someone else to look at it and they won't notice a thing ... we wasted alot of time worrying about the back objects only updating once/twice a second when nobody but us ever even looked at them!
  3. Firstly - that drop is nothing! Think about what FPS means - its not a linear scale. Useing FPS is actually a pretty bad way to measure performance. Try useing miliseconds per render or something as a better alternative. Think of this: FPS = 1700, means 0.6ms render time FPX = 350, means 2.8ms render time So with a fps drop of 1350fps you add 2.2ms to your render time. Now consider this: FPS = 60, means 16.6ms render time FPS = 50, means 20.0ms render time So with a fps drop of 10, you now add 3.6ms to your render time. See why FPS is a bad measure of performance? A 10 fps drop from 60 to 50 means double the difference in render times between 1700 and 350. Honestly any change when your fps is higher than 120 means practically nothing!
  4. OpenGL

    OpenGL doesn't work like that. Its not a window - its a graphics API. What you need todo is setup an OpenGL texture like normal, then draw a quad that fills your window with the texture on it. There are heaps of tutorials on how to draw textured quad's so google is your friend :P Also look into gluOrtho2D(), because that'll let you draw an image in 2D very easily, without having to try to draw a 3D quad then line it up with your camera (which is a pain).
  5. If you know c++ at all then Try This!. Even if you don't know C++ that gives a pretty good explantion of the technique and theory behind it so you can impliment it yourself in some other language. Other than that - google is your best option.
  6. Help us out by telling us whats wrong :P You have failed ... but at what? You get compiler errors? You don't know how to create the classes themselves? Your #include errors? So on and so forth. Ask a specific question and I'm sure someone can help. Just say you failed and there are so many possible answers its hard to know what you actually want.
  7. Two things: 1) Are these questions of the "Lets make a FPS? ... No i want an RTS?" style? Or more a "Health packs should give you 100health! Nah thats too much, try 90hp!" type? The first type need to be solved now, the 2nd type need to be solved later! So if you know your making a FPS, and you know generally what the final game will play like then by all means start coding. If you still in the "FPS vs RTS" stage, then solve that now :P 2) Even if you do actually start making things now at some point you will need to end up agree'ing on the aspects of the game. When that happens the best way todo it is to get a list of questions, and then ask your team to get them answered by the end of the meeting, day, week! If your face to face its easier as you can just go down the list and write your answers on the spot. If you think up any new questions along the way just add them to the list. This is the best way I've ever found for directing discussion and finalising things - even if you yourself don't activly participate in the discussion. Ask the questions and get a definite answer. The answer might change in 2 weeks, but thats fine at least you've got something to aim at, even if your target moves every so often!
  8. 5 years ago, mobile games were snake. The best sound you ever got was tone beeps. These days you can get full 3D games on mobile complete with sound effects and music all properly mixed etc. Checkout some of the high end games on Brew/Symbian and you'll find their simplified ports of most hit games. Things like Need For speed: Most wanted, Splinter Cell and Madden are good examples of hit games that have mobile ports. High end phones now pump out graphis in the Quake, Quake 2 area of quality ... some of them even have proper 3D chips inside with many more planned for the future. So the trend is to psp/ds style of games and beyond. And that definatly includes sound/music.
  9. Quote:Original post by serg3d Rumors have it that iPhone will not be open to third party developers. What a pity. Looks like a perfect gaming platform. Hope I wrong. Anyone have any information about it ? Considering how closed the IPod video development is I'm going to say it'll definatly be closed. I know people working on an I-Pod game and they don't even get a dev kit or libs really. They have to send their source to apple, who builds it, tests it, then tells you what happened. So for ipod even an official developer never see's the device ... its crazy :P If apple is like that with the i-pod no reason they won't be like it with their iphone.
  10. Quote:Original post by Wavesonics Is this true and if so something to really worry about? For instance, should all the 3D math for a 3D engine be converted from float to double and would there be a boost in speed? On your standard PC floats are 4 bytes (32bits), and doubles are 8byte (64bits). So unless your running a new 64bit machine it means that a float fits nicely its 1 CPU register of 32bits. This makes it faster to work with than a double, which uses 2 registers so needs a bit of trickery to get working. How much faster/slower I don't know, but unless you NEED the extra precision of double its probably worth keeping your stuff as floats. Then again the biggest every speedups will always come from changing your algorithms rather than this kind of thing. So if your struggling for speed its probably worth your while looking at the collision detection and rendering algorithms rather than this ... but if you know those are the fastest you'll ever get then float on a 32bit machine is faster than double (in theory, i've never tested it).
  11. OpenGL

    Many people (and myself most of all) find OpenGL easier than DirectX. So if your struggling with OpenGL then turning to DirectX probably won't help you out much. It might, so feel free to look, but the general feeling is that OpenGL is sleightly easier. And as for good games made with OpenGL ... try Doom3? Quake 3? The Unreal Tournament 2k4 used OpenGL and SDL for its linux port too I believe. There are quite a few out there. Its true most A+++ games are DirectX, but there are definatly quality OpenGL games out there. Trust me its not OpenGL that makes a crap game - its the people making the game that make it crap :P As for the fact its hard. Hell yeah its hard :D If anyone could do it then it wouldn't be that fun. I did computer science at uni for 3 years, and now I've been programming profeshinally for another 3 years and I still have to learn new stuff all the time - its why its FUN. Most of the joy of programming comes from getting hard stuff to work. So while it IS tricky, and it'll bend your mind for ages, when you get it, then you'll feel awsome. Being 12 is a only little drawback because you just haven't done all the highschool maths yet like trig and vectors which is really helpfull for 3D apps. You can learn it no worries, but just be aware that you might need to learn a few extra things that most people are assumed to have. Just remember 3D is pretty mind bending the first time out, so if you haven't already make a complete 2D game first. That will teach you heaps without your brain exploding ... as much :P
  12. Try to USE your code for something. If you can't, or if its hard then its badly designed :P There's no way to actually tell. Its like asking "is this picture nice?", the only way to know is to look at it and see if you like it. The best you'll get is to ask some questions like the ones below, if you say yes to most of them then its good! Is it easy to use? Is it easy to re-use on another project? Is it easy to customize for future use? Is it split into nice manageable chunks? Is it clearly written, with at least some comments and proper var names? etc
  13. The way I do it is this: Input gets parsed by my input function and transformed from real keys (w,s,a,d etc) into game-codes (PLAYER_MOVE_FORWARD, PLAYER_MOVE_BACK .... etc). These are bit flags which get OR'ed together, but you could easily use an array of bools if thats more your style. The input function then sets these in the player entities controles variable. Then the generic entity class uses them on its next update. The beauty of this is two fold: 1) I can map any keys to be PLAYER_MOVE_FORWARD and no game code will need to be re-written. Only thing that changes is which keys my input function looks for to set those game codes. Makes it easy to let the user customize their keys. 2) I've written my AI off that. My AI is based on looking at an entities position and direction, then it sets those keys for each entity, and my entity class uses those to move around exactly the same as a player. This way I only have 1 entity class, which just has a set of attributes and a really simple update like: if ((controls & PLAYER_MOVE_FORWARD) != 0) ... vPos += vForward * entSpeed * nDT; Then i have an AIControler which just pretends to be a player. The keyboard sets the controls for the player entitity, and my AIControlers set the controls for all the other ones. Have a few different AI controler's for each enemy type and bham - your done.
  14. Quote:Original post by Crazyfool And if so, shouldn't this work int xarray[getX()]; No it shouldn't work. When declaring something like "int array[size];", the size must be determined at compile time. Useing a const int works because its known at compile time what the value of that int will be. However returning a const value from a function just means you can't change that value. It does NOT mean its known at compile time. You can do something like this: const int myFunc() { return timeGameHasBeenRunning; } Each time you call that function it'll return something different. So there is no way at compile time to know what the value will be, hence you can use this to create an array on the stack. The compiler needs to know how much stack space a function will take when it compiles, so an array declared on the stack must have a constant size that is known at compile time. Edit: Beaten.
  15. Quote:Original post by IKG Why didn't anyone ever mention GLUT? I didn't know much about it until now. Is it harder to use than SDL? I looked through the documentation real quick and it looks pretty simple. Also as a side question: Couldn't I theoretically use OpenGL to do the rendering (draw textures) for a ray casting engine? I know that would kind of ruin the purpose since OGL can be used for 3D and ray casting is for using hardware only, but would it work? If yes, would it be faster? Nobody mentioned glut because its a dead library. I think the last time glut was updated was in 1998, and thats ALONG time ago - its old, and it really shows its age. It is pretty good for learning (I learnt OpenGL useing it) but practically everyone who uses glut moves onto SDL in the end. Glut has some very handy functions but in the end SDL is more flexible and in my oppinion better organised. Glut is still good, but most people (myself included) would agree SDL is way better. And yes you can use openGL to render your raytraced image. But the raytracing to get your image will be very slow. OpenGL might actually blit the image to the screen faster that pure SDL or Win32 call, but if it takes you 10 seconds to raytrace your image, the few microseconds you'll gain from useing OpenGL to render the output won't make that much difference. Besides - if your doing this for technical reasons because you like a challenge then make a demo. Something that'll draw cool colours in pretty patterns to the screen. If your going to be making a game, trust me that setting up a window is the least of your problems. Useing Allegro, SDL or Win32 won't make the sleightest bit of difference after the first two weeks because the hard bit is actually organising your game logic, collision detection, physics and all that. The bit your worried about is the bit you'll only ever write once then cut+paste into every other project. Much better use of your time is to worry about your game being fun!