...I warned ya... :-) If you happen to get the team of people, who have no idea about game programming, yet even to say programming. (I AM THE ONLY C++ PROGRAMMER!!!), and have this situation, what do you do... >>I am the C++ programmer - I make the brains of the game >>We have 14 graphics artists, who CAN make the graphics engine >>We have 3 beginner VB programmers, who are just tagging along Now, this is what we want to do: =============================== The VB programmers REALLY want to make the interface (i am not the boss)...I am told to make the game engine, and do the general game "Brains" design. The graphics artists would make the Graphics Engine using Flash...or director. Now, out of this WHOLE mess this is what we want to come up with: -The .exe that would be the Graphics Engine (apparently tou can make .exe''s in Flash or Director...hey I have no idea) -The .exe that would be the game it''self..the Brains...written the Brain...me (hehe ;-) ) -The VB garbage that we don''t really need but have anyway that will be the "Interface" (Oooooo Aaaaaaa) Now, after glueing this all together we want to get a game (go figure). The way we though of making this work is by having a communication line between the running programs. (This does not really apply to the VB interface, because it will only launch the Graf Eng, and the Game, then close itself). This is how this communication line would work: BOTH PROGRAMS HAVE A LOOP- When an Input Event occures in the graphics engine, it would tell the Game Engine what happened (a value or something) and the Game Engine would respond to the Graphics Engine...like telling it "Blow Head Off". Communication between the two engines would be continous, so whateven happens in either engine would effect the output of the other engine. So, if a randome event occures in the Game Engine''s AI...like a falling rock, then it will tell the Graphics engine to drop a rock figure at X,Y, and Z coords. The Input Events only occure in the Graphics Engine, the Game Engine is more of the processor. ================== SUM: -3 .exe''s -2 Main Engines -Infinate Communication Loop -Game Engine is the Event Processor -Grapghics engine is the user input retriever, and the output Well...If anybody has any idea of what I am talking about, you should win the Nobel Prize for Human Communication ;-) Well, have fun decoding what I wrote

quote: If Windows crashed in a forest...were did you plug it in?

I think I get what you''re saying.

I would run very far, very fast.

I have no idea how that would work.

I wanna'' ride on the pope mobile.

ok, i know somebody will probably tell me that anything is possible, but please keep in mind that i am taking reality into account with my rambling:
you guys are doomed. you need organization and a clear concept of what you are going to do before you start; even if you get a neato engine running, and the graphics guys get something else running, you will have a hellish time putting all this together, and probably won''t get it going good enough.

quote: Original post by Buy2Stamps
>>I am the C++ programmer - I make the brains of the game
>>We have 14 graphics artists, who CAN make the graphics engine
>>We have 3 beginner VB programmers, who are just tagging along

how much c++ do you know?
14 graphics artists? hot damn! how will they (as artists) create a graphics engine that will somehow work with your thing? maybe i am confused, but i always figured the graphics guys made pretty things and the programmers put them together in the game.
3 VB programmers, that you don''t need? i like VB, it is great (for some things), but i can''t see having 3 VB programmers when you don''t even need one. maybe you can have them write you an install program (although probably not if they are newbies)... you can (a) slap them, then tell them they are now learning c++ rather than VB, (b) get rid of them (gently of course; you must like them if you are letting them in on this) or (c) um, i forgot what this one was, but i''m certain it wasn''t as good an option as the last two.

quote:
Now, this is what we want to do:
===============================
The VB programmers REALLY want to make the interface (i am not the boss)...I am told to make the game engine, and do the general game "Brains" design. The graphics artists would make the Graphics Engine using Flash...or director.

you can compile your game engine into a DLL i suppose, then with some cleverness you can set it up to work from VB so they could make your interface... i am no authority on this, but i think this is a mistake. i know nothing about flash or director, although i''d be willing to bet they are not anything compared to c++ with directX or openGL...
who is the "boss"? perhaps you need a new one, if this is how he wants your dev team to run.

quote: Now, out of this WHOLE mess this is what we want to come up with:
-The .exe that would be the Graphics Engine (apparently tou can make .exe''s in Flash or Director...hey I have no idea)
-The .exe that would be the game it''self..the Brains...written the Brain...me (hehe ;-) )
-The VB garbage that we don''t really need but have anyway that will be the "Interface" (Oooooo Aaaaaaa)

ok, i guess maybe you can interface flash or director with c++, but why bother? if they are artists they can draw their stuff (or model it in 3D), and the programmer can use those gfx in the graphics engine, which nicely is in the same c++ program as the game engine.
give the VB coders some roofies and leave them at a bus stop somewhere.

quote: Now, after glueing this all together we want to get a game (go figure). The way we though of making this work is by having a communication line between the running programs. (This does not really apply to the VB interface, because it will only launch the Graf Eng, and the Game, then close itself).

i hope you don''t think i am being over critical; it is this "glueing" part that makes me think you are facing a near-impossible task.

quote: This is how this communication line would work:
BOTH PROGRAMS HAVE A LOOP- When an Input Event occures in the graphics engine, it would tell the Game Engine what happened (a value or something) and the Game Engine would respond to the Graphics Engine...like telling it "Blow Head Off". Communication between the two engines would be continous, so whateven happens in either engine would effect the output of the other engine. So, if a randome event occures in the Game Engine''s AI...like a falling rock, then it will tell the Graphics engine to drop a rock figure at X,Y, and Z coords. The Input Events only occure in the Graphics Engine, the Game Engine is more of the processor.

not bad, but i think it will be slower and buggier if you have it in 3 separate apps.
i wish you luck, but i think you are structuring this all wrong. if you ever actually want to get this game done, you''re going to have to put design and programming concerns before worrying that everyone in your huge group gets to do something [useless].

--- krez (krezisback@aol.com)

What? No Pascal programmers? This sounds scarey. Graphics artists should be drawing pictures, not programming. The Visual Basic programmers should go back to school and learn C/C++.

I think you need to stick to one language C++. With one engine. You need someone working on level design, graphics, game engine and of course most important, storyline and plot, depending on the game. It sounds like there are too many graphic artists, and too many engines. Very confusing... I see absolutely no reason why there is any need for a VB interface and then try to get it to communicate with you C++ engine when you could be creating the interface in C++ as part of the egine, less confusion, easier communication. Ditto with regard to a seperate graphics engine. It should all be part of one egine being programmed in the same language, with maybe a lead programmer and a few programmers that work under his direction with a few graphic artists doing ONLY the graphics and giving input on what the engine needs to do to display thier graphics, a level designer and a project leader who know a plot and storyline who can direct all of you.

Just my opinion.
Have a good one;

Neil "Night Hacker" Roy

(P.S.: check out my Deluxe Pacman game available online here )

My completely useless advice that you won''t want to read either:

It sounds like your group is trying to give everyone in the group a job, and make everyone happy...the graphics guys want to use director, the VB guys want to write interface code in VB, and you want to write C++. As a result, you''re making the game design fit the team, not the team fit the game design.

Not to mention that you have 18 people! It''s accepted theory in management that each manager should manage ~7 people, +/- 2. So this project needs 2 managers, plus a manager over them just to manage this project. Just answering emails must be a full time job!

You need to slim down, and break into about 4 teams. The graphic artists should go off and make their game entirely in flash or director or whatever. They don''t need a C++ engine for that. The VB people should go off and do their game in VB. You should stick with the best few people out of the group, or find some new people.

Actually, you could learn COM and ActiveX and totally save the day. You would write a COM object in C++. The VB guys can call any method of that object in VB. As long as Director can talk to COM objects, or vice versa, you would be golden.

Or you''ve got enough people to start your own baseball team. Got anyone who can pitch?

14 graphic artists? Can I have one?



From what I recall, Flash does not play well with others. Doing the program in VB and C++ would not be a problem at all, but integrating the Flash will probably be a nightmare of it''s own. Usually creating an executable in such a program merely consists of putting the player and the data file into the same file. Not much control there (correct me if I''m wrong).



Run fast. Do not look back. Find a team with some level of sanity.



Give us liberty, or give us death!

Is this some sort of a sick joke?

Seriously, though, you''re asking for trouble if you''re planning on doing the graphics "engine" in flash and then somehow integrating it. The VB - C++ integration is doable, but the flash is both overkill and likely won''t work. I''m not so sure everyone over there knows what a graphics engine is if you''re planning on doing it in Flash, sorry if I offend you. My advice follows with the majority - either demand the project is restructured or runaway.

Well, it looks like I need to get a team manager...or quit the team huh? OR, -if i can- Fire the Boss? Hehe...or steal his idea and RUN...RUN LIKE MAD!!! hey...it''s not copyrighted. Yea...In fact...i think i should steal the idea (WHICH WAS MINE), and take the artists with me, and leave my boss with the VB programmers.

quote: Run? Run like mad?

quote: Original post by Buy2Stamps
...I warned ya... :-)

but sometimes I like to know there are people who have it so much worse than me.

quote:
If you happen to get the team of people, who have no idea about game programming, yet even to say programming. (I AM THE ONLY C++ PROGRAMMER!!!), and have this situation, what do you do...

I''ld get out a spoon and start digging a tunnel under my desk to freedom and sanity.

Alternatively, saying to the boss "you''re an idiot. I quit." is actually a retty sensible option.

Either way, good luck with the escape plan