Best way to program?

[3DModelerMan]

Hi I was wondering what the best way to program a game is... should I have seperate parts of it in seperate functions (int splash_screen() , etc)
or should I have "class splash_screen , etc"?.
Thanks .

[skumar]

Games have a highly complex way of switching and decision making .So one of the best way of doing this is the use of Finite State Machines..You can start on your own or you can use an irrlicht based game framework by Paul Rowland...called irrwizard...

Try this....

http://irrwizard.sourceforge.net/

[The Onslaught]

But aren't Finite State Machines an obsolete way of programming AI?

I've heard that the new methods use game statistics and stuff like that

[JP]

FSM's are in no way limited to AI, that's just one of their uses and i should think they're far from obsolete!

Basically there's a 'skill' in knowing what should be a class and what shouldn't and how to program, there's no doubt lots of tutorials and useful tidbits on google if you go looking so i suggest you do that now as you obviously won't have broken the trend of your life so far and researched before asking!

[rogerborg]

Your design patterns have no honour!



A real programmer puts everything in the main() function!

[Seven]

:0 i really like that one

btw, you have WAYYYY too much time on your hands

[jontan6]

Hi I was wondering what the best way to program a game is... should I have seperate parts of it in seperate functions (int splash_screen() , etc)
or should I have "class splash_screen , etc"?.
Thanks .

there's no right or wrong. just code and code, and after you gained experience you will be able to decide whats the best way to go for each situation

[The Onslaught]

FSM's are in no way limited to AI, that's just one of their uses and i should think they're far from obsolete!

You are an AI expert isn't it JP, I'm glad to hear that FSM aren't obsolete, I made a little AI module using FSM in my Theory of Computing course.

So I guess that I will use it in my game right now, but I am very curious in the engines that use player statistics and stuff like that.

Do you know where can I start? It seems that you developed an AI engine, I just want some advice

Thanks in advance

[rogerborg]

Pfft, the vast majority of successful[1] games use FSMs (Finite State Machine, not Flying Spaghetti Monsters). The exceptions are very limited: Creatures, Black and White and Spore spring to mind.

Even in those cases, the 'AI' still clearly uses a FSM, just with complex and variable state transition rules. However, whether the variation in state transitions are achieved by using a neural net or just a Mucking Great Rules Table and Modifiable Database is largely irrelevant from the players' point of view. Whatever technique most easily produces the required results is teh winnar from a development point of view.

It is possible to write stateless behaviour, but it's likely to appear psychotic when used for any complex interactions. For example, I wrote a stateless[2] Netrek robot in which many sub-routines competed for instant control over various aspects of a starship's behaviour in order to satisfy selfish desires.

It certainly produced unpredictable behaviour, which was one goal, but it was deranged, inefficient, and next to impossible to debug or improve, so it failed in the other goal of actually being a useful computer oppponent.

Unless you're writing a game whose primary purpose is to showcase a particular AI technique, and you have dedicated developers who accept and embrace the need to produce unit tests that prove that their oh-so-clever technique actually produces valid, useful, observable results, then I'd highly recommend sticking to simple FSMs.

[1] Battlecruiser 3000AD does not count, since it was never "successful".

[2] It stored knowledge of world events, but not of its own goals.

[CuteAlien]

Don't confuse the guy with FSM's. I wrote my first games before I even learned what that is :-)

Minimum classes I recommend:
- Application class (for Init(), Run(), Quit() and having pointers to all other classes)
- Config class (for your settings)
- One class for each dialog (UI can also be seen as one or more dialogs).
- Game class (which handles all game logic which starts after you click "start-game" in your mainscreen (or after level loading if you have that)).

Instead of an FSM simply use an enum variable to keep your state. But set it not directly but with Setter/Getters, because then you can add functionality for state-switches in the setter (which is already like a simple statemachine then, but without all the overhead).

An older thread about that topic can be found here: http://irrlicht.sourceforge.net/phpBB2/ ... 3220#73220

Also maybe you want to browse sourceforge. Search for small, but finished games (like a working spaceinvaders, tetris or pacman clone - pacman already beeing rather complicated). Check those sources.

[rogerborg]

Don't confuse the guy with FSM's.

"The guy" isn't my audience, since he never reads past the first sentence of any reply anyway.

[CuteAlien]

Don't confuse the guy with FSM's.

"The guy" isn't my audience, since he never reads past the first sentence of any reply anyway.

You mean, like he dares to stop reading after:

Your design patterns have no honour!.

How outrageous...



P.S.
yeah, yeah - I've seen the other threads, but you invited that volley here ;-)

[3DModelerMan]

Thanks that was a lot of help, I think I know how to do it now, I was originaly trying everything inside of main(), that did'nt work, so I tried seperate functions for different menus, but I got problems with my main loop. Thanks for the help .

[rogerborg]

In kendo, students are trained by being hit where their guard is weak until the pain teaches them to defend themselves.

This is just like that, except that I'm not particularly bothered if you learn anything.

[3DModelerMan]

No way... you do kendo?, I used to do kendo to, but where we moved there is'nt a good dojo, the only one near us is a place where they're concerned about hitting to hard.