doeme

The company I work for recently made the switch from Trac (free) to Jira (Paid; hosted or downloadable) which both can do what you describe in the OP. Trac needs a bit of customizing and some plugins and macros which can be a bit time-consuming until you get it right while Jira has it all inbuilt.

Trac was good for us for quite some time and it did the job until the dev-team got bigger, more projects came aboard and we generally needed to work and rely more on the issue-tracking and planning.

Jira is generally easier to use (especially for non-techies) as well as i has a already integrated "agile" mode which makes working with it easier and more fun. The close integration with the documentation-system "confluence" is also a pro. Said that Jira has its drawbacks most of all being slow and some quirks in the UI.

Considering the monthly fee one has to pay versus free software that is hosted inhouse a rough estimate of the ToC might be worth it. A free software package might be even more expensive in the end if you need to buy extra hardware to run it on and if you do the server maintenance yourself (getting less time on your projects) or hire somebody to do it for you.

When I think of the pro's, the experienced, the people who use their incredible skills of math and programming to make video games, I sometimes wonder, just how did they make it there? And knowing how they've made it there, just how good are they?

Most good programmers/software engineers I know are good in what they do, because they are very experienced in what they do. Which means, they have been doing it over and over again for a very long time, most of them can be considered professional programmers for at least 10 years. Also most of them started out at a young age with coding and did a lot of hobby-projects to constantly learn new things. But no matter how good they are, none of them started out without making bad mistakes and producing ugly software in their early years.

How good they are?

• They get complex software of high quality done and shipped in time on a regular basis.
• They can come up with good solutions in reasonable time for even the quirkiest problem.
• They hunt down bugs with fearsome accuracy and speed before breakfast, more often they spot said bugs before they take their toll.
• They write articles and books to teach other people on regular basis

I think I could go on quite a while on how good some of the guys are

If your biggest interest is to prevent players from mucking with your data or steal it or break their game, don't bother. They'll do that no matter what.

I agree with this, given enough time and effort all of your assets can be stolen. Despite since your tilemap will be visible on the screen nothing will prevent the user from taking screenshots anyways.

Also installing measures to prevent this soon will limit the ease of access to your product, which for relatively cheap mass-market products (like games) is generally a bad idea. Needing to enter a key, which is prone to be lost somewhere in your house soon gets to be a nuisance.

I develop surgical simulators for a living, and we encrypt some of our assets when creating an installer and our customers get a USB-Key (produced by a 3rd-Party vendor) which has to be plugged in to be able to decrypt and run the system. However this is far away from the cheap, mass-market product so the acceptance of the user is a bit better for stuff like this, as this also acts as a security, so there is little point in stealing the system.

Compiling your assets to a binary might still be a first step in preventing the users from just copying them, but I would set the primary goal there towards faster loading speed and not towards security. Consider discouraging the lazy and casual thief more as a nice side effect than anything else.

C0lumbo, on 11 Feb 2013 - 08:53, said:

Yeah, my guess would be something like array overruns or underruns on a stack array or something. I'd suggest:



1. See if you can repro it on an optimised build in the debugger.

2. I believe it's possible to attach the msvc debugger to a process that's already running.

3. printf debugging (I guess you'll need to print out to a file)



So how do I do #1 and #2? Especially #2

For #1: Build your solution/project in release mode and start it again from the visual studio. Depending on your configuration the release-mode might be called differntly. Just pick any mode which has no debug-information compiled and code-optimisation enabled.

For #2: You can debug any running process from Visual Studio over the menu "Debug" -> "Attach to Process"; However this has some pitfalls as well. See this article here (just the first one that came up on google) or Google it

This might be caused by variables or objects that are not initialized properly. These kind of bugs can be very hard to find if you do not have a clue where to start.

I'm guessing you are if running the exe from Visual Studio you are running it with the debugger enabled and in debug mode which might cause uninitialized memory to be set to a certain value. Check if the program behaves the same if run from VS without the debugger (CTRL+F5) or if your army goes missing as well.

As C0lumbo said, late attaching the debugger might help, as well as some logging.

I can't easily go back to a last saved version (I keep many) as I didn't notice this until about 2 weeks or more of work has been added... I just didn't notice, didn't run this test, was working on menus and other stuff...

This sounds like you don't use any versioning software like SVN, my advice here is  to start using something to track your changes better. Even if it's only running locally on your machine.