• Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

103 Neutral

About RutherfordJones

  • Rank
  1. Looking For Programmers

    [quote name='vleugel' timestamp='1327866255' post='4907408'] Professional programmers probably ask about 15-30$/hr [/quote] They must be pretty crappy at those rates. That is quite low for someone with the capability to create an MMO.
  2. Simliar to GorbGorb's solution: Code: [code] template < typename T > inline unsigned int GetRTTI() { static char s_rtti; return &s_rtti; } [/code] [b]Pro:[/b] One of the quickest implementations ever. Don't have to write much at all. Fast comparisons. Low memory overhead [b]Con:[/b] RTTI values are not absolute and will vary with memory layout. Tracking bugs between different code executions may be difficult. May want more info other than a memaddress.
  3. I'm going to recommend that you hire a consultant to help you out with this sort of information. I understand you're probably testing the waters and trying to get a ballpark figure. However, when or if you do get serious about this project, I highly recommend you pay someone to help you figure out the actual requirements and if you'll be able to make your budget. You have two major issues you'll need to figure out: 1) A well defined set of functional and non-functional requirements 2) Competent people who can realize #1 For #1:A lot of entrepreneurs fall prey to good intentions. There are people who mean well, but will invariably give bad advice because they have no stake in the outcome. Or perhaps they were never qualified to give that advice in the first place. This is your money, not theirs. Most people's advice will change when they're eating from the same table as you. For #2: Programming is an area (perhaps more than others) where you can paint yourself into a corner. You MUST find competent people. Part of the reason why the game development community is so prestigious is because most people who try to enter do not make the cut. It is much cheaper to hire a consulting firm to help you figure this stuff out and hire the right people. There are a great deal of people who are excellent at what they do, but are terrible at defining timelines. There are even more people who excellent at what they do, but terrible at anything else. Game Development is about thinking outside the box- and you'll need someone who can get stuff done even if they don't know how to do it right away. Equally as dangerous are programmers who can promise the moon and never deliver. Good luck! :D
  4. Unity Quick and painless FSM techniques in c++?

    Quote:Original post by Antheus The problem above is in A5. Are you sure, absolutely sure, that there cursor will finish shrinking? For example, what happens if at A3 fires at 1.5 seconds. The things in my sequence aren't particularly volatile. The only thing that matters is that the art assets exist to be acted upon and are then cleaned up once they are done being acted upon. The sequence is guaranteed to not occur unless the assets exist, and the sequence is allowed to prematurely end with no consequence to the assets. Also, if the assets stop existing, then the sequence does as well.
  5. Unity Quick and painless FSM techniques in c++?

    I feel you're being rather harsh about pointing out my yearn to generalize. In the end, I think my downfall is that I left out a lot of information about my situation, or perhaps used a charged paradigm (FSM) as a possible fix to my solution. I think I also oversimplified my examples. I'm not so much concerned with whether my approach to use a FSM is correct, but the fervor in which you folks try to steer me away is compelling enough for me to rethink the situations I'm dealing with. My search for a solution stems from having to babysit things that should be fire-and-forget. This babysitting means that I must keep track of each thing that gets timed, color shifted, emitted, or alpha faded. My 'final solution' should indeed be to make such things so they are fire-and-forget. However, that's not an option at the moment. If it were as simple as my examples suggested, then I wouldn't need a FSM at all. But each 'state' as it were, needs to track various things before it may move onto the next. If it's not a FSM that I need, then I certainly need some way to encapsulate the things that get tracked- so that they may be properly initialized & cleaned up if I choose to rearrange the order in which they happen. I'd still like to entertain the idea of a FSM. If for no other reason than to discuss different ways to implement them in CPP. swiftcoder's showed an amusing example of what I mean.
  6. Unity Quick and painless FSM techniques in c++?

    Quote:Original post by The Communist Duck I asked a question about this a while back on the gamedev stackexchange. There's a huge range of answers to how to do this, but mostly you won't want an FSM. I have something similar to this for global gamestates- the exact same type that you describe at this link. My problems lie in tinier items of polish. Things like: (Time increases the farther down you go in this list) T1) Screen Fades to black A1) Player cursor becomes frozen A2) For 2.2 Seconds, The player cursor grows in size A3) 75% of the way through the cursor growing, a star sparkles in the upper right corner of the screen A4) When the cursor finishes growing AND the star sparkle finishes, for 1 second, the cursor shrinks down in size. A5) When the cursor finishes shrinking move on to T2 T2) Screen fades to purple A1) Audio plays A2) Audio finishes and we move to T3 T3) Screen fades back from purple and back to normal Imagine a game designer wishes to change A2 through A4 to do something completely different. Maybe rotate cursor. Maybe a monster flies in and laughs at you for a few seconds. We're talking really specific situations that get very complex (because game designers think of EVERYTHING :)
  7. Unity Quick and painless FSM techniques in c++?

    You make a good point about this particular sequence being set-in-stone and abort-able. Yes, this is probably one of those situations where a FSM would be superfluous. I think there is a point however, where development practices may dictate an overly complex solution for a simple problem. In the final game you'll never jump from Step 2, to state 2 to 8, or from 8 to 3. But during development, if you wish to be agile, you'd like to have the ability to rearrange them at a game designer's whim. This is the situation I'm in. As a programmer I can easily choose the proper paradigm to fit the bill for runtime and development time efficiency. However, I find myself needing to lean more towards RAD techniques akin to what you'd see in web-development. This means that my solutions may not be runtime-fastest, but I'll be able to iterate with a designer quicker until we ultimately do find the final sequence. I'm trying to discover a final solution for some sort of "FSM" framework for rapid development needs. I find myself iterating on a lot of simple logic of seemingly interchangeable gamestates. In the end, the gamestates are all abort-able sequences. But until that end, they're all arbitrary. Lately I've been leaning towards creating a FSM framework in which states are able to share a parameter package of data- that way states can know about global state machine variables while retaining their logic encapsulation. Also, I'm simply curious about other ways this stuff can be done with the assumption that my example sequence had variable state changes.
  8. Given: You wish to animate some UI elements in sequence to signify some game event. The overall sequence is relatively simple, which I will explain below. Therefore it is decreed that you must use CPP, and not some scripting system to complete the task. In the end, your solution will boil down to a Finite State Machine; in which each state will match a distinct part of the desired sequence. To do a Finite State Machine in c++, I find myself limited to what I've been exposed to. The techniques I know have their strengths and weaknesses. However, I'd like to know more. I know there are better options out there, but I simply don't know where to research. Perhaps I'm simply missing some jargon for which to investigate further? Anyway, I turn to you, Gamedev.net community. I ask that you enlighten me. I'll share what I know as well... To start, we'll need a fictional problem to solve. So here's a relatively simple scenario that happens in most games, yet requires a great deal of annoying busy-work c++: The title sequence. 1) The game starts to a black screen. 2) The intro/logo screen fades in over a second. 3) The intro/logo screen idles for a bit 4) The intro/logo screen fades out 5) The credits screen fades in 6) The credits screen idles for a bit 7) The credits screen fades out 8) Game transitions to title screen with "Play Game" option. Here's what I know and what I've seen used in games: Switch Statement Pros: Very quick to get results. All states can access the same data. Con: Not scope friendly for state specific variables. Can't do complex logic or multiple states. Ugly. States are defined by the enum (header) and fleshed out in the code file. enum eTitleScreenState { kTitleState_FadeInIntro = 0, kTitleState_IdleIntro, kTitleState_FadeOutIntro, kTitleState_FadeInCredits, kTitleState_IdleCredits, kTitleState_FadeOutCredits, kTitleState_TitleScreen, }; ... class IntroSequence { eTitleScreen m_state; void Update(float timeSlice) { switch(m_state) { case kTitleState_FadeInIntro: if(IntroGraphicIsDoneFading()) m_state = kTitleState_IdleIntro; break; case kTitleState_IdleIntro: m_waitTime += timeSlice; if(m_waitTime >= m_introWaitTime) m_state = kTitleState_FadeOutIntro; break; case kTitleState_FadeOutIntro: if(IntroGraphicIsDoneFading()) m_state = kTitleState_FadeInCredits; break; case kTitleState_FadeInCredits: if(CreditsGraphicIsDoneFading()) m_state = kTitleState_IdleCredits; break; case kTitleState_IdleCredits: m_waitTime += timeSlice; if(m_waitTime >= m_introWaitTime) m_state = kTitleState_FadeOutCredits; break; // You get the idea } } } Polymorphism Pro: Gain all benefits of OO programming- encapsulation, extensibility. Can re-use FSM. Con: Lots more code to write. Can be difficult to trace sequence of events without IDE help. Have to worry about dynamic allocation (maybe). States have trouble accessing common data. class State { FSM* m_master; virtual void Update(float timeSlice) = 0; }; class FSM { State* m_curState; void Update(float timeSlice) { m_curState->Update(timeSlice); } void SetState(State* state) { m_curState = state; } }; class IntroSequence { FSM* m_fsm; void Update(float timeSlice) { m_fsm->Update(timeSlice); } }; class FadeInIntro : State { virtual void Update(float timeSlice) { if(DoneFadingIn()) m_master->SetState(IdleIntro); } } class IdleIntro : State { ... } class FadeOutIntro : State { ... } class FadeInCredits : State { ... } // You get the idea Message-based (Essentially two systems. A sequencer that issues messages, and a message handler) Pro: Timing of sequence can be quickly changed without need to rearrange states or state links. Con: Doesn't encapsulate data well. Message handling can be tricky on large scale. Two Systems to maintain (though once sequencer is done, it never needs updating). Data isn't easily shared between states. class IntroSequencer { float m_timer; void Update(float timeSlice) { // this sequencer method is crude and just pseudocode. assume that in a real scenario it's more robust and is setup with a stack or queue data structure m_timer += timeSlice; if(ThresholdReached(m_timer)) IntroScreen::HandleMessage("FadeInIntro"); else if(NextThresholdReached(m_timer)) IntroScreen::HandleMessage("FadeOutIntro"); else if(NextThresholdReached(m_timer)) IntroScreen::HandleMessage("FadeInCredits"); else if(NextThresholdReached(m_timer)) IntroScreen::HandleMessage("FadeOutCredits"); } }; class IntroScreen { void HandleMessage(char* szMessage) { // can be done with switch too // no need for idle messages since it's not doing anything there if(szMessage == "FadeInIntro") // pseudocode. FadeInIntroGraphic(); else if(szMessage == "FadeOutIntro") FadeOutIntroGraphic(); else if(szMessage == "FadeInCredits") FadeInCredits(); ... // You get the idea } };
  • Advertisement