How do you NOT make a game?

Started by
8 comments, last by MaulingMonkey 18 years, 9 months ago
Hello there. It's not that I have a problem I need help with, it's more that I'm curious. I'm a fairly accomplished hobby programmer, at the moment making a 3d-action flight-sim on my own. Only problem is, I've never made anything BUT games. I have absolutely no idea how to make a buisness solution, or a database bound program. For example, Microsoft Word is a complete mystery to me. How does a program like that work??? Would you make it exclusively in Visual Basic, or what? The complete lack of an update cycle - or framerate if you wish - puzzles me. And also, how would you create a thing like a buisness app. which utilizes databases? Same way as Word, or would there be major differences? Please don't answer in any in-depth way, because that's not what I'd like to know. I only want to know the general thing, explained in a very simple way. Thank you.
----------------------~NQ - semi-pro graphical artist and hobbyist programmer
Advertisement
Applications are generally event driven. They just sit there and idle, processing messages as their message loop, which is similar to a games 'game loop', and react to buttons being pressed, controls being used, etc... Most of the logic for an application is in its handling of the events it recieves.
Perhaps an interesting way of migrating and learning how to make applications would be to make an editor for your game.
Ok, I see, but how would you go about creating them? What would be the most "normal" way?

[edit:] andrew: heh, i HAVE in fact made several (read: insanely many) editors through my history, but they've always been driven the same way games does. With framerate. But yes, that's a nice idea.
----------------------~NQ - semi-pro graphical artist and hobbyist programmer
Well, I think the best way of learning how to make them is to actually try making something. I suggest you get hold of some windowing toolkit (.NET, Borland's VCL (or whatever their latest is), wxWidgets (free), etc) and grab some tutorials and make a FUP (fairly useless program) or an editor.
Alright, fair enough.
I've only ever created things such as scrollbars in Visual Basic (in school), but there's a nice-and-pleasant way to do it in C++ as well??
----------------------~NQ - semi-pro graphical artist and hobbyist programmer
Or, hmmm... you said windowing toolkit?
Would that mean you combine a visual editor (creating visual buttons) with a code editor (code which the buttons execute)?
----------------------~NQ - semi-pro graphical artist and hobbyist programmer
Make a tool for your game using a Win32 or MFC GUI. An item editor or something. Start with something simple. If I were you I'd avoid diving straight into a 3rd party lib like wxwidgets. They are commonly not easy to get initially set up.

As an easy example, if you use visual studio to create an "MFC Application" it will generate a bare bones window. For simplicity have it create a dialog based application. SDI and MDI stuff can get complicated. Then you can double click the dialog on the resource pane of visual studio to edit it. Drag various tools onto the window to add them and position them and set various properties, then you can right click on those tools you can Add event handlers which will get called when various events are sent to those tools. This will add empty functions in the code you can write your code in and a few other lines that 'register' the event function.

This is a simple example just to get a bit of a feel. Some might say "MFC is the devil!" but it's a perfectly capable tool at making GUI based tools, and simple enough to get your feet wet. I wouldn't try to understand much of how MFC works though.

Alternatively if you want to get more lower level you can write a GUI app in straight Win32.
Oooooooooooooh!!
Visual studio can do that????
I have to try that when I get home! (at work)
Thanks!
----------------------~NQ - semi-pro graphical artist and hobbyist programmer
Quote:Original post by DrEvil
Applications are generally event driven. They just sit there and idle, processing messages as their message loop, which is similar to a games 'game loop', and react to buttons being pressed, controls being used, etc... Most of the logic for an application is in its handling of the events it recieves.


Just to expand on this, the main difference between a game loop driven app and an event driven app is that whereas games poll for events, and then do game logic/updating/rendering... e.g. to use SDL as an example:
int main () {    ...    while ( true ) { //game loop        SDL_Event e;        while ( SDL_PollEvent( &e ) ) { //event loop            ...deal with event...        }        render();        SDL_SwapBuffers();    }}

Event driven applications wait on events, blocking when there is none:
int main () {    ...    SDL_Event e;    while ( SDL_WaitEvent( &e ) ) { //main loop/event loop        ...deal with event...    }}

In the waiting for events model, rendering is usually (AFAIK) an aftereffect of the event. If you get a click on a button, you render the updated button. If you get a paint message (e.g. SDL_Event::type == SDL_VIDEOEXPOSE), you render because the screen needs to be redrawn.

This topic is closed to new replies.

Advertisement