Jump to content
  • Advertisement
Sign in to follow this  
graveyard filla

the general layout of an (C#) application program? (lots of Q's)

This topic is 4901 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

hi, this might sound ignorant, or stupid, so please forgive me in advance. recently ive been given the chance to work on some commercial windows appliaction projects (and *GASP* maybe even get a real job!), but all my experience is using C++ and game development. anyway, i've been studying C# and playing around with winforms for the past few days (i almost want to cry thinking about how much time i wasted writing ugly, ugly level editors, when i could have done it in half the time in C#), and i get the basic concept of C# and winforms, but it is the general layout / architecture that i dont understand yet. so, i have a few questions.. first, does anyone have any tips / hints / whatever for switching from game development to applications programming? any obvious things i should watch out for? any "gotchas"? next, where does the core logic to applications programs (using C# and winforms, specifically) go? this is kind of an obvious, maybe stupid question, but im really not sure. after doing some reasearch, i believe that i should overload the OnPaint() function on my main form, and put the core logic in here? so this function will be called each frame? but, what about scope? would i make them members of the main Form's class? even then, im still not sure where i could initialize them or perform initial actions on them (the main forms CTOR?). also, what about the general layout and architecture of an applications program? i mean, its weird, its like i cant see the general layout in my head because im so used to game development. where does most of the core logic go? does most logic just go into the individual form's functions (e.g. each button's click, text box enter, etc?). it seems like theres a lot of "globals" (not really global, but more like members that we can see because they are part of the same class, e.g. buttons and stuff). in fact, C# seems to make it even easier to expose variables with the get / set properties. do we really just do things like some_button.Text = "blah" from anywhere we want in the code? what about forms that should not be immedialty visible on the start of an application, or should be visable at start but go away? for example, lets say we wanted to have an initial login screen for the app.. how would this work? would i use a form like Panel, place it in the middle of the main form.. put in the username / password text boxes / "OK" button? then, inside the ok_button_Click() function, i simply just do whatever logic is needed, and then do panel_login.Visable = false? i'm not sure Panel is the right form for this though.. also, what about other "invisable" forms? for example, lets say i made a program where a player could do a turn based, text based battle against himself / another player by just pressing an "attack" button and watching the other persons health go down.. when their health reaches 0, i want to pop up an alert box saying "you died!", and then perform some other logic.. first of all, where would i do this logic? (the if(tb_player_health.Text <= 0) Do_Stuff_Here()). would this go into the Form1.OnPaint()? second of all, what about the GUI portion of this? would i place a panel form in the main window, with an "OK" button, and a label saying "you died!", set this panel to be invisable, and then set it to be visable when the player died? or, should i use the Forms.MessageBox() function? also, i have some other confusions, like in general im confused on where to put my classes / structs, but i think that if i can get these answered i could figure it out. thanks ALOT for any help!!

Share this post


Link to post
Share on other sites
Advertisement
Ok, first of all, you need to work the same way as you work with C++ and classes. The basic idea of C# is to force the programmer to (ab)use OOP to the maximum. You still store flags, etc. like you did with C++, but, you'll be forced to use classes.

First of all, I suggest you either read alot on UML, buy a book on it or take a course in it. UML is one of the tools at your disposal to design your application before coding. I'm not stating UML is the only tool, because there are more ways of reaching the goal.

First of all, I suggest you either use the 2-layer or the 3-layer model. This means, you seperate UI from Business Logic, and Business Logic from Database logic(Even if you're using plain files). In the 2-layer model, you'll merge the business logic with the db logic.

In the 3-layer model, we got 3 layers(Duh!), dividing up like this:

[UI/Controller Layer]
^
|
[Business logic]
^
|
[Database logic]


In the case of a level editor, you'll have a few windows in the UI-layer, and the rest of the logic in seperate classes, such as Tile, Map, ScriptTrigger, etc.

The window has the references to the map, tile, etc. objects, and uses them. For instance, the user selects the "dirt road" tile in the tile window. An event is fired on the button click and somewhere in your window, you set selectedTile = <thingy>.

Now, if you click in your map window to add a new tile, you call map.addTile(x, y, selectedTile). The map adds the tile to that location, and viola, it's added to the map. You then force the map to redraw itself.

On redrawing the entire map, you need to overload OnPaint yourself and do the drawing yourself. For instance, you're viewing (x=10, y= 20) to (x = 40, y = 50) in the window. In the OnPaint function, you call:

Tile tile = map.getTile(RELATIVE_TO_VIEW, 0, 0); // Will translate to 10, 20

This will return the tile, and you can now draw the tile with your graphics object. I suggest you do the drawing inside the OnPaint, and not inside the map object, since Map is business logic, and shouldn't care about how the UI looks like(And since a bitmap is device independant, you can store it in a Tile class).

Same goes with other applications. Check out GotoBed.net on my site, it's written in C# using the 2-layer model. I have a UI class, which sole purpose is to get data from the Notify object and display it. When you hit ok, it grabs all the fields, and goes like:

notify.Enable = chkAlert.Enabled;
notify.Message = txtAlertMessage.Text;
notify.NotifyTime = txtTime.Text; // Parses the time to a DateTime class
notify.Soun = txtSound.Text;


Other things, like your combat thingy, you don't overload the OnPaint(), since you would write classes to handle the work. If you use text-based combat, you'll handle the ButtonClick for the Attack button, run the business logic attacking and update the UI again(Thus, calling playerOneHealthBar.setHealth = playerOne.getHealth()).

If you want to do things real time, find out how to overload the WinMain() function(Or run, not sure, plenty of articles on it) and use that. Relying on OnPaint for real-time things is bad, as the paint isn't running 60fps(Not even if you keep triggering repaint()).

I hope this helped you out.

Toolmaker

Share this post


Link to post
Share on other sites
Quote:
Original post by graveyard filla
so, i have a few questions.. first, does anyone have any tips / hints / whatever for switching from game development to applications programming? any obvious things i should watch out for? any "gotchas"?

Some things I learned last summer were:
(1) Speed does not matter nearly as much (you probably know this).
(2) Do not put in a "Hack" if someone will see your code.
(3) Good code means nothing if a 45-year old secretary if the Buttons are not BIG and the UI is not extremely simple.
(4) If someone is using this app (non-programmer), try to think on their level when designing the UI

Quote:
next, where does the core logic to applications programs (using C# and winforms, specifically) go?

It depends on the type of application, but most logic is in response to an 'event', like the user clicking a button, typing some text. Unlike games that are updated constantly, most windows apps are based on the event-driven model, where logic is process in response to an event.

Quote:
what about forms that should not be immedialty visible on the start of an application, or should be visable at start but go away?

Forms, just like almost every other control, have the 'Visible' property, so you can just set them to Invisible when you don't want to see them. I think there's also something callled "Show()" and "ShowDialog()" [google]

Try to think of forms as any other control, and it should make it easier. You can instantiate them whenever you want. So in login example, you could Show() the form when the user correctly logs in.

Quote:
also, what about other "invisable" forms? for example, lets say i made a program where a player could do a turn based, text based battle against himself / another player by just pressing an "attack" button and watching the other persons health go down.. when their health reaches 0, i want to pop up an alert box saying "you died!", and then perform some other logic.. first of all, where would i do this logic? (the if(tb_player_health.Text <= 0) Do_Stuff_Here()).

What I would do is whenever I lower the health, I would have in IsDead() method and would take action based on whether or not IsDead() returns true.

Quote:
second of all, what about the GUI portion of this? would i place a panel form in the main window, with an "OK" button, and a label saying "you died!", set this panel to be invisable, and then set it to be visable when the player died? or, should i use the Forms.MessageBox() function?

MessageBox should work fine for a simple case like this.

Quote:
also, i have some other confusions, like in general im confused on where to put my classes / structs,

Classes and structs usually go in .cs files. Its the same type of file as your forms, but they won't be inheriting from Windows.Forms

Share this post


Link to post
Share on other sites
thanks guys, i appreciate your responses, i definetly have a better idea on how things work now.

so basically, all logic is event based. we make our objects like normal, but instead of calling Update() each frame for all our objects, we no longer have to do this, because theres no reason to do anything unless an event occurs. so we make our objects like usual, but only have them interact during certain events. this seems like organizing and structuring your code is pretty much already done for you, and you only have to worry about how objects interact with each other.

thanks again.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • 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!