this post was submitted on 23 May 2026
7 points (88.9% liked)

Learn Programming

2197 readers
1 users here now

Posting Etiquette

  1. Ask the main part of your question in the title. This should be concise but informative.

  2. Provide everything up front. Don't make people fish for more details in the comments. Provide background information and examples.

  3. Be present for follow up questions. Don't ask for help and run away. Stick around to answer questions and provide more details.

  4. Ask about the problem you're trying to solve. Don't focus too much on debugging your exact solution, as you may be going down the wrong path. Include as much information as you can about what you ultimately are trying to achieve. See more on this here: https://xyproblem.info/

Icon base by Delapouite under CC BY 3.0 with modifications to add a gradient

founded 3 years ago
MODERATORS
 

I want to preface this by saying that I think I got cooked by AI here.

I have a game where I am working on a job system. The job system has a job objects which I need to put into a data structure that can be searched via id, location, or work type. At first I was building with the mindset of "do whatever to solve this problem and make it work" but it became very hard to implement new features because I would break everything. So I started trying to think ahead and design ways of doing things that would handle all the different jobs and things.

At first I put all jobs into an array and iterated through. Then I learned about dictionaries and started using them for way to many things and so i updated my job queue to be a dictionary with the Key as ID > JobObj

Then I decided to plan out the job system before writing anything and "do it properly". I decided I needed to upgrade the data structure holding jobs because its a core part of the game and will be heavily interacted with. But I realized I only know array, dictionary and database, so I asked AI what data structure I should use and it suggested a nested dictionary.

Now im using multiple dictionaries but im really hating it. Its hard for me to work with and conceptually im not sure I can visualize how its even working.

How I am thinking about it is there is multiple layers of keys, 1st layer is work types, then once I find the work type it points to a dictionary of region IDs and that points to an array of jobs in the region.

Job def is work type like Planting Region id: the map is broken down into region IDs so i dont have to check every tile and can limit seaching

#python
var job_pool: Dictionary = {}

func register(designation: DesignationObj) -> void:
	var job_def = designation.job
	var region_id = designation.region_id
	if not job_pool.has(job_def):
		job_pool[job_def] = {} 
	if not job_pool[job_def].has(region_id):
		job_pool[job_def][region_id] = []
	job_pool[job_def][region_id].append(designation)

Here is how I am picturing it in my head.

var job_pool {
	"plants": {
		"1": {
			"job1"
			"job2"
		}
		"2": {
			"job3"
		}
	}
	"mining": {
		"1": {
			"job4"
			"job5"
		}
	}
	"hunting": {
		"5":{
			"job12"
		}
	}
}

But now I want to add ID look up into this im stuck and im thinking the entire structure does not work for what it needs to do.

you are viewing a single comment's thread
view the rest of the comments
[–] vk6flab@lemmy.radio 3 points 2 weeks ago* (last edited 2 weeks ago)

While databases have struck fear in the hearts of many developers, it's really just a structured way of storing (sometimes large amounts of) information.

From a naming perspective, a database is essentially a collection of tables, each of which you can think of as a simple list of rows, each row containing a collection of fields, each not unlike a single spreadsheet with a label at the top of each column.

Like a spreadsheet, you can decide what types of values are permitted in each field (column).

In spreadsheets you can refer to a row by its row number, which breaks down as soon as you sort a sheet, database tables can similarly be ordered, or not, depending on the requirements.

A query returns one or more rows as required.

You can relate two tables if you want to by having both tables have a field with the same definition and value, and then query the information together, linked by that common field. You can link many tables together if your data requires it.

For example, you might have a list of job types, with information that's specific to each job of that type. By storing those types in their own table, you don't need to duplicate the information for every single job stored in another table.

Essentially that's pretty much all there is to it.

If you get into bigger and more complex stuff, you'll come across a thing called an index, which tracks one or more field values across one or more tables, for the purpose of making retrieval faster, but until you hit a thousand rows, you're unlikely to need them.

Disclaimer: This is a summary of 40+ years of database experience and it's purposefully written to simplify concepts. It doesn't get into different database engines, but at this stage that likely won't matter much.

The underlying purpose of a database is to ensure data integrity, in other words, to make sure that a telephone field contains a telephone number and not an email address by accident. It's also intended to minimise the amount of data duplication and associated resource use, like memory, disk and network. Finally it provides mechanisms for multiple simultaneous users and associated conflicts.

Have fun!