PocketMatrix

Hi Eric,

I like this book. Try to read this book : Isometric Game Programming with DirectX 7.0 Here's the link from Barnes and Noble.

You might pick up something from this

Hi!

Thanks for the replies.

denthorq: I have also read that book by Andre LaMothe. Well, I have read parts of it, since I'm pretty used to DirectX, and DX7 is not really state of the art. But I indeed picked up a few things from that book. The "tricks of the windows gurus" 1 & 2 are also incredibly packed with great infos for 2D and 3D graphics.

mlepage: Thanks. To better describe what I need to design... We currently are 2 persons working on the design. We currently have all the game elements listed. We have the basic ideas of how they operate together. We have the gameflow and screens listed.

I feel very uneasy starting to work on programming related stuff like classes. For one, the other person working with me knows nothing about programming and I don't want to repeat the mistakes of my last projects, for which I went directly to programming at this stage.

I'm absolutely cluesless at how I should evolve the design document into some kind of design structure that I could follow for implementation. And more importantly, something I could show my partner and that he could understand, kind of a roadmap I can follow and update during development.

The game is a simulation. It has an economy (income and expenses) and various type of (micro/macro) management of assets. There are also computer controlled "opponents" that compete to win the game.

I've been thinking about taking the big elements of the game (the players, AI, economy, etc) laying them out, then dividing them into smaller and smaller blocks until I can get to small enough blocks that I can "connect" them together with the gameflow and lay out some general classes and such. Hopefully achieving a "map" of what needs to be done in term of general programming, and something others can review and unserstand.

This is the first time ever that we try to define this intermediate step in development, the link between the design document and the actual programming work. We've spent lots of time on this and we're still not satisfied and/or getting anywhere.

I had to spend some time writing this reply and it helped me see more clearly the step I need to properly define, that is the link between design doc and programming.

I look forward for your comments, sorry for the length of this post!

Thanks,

--Eric

My humble opinion :

Nothing is more valuable than experience and design methodologies are just a way to fake experience.

It's good to read books but reading them without experimenting by yourself will not transform you into a guru.

Hi,

Stéphane: I totally agree with you that it's pointless to just read and read and try to "emulate" what other people do, without trying it for ourselves.

I also think that many books express some people's experience; and some pieces of information, gathered here and there, can benefit many developper.

Thierry: I think that the term "development process" better describe what I'm after. I'm not really after one way of doing everything, but rather a way to look at things to better plan the work to be done.

Thanks for the link, I'll review that right away!

--Eric