Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 28 Nov 2010
Offline Last Active Oct 19 2016 03:48 AM

#5183266 Optimization philosophy and what to do when performance doesn't cut it?

Posted by on 27 September 2014 - 03:57 AM

I dislike the way the "premature optimisation.." quote is misused, and quoted without the benefit of its original context. 


I take the quote to have 2 meanings:

  1. Get the code working first then worry about optimising.
  2. Don't rush into optimisation without profiling the code first.

The benefit of #1 is that you can keep your working, reference implementation and ensure the output of your optimised version is still working correctly. And #2 gives you the best bang for buck, since as developers, our time is precious. 

#5177539 Did I begin learning late?

Posted by on 01 September 2014 - 06:32 PM

In many respects you're lucky you can start so early! Python only came to my attention in the last few years, and I'm in my 30's.

#5172556 Getting started

Posted by on 09 August 2014 - 11:30 PM

The best advice I can offer is to start simple and practise often. There's no quick way to gain the knowledge you need, the reality is that you'll have to put in the time and build up your skills by trying projects of increasing complexity.


The choice of game engine is far less important.

#5157279 2D physics in a game.

Posted by on 01 June 2014 - 02:36 AM

Game physics is something that only works correctly if you update it at a constant, predictable rate, independent of the rate you're rendering to the screen. The way this is commonly achieved is to define how often you want to update your physics, eg, 20 times a second, and then calculate the elapsed time between each rendering frame. Accumulate that over several frames until you reach 1/20th of a second, then do a physics update, using 1/20th of a second as your time parameter in all your physics equations. This means that your physics updates are all done with the same time difference (or delta), and they happen predictably, which means the motion of your objects will be smooth.


I highly recommend you check out "Fix your timestep!", the seminal work on the topic.

#5157098 2D physics in a game.

Posted by on 30 May 2014 - 10:50 PM

Typically, you'd apply a force to an object, which would cause that object to accelerate. Over time, acceleration alters the object's velocity. Over time, velocity alters the object's position.


Force, Acceleration, Velocity, Position and Time. Those are the 5 things you need to worry about. If however, you also want your object to rotate, then you have Torque, Angular acceleration, Angular velocity and Orientation to worry about.


Though it seems like 2D physics should be pretty easy compared to 3D physics, the concepts are actually the same, but some of the formulae are simpler since they involve one less dimension. 


I wrote a simple 2D physics engine in C# about 4 years ago, and Chris Hecker's articles on rigid body dynamics were an invaluable resource.


#5149852 Random map with prebuild pieces

Posted by on 27 April 2014 - 07:40 AM

One approach I've seen is to first generate the rooms without any doors or corridors between them. Then you go through a second pass adding doors to each room to connect them all to each other. Larger rooms could be allowed more doors, and you could easily verify how many dead ends you have by looking at rooms with only one connecting door.


I can't find the link right now, but I recall seeing a presentation on Path of Exile's random dungeon generation, where they place a Start room, an end Room and then a room in the very middle of the map. Then they randomly add rooms and doors using a similar technique I mentioned above, but ensuring that there's a path from the start room to the middle room, and then the middle room to the end room. This ensures the overall network of rooms is linear, which is better for guiding the player.


Another interesting technique is described here: http://www.reddit.com/r/gamedev/comments/1dlwc4/procedural_dungeon_generation_algorithm_explained/

That might be more complex than you're after, but it could give you some ideas. 

#5148106 How to stop users from manipulating Game Save Data

Posted by on 19 April 2014 - 05:54 AM

For a non-online game It is impossible to prevent a dedicated, intelligent individual from altering your game files.


You can discourage a high proportion of players by making it difficult to do so. However, the dedicated and intelligent will figure out what you did and circumvent it. Guaranteed.


Its a matter of diminishing returns. Do nothing, and anyone that is curious can look in the game folder and make whatever changes they feel like. Hiding the files or obfuscating them in some way will eliminate some of those but not all. Its an unwinnable battle. The question you have to ask yourself is how much time are you willing to spend on it, and could I instead invest that time in making the game better?


With that in mind, something simple like computing an MD5 hash of the file and storing it in code somewhere will take care of the majority of users. But, I'd advise against it.


The game project I'm currently working on is likely going to ship with all of its game data files as plain text with non obfuscated key/value pairs. Why? Two reasons:

  1. The game isn't directly competitive, so "cheating" doesn't affect anyone else. 
  2. I want to encourage people to make (and share) interesting mods I wouldn't have thought of myself. 

#5147751 Component Entity and Data-Orientated Design

Posted by on 17 April 2014 - 04:35 PM

Some interesting viewpoints in this post. I am at the tail end of converting my entire project from traditional OO-inheritance to component-entity, and my primary reason for doing so has nothing to do with speed or performance. I ran afoul of the diamond problem and the codebase was getting ridiculously complicated. Special cases hardcoded everywhere to handle unrelated entities having similar properties... yuck


If well implemented, CE systems can be slightly faster, yes. But certainly for me, better code organisation and partitioning of data was *the* reason for the switch.

#5120378 Why XML is all the rage now?

Posted by on 31 December 2013 - 04:45 PM

I consider XML to be in the same category as COLLADA. ie, designed to reliably convey data between different systems, and nothing else.

  • They are both text-based and inefficient at storing data when compared to binary formats.
  • They can have complex structures that lead to slow parsing especially on larger files.
  • Despite what people say (and the original design intention), XML is absolutely not human readable.

The only difference I see is that people realised what COLLADA was intended for and treated it accordingly, whereas XML was (and still is) abused.


I've worked on a project where the original authors thought it would be a good idea to create an entire XML document on the fly using string concatentation, pass it to a stored procedure and query it as a table to pull out a few parameters.


Guess what brought down the entire system?... "&".


Granted, that's not XML's fault, but still...

#5115017 Bullet physics undefined behavior with a dummy simulation

Posted by on 06 December 2013 - 08:34 PM

Isn't it generally considered a bad idea to explicitly set an objects velocity in a physics engine? I've always read that you should apply an appropriate force instead.

#5106163 Dividing by zero, on purpose

Posted by on 31 October 2013 - 11:25 PM

If I'm about to head home for the day and I'm working on a piece of code that is incomplete but compilable, I'll type some garbage like: "dgsahjgda". That way when I come back to it in the morning If I forget where I was up to, it'll take me straight to the garbage when I try to compile. 


I'll do the same if I'm doing some manual refactoring involving a lot of copy and pasting.

#5068407 Models are missing half their triangles.

Posted by on 09 June 2013 - 07:32 AM

The OBJ format is deceptive. It's pretty quick to write a parser for it, but it has plenty of gotchas, such as only being suitable for static meshes, since it has no support for bones or keyframes. Nor can it store what the X, Y and Z axes actually correspond to it, it's purely up to the exporting application, and a major headache if you're sourcing models from artists that use different 3d modellers.


I started with .OBJ, but more recently switched to a combination of COLLADA (exported from blender) and a custom binary format of my own making (created from the COLLADA file at build time), and I don't regret it for a second.

#5046083 Why is my Rotation not centered?

Posted by on 23 March 2013 - 05:11 PM

Unless there's some matrix multiplication order difference between OpenGL and DirectX I'm not aware of, the construction of your MVP matrix seems backwards. Shouldn't it be mModel * mView * mProjection?


Similarly, to construct your mModel matrix, I believe the order of transforms should be (SRT) Scaling, Rotation, Translation. 

#5043550 Am I a bad programmer?

Posted by on 15 March 2013 - 06:05 PM

A bad programmer is unwilling to learn and develop their craft. An inexperienced programmer is new to the craft. These are not the same.


I disagree with the mentality that you should be an expert in your field before offering advice or tutorials. Sharing information, (even small snippets) to help others get started is a key way of distributing knowledge in communities. Though, if you're going to offer advice, its your responsibility to amend that information if you discover it is wrong or "not the done thing".


Trying to teach other people what you know (especially through some sort of peer-reviewed process), is the surest way of finding out what you *really* know about a topic, as opposed to what you *think* you know.


I cannot fault the OP's attempts to pass information on. Even experts get started by reading someone else's tutorials.

#5033665 What exactly is paid for when making games?

Posted by on 18 February 2013 - 02:08 AM

Remember that games studios are still businesses at the end of the day, and unless you're in some ridiculous high rent location and have token staff, the biggest cost by a long margin is going to be people's salaries.