• Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

5 Neutral

About AlexKay

  • Rank

Personal Information

  • Interests
  1. Sorry your question seems like asking "how long is a piece of string"? One person's idea of small is mammoth to someone else. Learning from what baseline, know "hello world in C++" or have worked on million line projects for 10 years? A lot also depends on the type of game. How about a different tact. I think everybody knows DOOM? Those 4 guys each had 10 years experience making and publishing games - before starting idSoftware. Then they made a handful of games together, like Wolfenstein. After that they made DOOM. Lived in a shared house and worked on it pretty well every hour they were awake. How long? That took 12 months. By today's standards DOOM is a small game. Not sure what you had in mind? If you know C++ and Linear Algebra (matrices, vertices...) well and you only have to learn SDL/OpenGL then should be able to make some "hello triangle" - hey it moves type "games" in a couple of months I reckon. 3D is a lot more work, probably a year to make something which doesn't have everything in it. Initially you can borrow the art but will eventually have to make your own. The first few games will not be games, they'll just be programs which emit graphics while learning. It can be done.
  2. Why A.I is impossible

    Ha ha, yes indeed, you are correct. I wasn't intending to use words like intractable and undecidable in a formal computational complexity sense, I just meant "hard stuff for computers to work out" - but I couldn't think of alternate words. I am glad you pointed out the more precise meanings of those terms, so thanks for that. I probably should've just said "when there's hard stuff for computers to work out - don't just take the opportunity to launch into 'a proof' of pretty well anything you like'. Civilisations have been lying along these lines for millennia, "why am I sad or sick", "well of course the devil did it", or in more recent times - "let's do a lobotomy that'll fix your mood swings". Or "your child has ADHD so pop these pills ... trust me I'm your doctor..." Years or centuries later those plausible sounding arguments don't sound so plausible. I forgot his name but didn't Mr Lobotomy win a Nobel Prize for that piece of brilliance?
  3. Does violence stem from video games

    I’m no historian, but I’m pretty sure violence came just after the Xbox 1 and a bit before the PlayStation 3? Err I could be wrong. Seroiusly, people who think violence stems from video games must only know history going back to a couple of years ago. I wonder if they can read? Actually, no I’m wrong, but it does prove time travel. The Romans, Nero, ... countless others, Hitler, Stalin they all had PlayStations which must’ve been transported back in time - before that no doubt they were really nice guys.
  4. Why A.I is impossible

    Sign me up, where do I send my money? Lemme see if I’ve got the hang of your logic though: Step 1 - insert some intractable or difficult problem [ here ] Step 3 - therefore this proves ... [ insert some unproven assertions here ] Ok, let me have a turn. Step 1 - forget “a.i” how about just simple multiplication and division? I’ll bet you can’t devise algorithms for something as simple as finding the factors of a large number. Yep that’s all. You know the factors of 77 are 7 and 11, the factors of 100 are 2, 5, 10, 20 ... but now do that with huge numbers. All the computers in the world running for thousands of years can’t do it. Step 3 - therefore this clearly proves .... faires. .... Hey I’ve go the hang of it. My cheque is in the mail ... .... There are some things computer algorithms just cannot do - never mind “a.i” - even some alegedly very simple questions cannot be decided! This was all demonstrated only some 80 years ago (Alan Turin / Alonzo Church ...). And no - Moore’s law won’t help nearly enough. So just because we may or may not be able to solve intractable problems doesn’t mean we get a free ticket to “prove” - or - disprove anything else we like. You’re explanation for why we can’t create a.i. is as good as mine. The answer is fairies. You might need to elaborate on step 2 a bit more. So yeah good luck.
  5. Was it a mistake to develop my own engine?

    You are correct fully bouncing off walls is not the proper thing todo. I have implemented “Collision Detection with Sliding”, but it was a while ago and it’s way past my bedtime so sorry I can’t remember any details, except it was pretty easy todo. IIRC I just had to tweak a couple of functions ... the answer might be nearer than you think. As for your original question - no I don’t think you made a mistaking implementing your own engine. When I tried to understand Quake, Doom, Unreal, Unity ... I struggled to get anywhere but when I got neck deep in my own engine I gained the deeper understanding and insights I previously lacked. Now I can understand those other engines and finally could use them if I really wanted to. I suspect you’d be in the same boat so all is not lost. So yeah go for it I reckon doing your own engine is great ...
  6. In your first post you have this function: /*picking function*/ bool picking(int x,int y) { int mouse_to_image_x, mouse_to_image_y;//get mouse position in the image mouse_to_image_x = 30 - x; mouse_to_image_y = 30 - y; if((mouse_to_image_x < 0 && mouse_to_image_x > 7) && (mouse_to_image_y < 0 && mouse_to_image_y > 7))return false;//mouse is not in the image for(int i = 0; i < 7 * 7; i++) { if(pixel_alpha[mouse_to_image_x][mouse_to_image_y] == 255)return true;//in the image and alpha channel is 255 } return false; } and this data structure BYTE pixel_alpha[7][7];//save alpha channel matrix If you have gone to the trouble to store hittable bits in your own data structure wouldn't you be better of just looking up the alpha value at a given location instead of iterating in a for loop searching for it // something like this? lookup_x = mouse_click_x - location_of_object_x; lookup_y = mouse_click_y - location_of_object_y; if( (lookup_x < 0 || lookup_x > 7) || (lookup_y < 0 || lookup_y > 7)) { // WAS: OOPS had && but can't be less than 0 and greater than 7 // NOW: changed to || return 0;//mouse is not in the image } hit = pixel_alpha[lookup_x][lookup_y]; return hit; Say mouse_x is at 355 and object corner is at 351 you need to lookup 355-351 = 4 and a similar thing for y. Also you are storing value 255 in a BYTE, I presume a BYTE is 8 bits, so it'll cost 8 bits for each texture bit. Wouldn't you be better off using 1 bit per bit (hope that makes sense). Sorry I can't be more specific since I'm not sure what you're trying to do, these days I would use modern OpenGL and vector graphics and I'd render to an off-screen frame-buffer, each object in its own color with unhittable objects left as black then I'd use glGetPixels to decide what was hit. So called "Color-Based Mouse Picking" ... It requires a lot more code than this - but it gets to run on a "hardware" accelerated board so probably worth it? Cheers.
  7. Let's say you have a texture which is an image of a button or something - and now you want 15 buttons. And another texture - a kitten - so you have 20 "Entities". One way to do all this is to have a struct or Entity class which has it's own bottom left x,y and top right x, y to form a bounding box, yes, a good old fashioned rectangle. Not buttons, not kittens but rectangles. Now you would have an array or list of all such Entities, each with their own x, y locations. So you can go through your master list which has all the Entities - if the mouse x, y is not even in the bounding box of an Entity then it can quickly and easily be eliminated. There is no point in drilling down into the details of each kitten pixel if you aren't even in the same ball park as the bound box rectangle. Right? For these "broad phase" collision tests you can use other simple shapes as well:- like circles, spheres, cylinders or whatever. The concept is the same. Back in the day I was an avid arcade game player and could've sworn they were doing pixel perfect collision detection. Years later I heard the actual author say it was just a bounding box or circle test. Had me fooled. Yes you can drill down and "sample" the RGBA of a texture but I'd get the bigger picture as described above sorted out first. And if you have many thousand objects then you would benefit from partitioning space. A simple Grid with Cells or Quadtree for 2D, Octree for 3D will help you reduce the master list, you'd have a sub-list which only contains Entities in that neighbourhood ... (At any rate I would not create my own data structure containing just the alpha channel bits. That's all on the CPU with regular system memory, you'd want more OpenGL and hardware acceleration help).
  8. “Where to start” is a great question - and there have been some great answers which I wholeheartedly agree with. Especially about starting small! I know the temptation is to go all-in with all guns blazing but that'll lead to nowhere but frustration. I strongly recommend that you really understand how something like Space Invaders or any other 2D arcade game with sprites works. Then you will understand how thousands of games work! I reckon C with K&R is great and well worth the read (and re-read). OpenGL is written is C, SDL is written in C, GLSL is "C like", we have C++, C#, Objective-C ... You can do C++ without first learning C but I'm glad I did C first. At least I understand what has no become some sort of secret - memory is not infinite and must be managed. The memory fairies won't be able to sprinkle fairy dust and make all the problems go way. Chances of going astray with C are pretty low. You could then get SDL which is an OpenGL library and learn the examples it comes with like fireworks.c - then modify and build from there. Or you could start with Lua - a C like language which is used a fair bit in the gaming industry. If C++ is king then Lua might be a prince? There are many engines like Corona Labs which run Lua. The App Store must have thousands upon thousands of games built with it. You can find many small game examples to get you started. C++ ? Hmm, I fear you might get distracted and roam around the wilderness a few years! It is a big language used in so many different ways in so many different arenas - it does not all translate well to game programming! Often the opposite of what you need!. I am not rubbishing the "GOF" Pattern Book, it has some deep insights and knowledge. But evidently too deep for most people: It says "favor object composition over class inheritance" (page 20), but what does the world do? The exact opposite! Deep and wide hierachies everywhere. This is only completely different, 180 degree, PI over 2, boolean negation operator, opposite! Went left - should've gone right. WOW. And then there's STL, Boost, Templates, Multiple Inheritance and whatever else. Again these are not without merit (STL and Boost saved C++ IMHO) but for gaming they can all be a big problem - falling into a pit or three is almost assured. Anyway I reckon finish C with K&R and either get SDL and examples which run with SDL. Or go to LUA. Either way learn what a game loop is ... Once you understand games and have built a few small ones then you might go to C++ - at least then you will be anchored on what is necessary for gaming.
  9. Your example will probably run at 500+ FPS so efficiency is not an issue at this stage. Far from it. Checkout the site learnopengl.com it goes through everything step by step. Forget efficiency for the moment - you'll want to texture the cube, then move the cube around, read an OBJ file to move beyond cubes and then render that model, maybe a few instances of it, a camera, matrix transforms, basic lighting .... that or similar is the usual order of things. Do work out how to calculate FPS and display it in the Window.title bar or Console - that way you'll know where you really stand as far as efficiency goes and if / when you need to do something about it. Meantime over thinking it all will just cripple your progress. (Sooner or later google "bunny.obj", download it, read it into as a mesh and render that ...) my 2 cents worth.
  10. I definitely agree you should start with 2D, get things going make something small to learn from then you can expand from there. SDL is very good, it is used in a lot of small and heavy duty games. But I did found it hard to find good material so I had to expand my horizons and look at the other OpenGL tool kits like:- glfw, SFML, LWJGL/Java and WebGL. Under the hood they all use OpenGL - so it all helped. I wanted example projects bigger than HelloTriangle and smaller than Doom3 - could not find much in-between. BTW of all of the OpenGL tool kits SDL is my favourite because it does mobile and it just works! Anyway have a look at: 1. The example apps that come with SDL (or SFML, LWJGL or whatever). 2. http://www.lazyfoo.net/ - shows you how to setup on Windows, Mac, Linux, with and without mobile. There is no great architecture here, just example by example - but then you can take that knowledge and use it in your games. 3. https://learnopengl.com as mentioned here already. Uses glfw not SDL but it is a good site and there's a free book you can download. 4. http://learningwebgl.com/blog/?page_id=1217 (WebGL yes I know ... but still it is OpenGL under the hood and you can quick learn from those guys. Lots of stuff on YouTube but many of them take 100 videos just to make the most primitive game - it should only take about 10 vids not 100. Everything is easy once you know how. If you learn how one sprite based game works (like Space Invaders) you will realise they are all more or less the same. Good luck.
  11. Welcome theelephant, (I'm new here too but been doing game dev a good while now). Definitely, absolutely and make no mistake about it - start with something small. An arcade 2D game like space invaders is the way to go. Forget 3D for now. There is no best engine, they all have fans, so yes you'll hear conflicting stories. But people are all different so you have to find what works for you. At this stage the best engine is the one you learn most from! And I definitely wouldn't be paying for an engine at this stage (I did in the past but never mind that ...) - there are now so many great free choices. Corona Labs have a Lua based 2D engine. It was subscription based but now I believe it is free. Lots of examples, tutorials, vibrant community, remember learning is the big deal at this stage. Angry Birds is Lua based, I unpackaged the original iPhone version, I can see Lua guts but can neither confirm nor deny the rumour it was actually done in Corona? Still plenty of real games done in Lua. Love2d is yet another Lua engine with real fans and games. Godot - seems to be very good but they use their own custom scripting language. I've only tinkered with Godot but I got it up and running within minutes and the demos all worked flawlessly. A pretty polished open source engine. Apple's SpriteKit - if you decide to get into programming more? It is pretty easy to use, I made a game in about a week or two (but I've been programming a long time). It has a thriving community with plenty of examples and tutorials. Unity 3D is bigger than the above and pretty good - but it seems to me there is a reason it's called Unity 3D - it feels like 2D was an after thought. Anyway it starts free but sooner or later you feel the urge to start buying stuff from their store ... Unreal Engine is even bigger and definitely the real deal - but you need beefy hardware and again it's really a 3D engine pretending to be a 2D one. Maybe SDL, it is C based but it can work with Python or Lua... Again that's if you get into programming more. But SDL very good. I suppose I should mention Java with LWJGL. Not my first choice of language or environment but apparently you can make popular games with it as in Minecraft. You run but not hide from programming and maths - either you will have to do it or beg/pay someone else to do it for you so the more you know the better. And you might discover you really like it. Sorry I don't have a simple and clear answer - it depends on you - but have a look at Corona Labs and Lua see if you can sink your teeth into that. Meantime learning is the answer. And game design is more important than which engine. Hope that helps.
  12. 3D Do models go inside a BSP?

    Just to clarify I wasn't advocating BSP Trees as the be-all-and-end-all of game related tree structures. But the OP did say 'starting to think about BSP Trees", and rightly or wrongly, I jumped back in time to when I started with them. I bought a dozen books and read everything on the Internet on the subject but frankly the signal to noise ratio was and still is pathetic. Sad rubbish. I only made real progress and got all my questions answered after I somehow cobbled a version together and played with the code. I guess I was channeling my university professor who said to me "yes I can give you all the answers but that'll be like reading a book on How To Swim! You can read and think until the cows come home but you have to write code then you'll truly understand..." So I stand by what I said "if you have great information and source code for Octrees or Bounding Volume Hierarchies (BVH) then by all means go with them first". And I don't treat code as so precious that it cannot be changed, tweaked, improved and thrown out. Master whatever tree you can and keep moving. Have a nice day, Thanks.
  13. 3D Do models go inside a BSP?

    Sorry, late reply and most points have already been answered but I really like BSP Trees so why not ... and they're actually good questions.
 If your engine is mainly about outdoor scenes then you will not benefit from a BSP Tree or any other tree. BSP Tree's are predominantly about indoor scenes. To build a BSP Tree you feed it all the static polygons of the world. Dynamic ones are not included at all, they come later. You have an empty world with walls, ceilings, floors, steps and any other static objects you want to "bake" into the map. You need a way to specify all this. Sure you can build a world in Blender or Maya but then you need a way to flag what polys are walls, which are floors, which are ceilings. Most game engines don't use Blender or the like for world creation, only for models. For levels or worlds Doom had doom-ed, Quake had quake-ed, Unreal has it's own built in world editor... You can just create a simple text based map file, similar in nature to OBJ files but for maps. You specify walls, floors, ceilings and refer to OBJ files for static objects. After reading this file you can create the specified wall, floor and ceiling polygons and OBJ derived static meshes which are of course just more polygons - feed them all into a BSP Tree, partition along walls and you're ready. Once a tree is built and the game is up and running - then dynamic models come into play, they can quickly determine what can be seen from any given room - but it's not just about visibility - the BSP Tree lets you test for collisions, you obviously don't want to walk through walls or fall through floors. For dynamic to dynamic model collisions the BSP Tree cannot be used, they aren't even in there, you probably need an additional scheme. I'm just using a grid based division for this, there is no point checking for collisions with other dynamic objects across the world, only check within neighbouring cells. Apart from BSP Tree's there are other partitioning schemes but if you're anything like me the only way to truly answer all the questions is to build one and play with it. It's a case of build first, ask questions later. Once you master one scheme you can quickly and easily bridge over to others. Sure if you have great information and source code for Octrees or Bounding Volume Hierarchies (BVH) then by all means go with them first - but for me the Michael Abrash Black Book and associated code was a deciding factor. It's not really a book, it's a collection of articles so you don't have to read it all. I find most of the information about game programming "out there" to be rubbish - but Abrash worked with John Carmack on Quake so this is the real deal and he has code examples. Thanks Michael, thanks John.] (Spoiler alert - for Quake which has polygon based dynamic models they ended up using z-buffers after all but only in a limited way and just for mixing dynamic and static polygon models. Now we have z-buffers handed to us on a silver platter, just enable GL_DEPTH_TEST and let OpenGL do its magic). Hope that helps.
  • Advertisement