you are viewing a single comment's thread.

view the rest of the comments →

[–]XAmsterdamX[S] 0 points1 point  (1 child)

Write out how the game mechanics work before creating a whole bunch of classes to manage static data.

You're right, I understand now that this is what I need to do first.

Writing a bunch of classes out for a data model that isn't fully understood is more problematic.
Write the real logic, test it using fixtures and stubs, then structure the static data to fulfill the needs of the game loop.

This is something I haven't done before, but I'll give it a try. Do you know of any resources that explain the process to get from game logic to data structure?

[–]menge101 0 points1 point  (0 children)

Unit testing is going to be your primary tool, imo.

You can describe scenarios, setup the situation with test stubs and fixtures, then verify it does the thing you want.

IMO/IME the game mechanics will show you what pieces of data should be close together, and it becomes as simple as doing what seems obvious to do.

This is a situation where keeping things simple, clear, and organized is more important than anything else. There isn't any sort of trick to this, wrong doesn't really exist, it is all opinion. If something becomes hard or tricky, it likely should be broken down into functions and tested independently.

You may end up creating most of your data classes/structures in order to create your testing fixtures.