Game Development Question - Data storage
 

Hey You Guys!!

I'm trying to develop a text game and having trouble with windows 7 64bit.

Could someone tell me a compatible data source to use with this OS and

since I'm trying to sell it, maybe recommend open source or something similar.

Also, I wonder what type of data storage other indy developers use.

thanks,

JJ

Pretty interesting to read what I wrote about programming 6 1/2 years ago and compare it to how differently I do things now (interesting to me anyway). (Edit: I still use binary files, though. Although I have thought about going to just using text files like the Paradox games)

If using C#, there is SQLServer compact available, no server or anything just reads/writes a standalone file. You could also look into SQLite for C++ or other development.

Or just write your own binary file reader/writer.

I am assuming you are using C++ since your having this issue on a 64 bit operating system. If so, you got a real nasty booger on your hands. The issue has to do with overflow of primitive data types I believe. I think this is reason that FM does not support 64bit operating systems at this time. For a code base that size, I am guessing it is going to take years to overhaul and test it.

FM certainly runs on 64 bit Windows 7. I have run the last 3 versions without using compatibility mode.

If you've been careful with compiler warnings (i.e., don't turn them off simply because they nag at you) over the years, it's not much of an issue.

The problems start when you're sloppy about type definitions. Don't use integers as pointers, then ignore compiler warnings. With 64-bit, that's a bug.

If you have a lot of custom typedefs, you might be inviting trouble.

While an integer isn't always what you think of as an integer, generally performance improves as the operating system improves. If you're counting on an integer being 32 bits, though, you're setting yourself up for an unpleasant surprise.

When writing a program I would heartily suggest ALWAYS writing it 'platform neutral' and abstracting as much as possible - not just in terms of the actual code functionality (ie. functions to open a file for instance) but also the typing you use.

For instance all programs I write have a section where I typedef out all the basic fundamental coding types so they can be effectively 'platform neutral' as needed.

for instance:

This approach makes it far simpler when it comes to moving between 16, 32, 64, 128 bit or whatever platforms if you want to retain save game compatibility between them because if you so desire you can keep all variables the same size on each by simply ensuring your definitions are appropriate for the type.

(these days its fairly commonplace not to refer to say an 'int' any more in code but to have a typedef used as INT32 or whatever to indicate the size for it ..)

This approach is also useful for the same reasons for saving on different endian systems - if you wrap things into a 'platform neutral' read/write function then you can hide the swapping of bytes in your platform layer and effectively ignore the endianness of the platform when you write the game code.

(if you want to be bored about this sort of stuff drop me a PM, I've been writing cross platform products longer than I care to remember ;) )

Finally I'd echo Solecismic's comments about trying to be overly clever in code - don't rely on anything from a specific platform whether its how pointers operate or how a class lies out in memory, that sort of thing WILL bite you in the butt at some point otherwise ...

Actually I tend to do:


Better to have the bitsizes in the type names, and save CHAR for an actual character, not a number you store stuff in. But I agree wholeheartedly with the point, it's much easier to change the definition of INT16 for a particular compiler / platform than fix all your usage of INT because you moved to 64-bit or something.