Odysseus Kosmos – Developer Diaries #5

repair_work

Hey there, friends! Welcome back on board of “San Francisco”, a huge spacecraft travelling far, far way from planet Earth.
After wrapping up character design I started working on the first-playable and on the game engine. There were a lot of serious preparations at this point. A lot of time was spent on designing and thinking the entire system through. I knew that the success of the entire development will depend on the core engine, so my efforts and time would pay off eventually.
A quest includes dozens of locations and hundreds of items. And there is always the temptation to implement this system directly in the code. Let’s say, we have four chests in a scene. Sure, you can write a couple of lines using C# or Java to easily handle the situation and walk players through the game story. And there is another location where you must help players picks two items in a row. You can add another line of code. Sounds easy, isn’t it? Not at all! In time the total difficulty of these conditions grows and can become overwhelming. Can you imagine what kind of construct grows in the code as you approach the first hundred items?!
I’ve chosen a different approach. The entire game logic for items is handled by a separate script. The core engine recognizes it and applies the conditions and commands to the items in scenes. If there is a command “make the character use this” – all right, let’s do this,

collect_01

collect_01

I can change the name of action in the script at any time to make it look like this:

collect_02

collect_02

No need for recompilation or reassembly. Four lines of script handle the four chests. No complexity growth whatsoever! The basic stable game engine does not change, no matter how many objects or interactions are added. You can be sure that the 1000th line will work just the same the 10th. There is no need to copy any strings and the required line can easily be found using the search function. And yes, I am aware of the frameworks available on the market… but none of these offered the required flexibility and some key features that I will focus on some other time.
I should also say a few words about the mini games architecture. There is different logic in different games, so we had no other choice but to write more code. But!

minigame_01_v2

Due to the features of the global engine structure, all mini games featured in all of the game episodes are absolutely isolated from the main engine. So even if something goes wrong in a mini game that won’t affect the main logic. This also has the benefit of non-strict discipline when coding the mini games. You can just work at your own pace and enjoy coding.

minigame_02

And next time we would like to talk about the episode structure of the game or continue our tale about the project development.

 

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s