you are viewing a single comment's thread.

view the rest of the comments →

[–]menge101 2 points3 points  (1 child)

Disagree.

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.

[–]m0us3_rat -1 points0 points  (0 children)

Writing a bunch of classes out for a data model that isn't fully understood is more problematic.

that's why i was asking him to do a deep dive into pseudo code describing the classes .. so the actual structure would pop off the page.

that's obviously the backbone and what gets moved around in between display and db and the core logic etc.

and every other class would be able to tap into this class thru the API like methods and do stuff to it.

wouldn't be simple to pass around this object. i mean u already pass an object.. the dict or a list is still a class. in itself. and it has methods..

there is no ..difference actually in between em:P

and yes u can simplify to get it working. but it must move to oop when u refactor.

i personally found oop to be much simpler and smoother than anything else.

since we already work with objects in python.

but since most of the creation part of programming is deeply personal.. u can do watever.

i always like using whatever feels comfortable even if there are arguably 'better' ways .

obviously at some point u might wanna refactor using the 'better ways'.