I'm a self teaching beginner, and I know absolutely nothing about the technical specs of computers/programming in general. I am using a C# book to learn it, and I mainly just want to learn everything that relates to game development, if something has no part in game development/no use in it. I won't bother learning it for the time being. All I currently need to know is, does SQL have use when it comes to game programming?
views:
190answers:
5
+1
A:
It depends on how you plan on persisting data after the user closes the program. There are a lot of options, so SQL may be a good way to handle it, and it may not. This is, of course, assuming that you want to save data between game play sessions. There are so many options out there that you may never use SQL.
(That's an understatement).
Outside of game programming, if you're a developer you will likely need to know SQL. I'd recommend learning it. Even if you don't use it in your game design, knowing the concepts will help you.
David Stratton
2010-03-07 16:13:06
+4
A:
Perhaps SQLite where the overheads are minimal, but unless you need the indexing (fast access) and lots of storage it would be better for roll your own as SQL Server itself is overkill and heavy on system resources, not something you'd want running alongside your game.
In summary, I would say no, SQL does not normally have a place in game design (client side stuff anyway).
Ryan ONeill
2010-03-07 16:15:34
+1 for mentioning SQLite which I do believe has good uses in game development.
Ricket
2010-03-08 02:08:02
+5
A:
99% of the time, no.
SQL is used for storing and retrieving large amounts of data quickly and efficiently. Think of a database as a filing cabinet (or usually a room full of filing cabinets) and SQL as an ultra efficient filing clerk!
If your game needs to store and retrieve lots of data (maybe a highly complex strategy game for example) then the answer may swap to yes, but on the list of things to study I would put it waaaay down.
If you do need to store settings etc. from your game you're better off
- storing it in the system registry, if the amount of data is tiny
- storing it in the application settings file of your app
- storing it in a text/binary file next to your game executable
CResults
2010-03-07 16:16:01
Although many games do it, it is bad practice to store settings in the same folder as the executable, and has been so for many, many years. Stuff you need to change (settings, save games, etc.) should go in Application Data or possibly the registry.
Michael Madsen
2010-03-07 16:19:18
And for those times when you need SQL, SQLite is probably a better solution. And since we're talking about C#, learning SQL is probably not useful, since you can just write your queries in LINQ.
Travis Gockel
2010-03-07 16:27:12
Also, @Geno: Learn Linq, and learn it well (also lambdas). It will shave tons of time off of development. For prototyping, you don't even have to bother with using libraries and doing it "properly," you can just use Linq for everything you need sorting for (collision detection, enemy finding, spacial sorting, whatever).
Travis Gockel
2010-03-07 16:32:13
Sql Server Embedded (aka CE aka Compact) is a good version to use in applications for storing lots of data, as it provides the efficiency of sql data storage and retrieval without requiring an additional install or the sql application service to be running on the client machine.
Will
2010-03-07 17:14:21
Rather sweeping generalisation - how do you know that games dev doesn't use SQL, on what evidence are you basing it?
zebrabox
2010-03-08 12:19:05
:-) @zebrabox. I get what you are saying and perhaps on reflection my answer is sweeping. However, it was aimed @Geno who has only just started off in programming and needs to be able to focus on the basics. I write desktop/web applications for a living and the large majority that I write, from 10-liners to full apps use SQL. However, of the handful of games I've written none use SQL. I note you work for SCE, balance my answer up; How many games have you been involved in that use SQL (not just a data-store, full blown SQL). This is a genuine interest, not a rebuttal
CResults
2010-03-09 09:34:40
@CResults - Not sure what you mean by 'not just a data-store, full blown SQL'
zebrabox
2010-03-09 12:51:03
@zebrabox I mean not just a binary file/text file but querying/storing your game data with SQL
CResults
2010-03-09 13:04:37
@CResults - Very hard to answer in general - it will depend on the requirements for the game title but I'd say that it's becoming increasingly common as the complexity of modern titles increases. It's also worth making a distinction between runtime and development tools. The runtime may use SQL for the reasons I just mentioned though on consoles this will be an embedded DB engine such as SQLite. Development tools are much more likely use SQL in some form for asset management, profiling, tracking etc
zebrabox
2010-03-09 17:52:16
+1
A:
Most games have high performance requirements, where loading times are predictible and it is possible to have fine grained controlled over when and how data is loaded. Unfortunately that is not what a general storage engine like sql database offers, so most games use their own storage in binary files.
Any ways, if you want to learn programming focusing on one thing at a time is probably best in the beginning so my suggestion is to keep focused on C# and when you feel you can do at least basic things there, you can broaden your perspective.
Anders Abel
2010-03-07 16:26:00
+1
A:
Online games almost always use SQL on the back end for the persistent world, player accounts, etc. (Though there are exceptions.)
Single player games or games with no persistent world almost universally do nothing with relational databases at all (although again, there are exceptions, often involving SQLite.)
.NET is sort of an irrelevant issue because only hardly any commercial games are written using .NET, and if you're asking about hobbyist games then it's impossible really to say what people have done at home.
Kylotan
2010-03-10 10:44:49