Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

Rocket05

Designing Interfaces

This topic is 5392 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

i''ve finally reached the stage where I realized that designing your programs extensivly before jumping into code makes for much more successful programs. I''ve been researching design patterns, UML, and other general software design techniques, but i''ve yet to find any information on desiging interfaces. Obviously, interfaces are usually very implementation specific, but I was wondering if there were any general techniques for realizing what all is needed, and how to pack that functionalilty into a handful of methods (something kind of like the is/has technique for desiging class inheritance/fields).

Share this post


Link to post
Share on other sites
Advertisement
One thing that I will probobly do when I am ready to work on the design for the interface for my game, is do a very rough sketch in a somple GUI frendly WYSIWYG program like VB. There will be no code, or maybe just enough to transition between the different menus and thats it.

I think this is what you were asking anyway...

Dwiel

Share this post


Link to post
Share on other sites
Heh, please pardon me for not being clear. By interface, i meant code (class/object) interface, not user interface

thanks anyways for attempting to help, Tazzel3D

Share this post


Link to post
Share on other sites
"Use cases" for discovering what software needs to do.
CRC cards or equivalent technique for which class does what.

That''s what we do anyway.

"Most people think, great God will come from the sky, take away everything, and make everybody feel high" - Bob Marley

Share this post


Link to post
Share on other sites
To be somewhat more informative:

Use Cases
CRC Cards

Personally, I just think about it and start writing. If I'm having trouble getting something to work, I remember to consider the possibility that my interface design was wrong.

And always always remember to refactor! This includes refactoring interfaces. Of course it's often best to aim at the easy targets first, but don't be afraid of big refactorings either.

[edited by - Zahlman on January 14, 2004 7:50:37 AM]

Share this post


Link to post
Share on other sites
If you''re making an interface that''s designed to swap out the underlying implementation rather easily (ex: making a graphics class so it switches between OpenGL and Direct3D fairly seemlessly), then don''t have your interface tied to API dependent details. Abstract it enough so you really aren''t concerned with what''s happening under the hood, so to speak.

I''ll agree with Zahlman and say that writing stuff out on paper is a pretty good way to go about it. Just start jotting down ideas that come to your mind, listing the different specs and tasks for your interfaces. Working things out on paper first saves a lot of headaches when it comes time to code.

And don''t be afraid to scrap ideas for new ones. If you think you have a better idea of how to do something, start doing the paper thing again until it starts coming together.

Share this post


Link to post
Share on other sites
Actually, by "writing" I meant the code - I almost never put things down on paper, but I cede that such technique probably doesn''t work for everyone. I just find it easier to keep things in my head, most of the time.

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!