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

PragmaOnce

Members
  • Content count

    41
  • Joined

  • Last visited

Community Reputation

755 Good

About PragmaOnce

  • Rank
    Member

Personal Information

  • Location
    South Africa
  1. Although these are very cool mechanics it has already been used in a game that was created for a ludum dare in 2012. Check this out Well it uses the principle of perspectives but it doesn't go as far into portals and what not :p    http://www.youtube.com/watch?v=_sJPufr0qmI
  2. Well, when I started with Unity I also only knew C++. You'll find that the syntax is almost exactly like C++. So instead of learning C#, do the tutorials and get familiar with the syntax but focus your efforts towards understanding the Unity API. Because the majority of your programming will be based on functions/variables that already exist within Unity.   Goodluck
  3. The projects on the unity page are quite nice to work through. The first one touches on some of the basic concepts and the third one goes into more advanced coding techniques.    http://unity3d.com/learn/tutorials/projects   There is also a manual that explains the theory behind unity concepts and a reference guide that can be used to check functions and search for a specific behavior etc.   http://unity3d.com/learn/documentation
  4.   It really depends. There are API's like Box2D and Bullet that you could use to implement physics or you could code it yourself. When it comes to implementing physics you generally have two aspects to look at. Detecting a collision and resolving the collision. Now before you can start with your 3D physics you're going to need to do 2D.    Now there are thousands of ways to to implement a physics engine and even more ways to optimize them. I am not too experienced when it comes to physics and I don't want to give advice that is above my skillset so I will provide you with some links that I have used to implement physics. Most of the material is the same but covered in another way or maybe with more details, by studying all of these you'll hopefully be able to understand how a possible implementation could look.  Hope it helps.    http://gamedevelopment.tutsplus.com/tutorials/collision-detection-with-the-separating-axis-theorem--gamedev-169 http://gamedevelopment.tutsplus.com/tutorials/create-custom-2d-physics-engine-aabb-circle-impulse-resolution--gamedev-6331 http://www.wildbunny.co.uk/blog/2011/04/06/physics-engines-for-dummies/ http://www.wildbunny.co.uk/blog/2011/12/14/how-to-make-a-2d-platform-game-part-2-collision-detection/   A lot of theory: http://buildnewgames.com/gamephysics/   As I said earlier the key thing is to do a lot of research, whenever you find a nice website/link. Bookmark it so that you can come back to it later.   EDIT:   Also, to really understand these you are going to need to be familiar with vector math: http://www.wildbunny.co.uk/blog/vector-maths-a-primer-for-games-programmers/vector/#Magnitude
  5. Firstly you are talking about two completely different disciplines found in game development: A programmer and a 3D artist. I am no artist so I won't be able to help you regarding the 3D modelling, but you need to decide what you are going to focus on. I am a programmer so I can give you some advice from my perspective.   Making a game engine without any previous experience will be more of a learning experience rather than actually finishing it and developing a game in it. If you want to improve as a programmer and love solving complex problems while maintaining a good architecture try and make your own game engine, BUT if your goal is to actually develop a game then using an existing engine is probably your best option. The reason I say this is because learning about all the different implementations, systems and methods in a game engine is a very long process and can be quite daunting to new programmers. However, since you specifically asked how to implement your own engine I will provide possible steps to take concerning both processes.   Using an existing engine:   One of the best free engines out there (opinion)  is Unity. With the new iteration (4.3) it is not only a 3D engine but allows users to easily make 2D games as well. The nice thing about unity is that all the complex math and physics are already done for you so you can focus on gameplay elements. You can also build your games for multiple platforms.  The scripting languages you can use are C#, Javascript or Boo (the syntax is a lot like python).   There are a lot of other engines to choose from so doing a quick search on google will get you far.    Creating a custom engine:   The thing about game engines are that you won't find a tutorial anywhere that goes step by step in implementation, so a lot of research is involved. By researching modular systems found in a game engine you can learn more about the implementation of such a system.    Now there are a lot of engine systems that are not that important for a basic engine, for example: a memory management system. So without further ado here are some of the more critical systems found in a game engine:   - Input manager: You need some way to convert input from the user into logic that the rest of the engine can understand. - Rendering engine: This is the system responsible for drawing all your objects, an API like OpenGL or DirectX is used to do low level communication with the hardware. - Physics engine: Responsible for detecting and resolving collisions.    Now those are only the critical parts, you will maybe need a event/messaging system so that your different systems can stay decoupled, or a interpreter if you want a scripting system. I can go on, and on for quite a long time discussing resource mangers and state management systems but as I said those are all research topics.   Steps in the right direction:   If you are set on creating a engine the first thing you will want to do is learn an object orientated language like C++ and master it. You want to make sure that you understand inheritance and polymorphism as well as knowing your object orientated design principles.    Then start creating your own games using a library like SFML. Note that I said games, not game engines. SFML is nice because it already contains a rendering engine, input manager and various other systems that are useful for creating games without diving to deep into various systems. This will get you acquainted with main game loops and object hierarchies.    The one thing that SFML lacks is a physics engine. So your next step could be to implement a very basic physics engine that detects AABB (basically a box around an object) and then resolves it.    As your projects grow in size you might feel overwhelmed because everything feels like a big blob of code with new bugs popping up after every feature. This is a good indication that you need to start investing time in design patterns. These patterns are there to solve problems that occur a lot when programming in an object orientated language.    After a while a game engine will actually evolve out of your games (or this is how it worked with me!). But the thing is, as you dive deeper into the various systems it takes a lot more time to actually get something done. Remember, you actually get programmers that are "specialized" in a certain field like physics or graphics. For a single programmer to learn techniques spreading over multiple domains takes a s***load of time and dedication. The thing is I love game architecture and implementing all of the different features but because it takes so long I divide my time between making an engine and actually making a game. 2-4 hours a day I will spend on my engine and 2 hours I will work on a actual game inside Unity.   I hope I helped a little bit and remember this forum has great resources and a nice community if you ever get stuck on something. Happy devving   EDIT: I gave very vague steps on how to start with a game engine. Shoot me a message at anytime if you want to know about more concrete steps you could take, this is of course after you mastered an OOP language
  6. Just an update..   I finally got the pen. It's working, but I can't do anything with it The pen has the ability to move the cursor over the screen but only if i'm actually touching the pad or if it is literally 1 mm above the tablet. There is also no clicking/drawing.. So the full functionality of the pen is to move the cursor across the screen.   The funny thing is, windows keeps on installing a generic driver for the tablet. Even after disabling signature verification (just in case the driver is too old) it still goes and bloody installs its generic version. That might be the problem,I don't know. But I don't think I could fix it if I wanted to.
  7. Well, something like this in the update loop could work: const int reactionRange = 600; // IF the ball is near the paddle and moving towards the paddle if ((ballY - getPosition().y <= reactionRange) && (ballDir >= 90 && ballDir <= 270)) { // If the ball is a little to the left of the paddle, move left if (ballX <= getPosition().x+30) { movement.ChangeSpeed(8); movement.ChangeDirection(90); } // If the ball is a little to the right of the paddle, move right else if (ballX >= getPosition().x + getLocalBounds().width - 30) { movement.ChangeDirection(270); movement.ChangeSpeed(8); } // Else the ball is between the paddle ends, and there is no need to move else movement.ChangeSpeed(0); } With this approach there are a few things that you can do to change the difficulty of the AI. You can change the reactionRange so that the paddle begins moving earlier. Or change the speed of the paddle. This is still extremely basic but it should serve as a base for more extensive decisions.   EDIT: Damn, I just realized that I created code for a paddle moving left to right.. But just convert it to up/down. Sorry. 
  8. Because currently the Explode function does not exist :/ I have a tendency to go into a "What if.. " mindset when programming. I could even make an EXPLOSION_EVENT with those parameters and make the scene register to it. That way the scene will handle the explosion and my entities are oblivious to the world they are in.   Basically, i'm just scared that at some or other point my Entities are going to need something and my scene class is "global" enough to be able to respond to anything the Entities might want. But... now that I really think about it, events will be able to keep things together. If not, then I guess i'll have to do some refactoring.   It's really hard for me to plan things out because I am afraid of having to refactor. I know code is not supposed to be completely set in stone but I can't stop myself from being over cautious to eliminate the chances of redoing something. 
  9.   One small thing about #pragma once is that it's technically not part of the standard, and though it's widely supported (I don't think I've ever seen a compiler that doesn't support it) people will often use include guards after the #pragma once, just in case #pragma once isn't supported.     Yes, I know it's only a directive for compilers. Since I am a mere novice, working alone, on a project that no one else will see... I figured that if my compiler supports it, it reduces the chance of bugs, and does not involve as much typing :p       Since the topic appeared to be circular dependency, making a note about using guards or #pragma once would have contributed to the understanding, as that tends to be one portion of usual circular dependency issues.     Ah I see, forgive my lack of experience. I didn't realize that it could cause dependency issues. Thank you :)
  10.   I use #pragma once. I didn't include it with my examples because it has nothing to do with the problem at hand. Those classes are actually filled with members and methods but I thought I would leave out any code that has nothing to do with the circular dependency, to make the problem easier for others to understand.   Because the Scene is going to hold the list of entities found in a particular level. I was thinking I might need it later to implement some logic, for example: // Inside explosion_object, this is purely psuedo Explode() {     scene.ObjectList.findObjectsInSphere(DamageRadius,variableToStoreObjects) } Why is that,  please elaborate?   Thanks for the tip on forward declarations. I have read about them but I always thought it was bad practice to do it, but if you say it's fairly common I guess it's a solution
  11. Hi guys.   So whenever I try to make a game I run into a problem where a circular dependency occurs between the scene or level holding my game objects and the game objects that need access to the level. I am sure this can be easily solved because my architecture is structured wrong but I just can't seem to think of an efficient solution. I'll roughly show what I have (just the parts that are causing the dependency).   Scene.h #include "ObjectList.h"   class Scene : public EventListener { public: ObjectList objectList; // This holds all the entities that are currently active in a particular scene/level. }; ObjectList.h #include "Entity"   class ObjectList { private: std::vector<Entity*> objectList; }; Entity.h #include "Scene.h"   class Entity : public sf::Sprite, public EventListener { protected: Scene *gameWorld; };
  12. Hi there.     Are you talking about the fact that the player isn't buffered correctly. I used a pink square as my "you sprite". This line you are talking about is probably what Eck has mentioned. Now I am not familiar with python/pygame (remember I downloaded it last time to help you ) but..   I'd say you call this after updating display: pygame.display.flip()   Also, put your code in code blocks next time to it's easier for other people to help you. Just click on the < > button that appears in the editor menu and paste your code in there, selecting the generic code option.   EDIT: That didn't work, i'll check what other functions are available ^^ Found the problem : You need to fill the screen with a color after you draw to it to "reset" it basically. So right after you do your display.update, add this:  screen.fill(pygame.Color(0, 0, 0, 255)) This just fills the room with black. 
  13. Thanks a lot!   The monoprice pen was exactly the kind of thing I was hoping to see. I am definitely going to take risk in buying it but i'd say it is worth it... what's the point of having a tablet if you can't do anything with it. Plus the reviews seem to indicate that I have a good chance of it actually working :)
  14. I'm not an artist so I won't know anything about your technical implementation :p thus from a outsiders perspective.. these look really good! I especially like the mushroom and the wolf scenes.   The fallout converse also look very good and professional. Keep it up :)
  15. Hey guys.   Firstly let me start off by saying that I am by no means an artist, I just like drawing every now and then. I have this really old tablet that my father gave me that he found at work or something but I've managed to lose the stylus.   The type is a genius G-Pen M712X, the only way I can see to get the stylus is ordering from the genius shop online. The problem  is they don't ship to South Africa. I've searched Ebay/Amazon and nearly all those sites but I can't find a way to get the stylus.   So my question would be, will another stylus work? I know the pen has 1024 different pressure levels so would another stylus with the same specs work? Sorry if this question sounds completely stupid but I have no idea how tablets work :/