Jump to content

  • Log In with Google      Sign In   
  • Create Account

Keeping parts of the engine separate


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
2 replies to this topic

#1 Theis_Bane   Members   -  Reputation: 312

Like
0Likes
Like

Posted 03 September 2012 - 01:56 AM

After taking the advice of several valuable forum posters, I 'grabbed the bull by the horns' and began coding my very first game: a text adventure! I wouldn't say I'm new to computer programming, but it's been little more than a hobby for me for the past ten years. Luckily, over this past year, things have begun to 'click' in ways they haven't before, and I'm flying through my text adventure's engine. I recently started to comprehend an entity-based design system built around unique entity ID's and a plethora of specific DB queries, so my engine is slowly morphing into something quite interesting. And as I'm not exactly sure of what I'm personally capable of programming, I'm sorta planning my engine as I go (though I do have a very general idea of what I want). Eventually, I'd like to complete a single player game that shows off the engine, and later adapt the code into a MUD. (If anyone has any advice on preparing my engine for that, I'm all ears. I know very little about networking at this point, but I'd like to make future transitions as torture-free as possible.)

Before I get to my question, I'd like to explain a bit about the general structure of my programming. I'm using Visual Studio 2008. In my solution, I have added a WPF project that will eventually be the User Interface for the game. The main bulk of the programming is in a class library file with currently one class file containing the entirety of my engine. I have multiple managers that process queries, each handling relatively similar tasks within the engine. For instance, my Environment Manager handles light levels, weather, and indoor/outdoor aspects of Areas, while my Accessibility Manager handles Features with Open/Close, Security, Vehicles, and item generation properties. Then I have my Parser. Currently, to run the engine, all one has to do is reference my class library, create a TextAdventure object, and pass a string to TextAdventure.Parse(string) to get things moving. This returns a string[ ] array (set up this way for UI formatting possibilities) which holds the results of the player's actions.

Now, for my question. I'm beginning to think ahead to character customization possibilities, but I'm not sure if I want to hardcode this straight into my world engine. I'd like to think that I'm building this engine so that it is possible to create sci-fi, modern, fantasy, and horror games without any engine modification. BUT, I doubt I will always want the exact same character statistics across every game I build. If I can, I'd like to keep the character engine separate, but I'm having a hard time wrapping my mind around how to do so. How can I build my world-building engine separate from my character building engine, or do I have to reference both aspects from within each if I ever hope to get this thing made?

Sponsor:

#2 slayemin   Members   -  Reputation: 2652

Like
1Likes
Like

Posted 03 September 2012 - 04:31 AM

There's a subtle trap you may be at risk of falling into: Soft coding everything. It's at the opposite end of the spectrum of hard coding everything, but can be just as annoying.

Focus on creating your game to its specific requirements. You're going to have to get specific somewhere, eventually. If that means you have to create a fantasy character generator to make your game work, then that's what you'll have to do. If, in the distant future you find yourself building a futuristic version of your game, you can reuse most of your code and existing software architecture. It'll probably add unnecessary complexity if you want to generalize your character generator for any genre. Remember that software is software, which means it can change with changing requirements. It takes less effort to recompile and deploy a patch :)

Eric Nevala

Indie Developer | Dev blog


#3 pmvstrm   Members   -  Reputation: 122

Like
0Likes
Like

Posted 07 September 2012 - 03:24 PM

Try to build each subproject as lib Project and statically link it later all together.
Someparts maybe, not related to the main program functions or later interchangeable should stay outside
the exe as dll.

Edited by pmvstrm, 07 September 2012 - 03:29 PM.





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS