Jump to content

  • Log In with Google      Sign In   
  • Create Account

Interested in a FREE copy of HTML5 game maker Construct 2?

We'll be giving away three Personal Edition licences in next Tuesday's GDNet Direct email newsletter!

Sign up from the right-hand sidebar on our homepage and read Tuesday's newsletter for details!


We're also offering banner ads on our site from just $5! 1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


PragmaOnce

Member Since 01 Apr 2013
Offline Last Active Nov 15 2014 11:05 AM

Posts I've Made

In Topic: The most innovative development in First Person Play I've ever seen...

10 January 2014 - 10:39 AM

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 smile.png

Well it uses the principle of perspectives but it doesn't go as far into portals and what not :P 

 


In Topic: scripting and unity3D

06 January 2014 - 12:50 PM

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 smile.png


In Topic: scripting and unity3D

06 January 2014 - 12:03 PM

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


In Topic: Learning 3D and physics.

05 January 2014 - 11:08 AM

Wow! Thanks for the long and detailed answer!

Since I am not interested into making a game (ie: campaign, story, etc) I think that I'll try to make my very own engine. I already know OOP but I have no idea how to implement physics. Do I need some extra libraries/APIs/Tools or is it all about coding?

 

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


In Topic: Learning 3D and physics.

05 January 2014 - 10:44 AM

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 smile.png

 

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


PARTNERS