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

McGrane

GDNet+ Basic
  • Content count

    204
  • Joined

  • Last visited

Community Reputation

1743 Excellent

About McGrane

  • Rank
    Member

Personal Information

  • Location
    Ireland
  1. Getting closer - the reason it is not red, and/or other issues you may see may be due to your error handling. As you mentioned, you are seeing a linker error, but you are not doing anything but outputting the error, and then carrying on, this could be cascading the problem to the next shader, and causing unknown issues. The easiest way to handle this is to turn your compileShaders method into a boolean method, and return false once an error is detected (after outputting your error somewhere) - this way your program will stop at the stage it fails, rather then going on to do whatever craziness it might do after a section fails.. A shader failure is not something you really need to try to recover from, as if its incorrect its incorrect- you fix it, recompile, and hopefully it will move onto the next shader, and you fix it then and so on.. If you havent already, check out https://learnopengl.com/ Its a great resource for getting you up and going in opengl, and is quite easy to follow, unlike alot of the opengl tutorials out there
  2. Apologies, you are correct, i had said 12x rather then 9x. Are you getting any warnings in your code, I would expect the returning of the address shown below would cause a warning: You are returning the address of a local variable, which may also cause an issue, in this case you could just return what the value actually is. Maybe just step through your program and see what you get for your shader ID's VAO etc. when you generate them, and compare them when they are later called, for example with the above mentioned, see if the below is what is expected
  3. Just on this, although it appears correct, when you pass an array like this, you are passing a pointer to its first element, if you check the sizeof function, it will say the size of your array is only 4 bytes so when you pass your array using glBufferData, you are saying to pass the 4 bytes. Your coordinates array is 12 floats - which is 12 x 4 bytes = 48 bytes. So you are not sending the whole array
  4. At a very quick glance over you code, I suspect this is an issue (there may be more), you appear to be passing in the sizeof( pointer ) - what you need here is the size of the array you are passing in - so something like sizeof(float)*countVertices If the above doesnt help, maybe just add some error checks to ensure that your shaders are compiling and linking as expected- I know you dont want to add error checks yet, but maybe just start with these
  5. I have my doubts that anyone is going to download ( im not going to download some random zip file from a forum ) and fix your code for you considering you haven't said what the problem is, how you attempted to fix it, or what part you don't understand / is broken. Its a huge time investment considering you haven't invested the time in explaining the problem Maybe put your code on github or something similar that someone can just browse to safely, and explain your problem in more depth, and you are more likely to get help in my opinion
  6. 2D

    I know the article you referenced mentions that they wish to use Xwindow and makes points of how easy it is, but could I just suggest you use something like glfw if your main aim is to just do graphics programming - and once you get used to it you could switch back to X if you wish. Your above code also seems to mix legacy OpenGL and modern opengl quite a bit, and commenting on what parts are wrong would take more time then i have at the minute, can i suggest reading through learnopengl.com It is a great starting point and talks through most if not all issues you are seeing - even if you want to get your own program running and carry on with those tutorials - just have a look at the hello triangle page, and it will show you how to correctly set up your buffers and render to the screen
  7. My first post was probably something similar, although Ive never had much interest in MMO RPGs, it was probably a FPS or something along those lines. The same advice would have been given to me, and I also just shrugged my shoulders at the people, we all probably have. I'm not discouraging you. I, like most people here would like you to prove me wrong. I think when we all start we all have a little bit of a Expert Beginner complex. When i do see posts like yours, i always see them with a little fondness and nostalgia as like most of us its where my journey in gamedev started. The point of doing smaller projects is that you will learn these concepts quicker, and then build up to larger projects. Your code is like lego, you can reuse pieces and blocks of code in your project, but you need a strong base if you want to build something huge - its harder to go back and fix it after you realize the design was wrong from the start. This is all off topic from the original question, so I'm going to leave it at that and wish you all the best with your game.
  8. Im not sure its really discouragment, Once you are on these fourms long enough, even a few weeks, you will see a lot of people (weekly/monthly) who all have the same post, "I want to make an MMO RPG". People advise against this, and thats because it is a mammoth task, it could take 20/30 people years to make this type of game, and as 1 person you could be 20/30 years. While it is good to use something you are interested in to learn, what happens 99% percent of the time you will hit a road block, and become very discouraged very quickly, and a lot of people give up. Its not out of malice that people tell you not to do this, its from personal experience, and its echod here on a daily basis by professional people who work in the gaming industry. The advantage of doing smaller projects first, is that you hit more of these problems early on, and learn from them. When your touching on so many systems of an MMO RPG, its easy to just jump to some other part when you get stuck at something, you could spend weeks avoiding problems that you may already learn how to fix doing smaller projects. I respect the drive and willingness to learn and not give up, but to see your looking at server code, while in another post wasnt sure about what try{}catch{} are, and a few other posts about not understanding some language basics, Id compare this to learning to walk before you run, but an MMO RPG is more like several back to back marathons. I agree with the above, learn what you can on RPG maker, and when/if you outgrow it move on to the next stage. You will be more likely to stick with a project as long as you can see progress. And learn from your mistakes. Make as many as possible, The more mistakes you make, the more you will learn as to why they where mistakes
  9. I personally think that an RTS game would be quite a huge undertaken for you to take on, as a person who knows how to program, let alone for someone so young. Im not saying not to go for it, but maybe just start off on something smaller, and a little easier to keep interest levels up. I think rather then using a RTS engine like spring, you should look into using something like Unreal/Unity. They will show results quickly, and keep things more interesting, plus there are hundreds of tutorials etc for them, and will get usable experience for any other projects you may choose to do, 2d platformers/3d/whatever. Just even google unity/unreal RTS and you will see tutorials already available to help things along
  10. I don't really understand what your asking here, can you elaborate a little bit. When you say you want them to render every second, do you mean you want it to only update once a second? - this would be quite slow, ie a game running at 60 FPS would be rendering 60 frames every second. Or do you just mean you want something to constantly render? - which i assume it is doing whatever way you have set it up
  11. Thanks for sharing, ill add it to my list of things to read when i get the time :) Just at a quick glance, you have an error in your title: 'Requrements'
  12. Unity

      We can only hope, but I wouldn't hold my breath :) For every new system that comes out, there are people who like the challenge of breaking it, and usually eventually succeed   Happy coding, and good luck on your game ;)
  13. Unity

    As far as piracy is concerned, I wouldn't give it a second thought - All games eventually get cracked, so it becomes a lot of wasted time trying to stop it. You could put months into it - just to delay the game being cracked by days/weeks. That time is better spent improving your game, and making it more likely to be paid for. People buy good games, and people always crack games, you will not stop this - just think of the resources that a company like steam would put into this, and how trivially these games are broken. I understand why you wouldnt want your game to be stolen, but put the effort into first completing the game, and then just add something trivial to just not make it too easy to crack in at the end
  14. I dont think that each level here would need its own state, if you simplify this down abit, you can have an intro state - a menu state - a game state and a pause state.   The game state itself is what will actually handle the game side of these, including which level to load and render etc. I think having all these levels on seperate states like you can see adds a lot of bloat and complication to the design.   It could do something like the following   BaseState {      void Load();      void Update();      void Render(); };   GameState : BaseState::Load() {      if( currentLevel == 0 )            // Load the levels settings }   GameState : BaseState::Update() {      this->currentLevel->Update(); }   GameState : BaseState::Render() {      this->currentLevel->Render(); }   This is obviously a very basic example, maybe someone has more time to better explain this ( or tell me im completly wrong )   Have a look at this tutorial ( Great reference for a lot of things ) http://gameprogrammingpatterns.com/command.html Altough not about states per say - it will show methods of passing and using paramaters like you have mentioned. Another example on this site are states http://gameprogrammingpatterns.com/state.html :) Just read it all, its a very imforative website, and explains alot well and in a fun way
  15. Id also just recomend researching the scanner for compatability, I have only one experience with this - where i had spent money on a scanner - to find out it didnt run on any of the latest versions of windows for whatever bizarre reason, and as the company had closed down - were given no support for the device / drivers.   Im sure there was someway to make this work, but after being dishearthned at every beep of the scanner I gave up quickly :)