Episode 1 – is out now!

share_picdownload

 

Here are some promo assets(screens, banner, characters) and the game description if you need it: promo pack

Feel free to contact me at 16bittank@gmail.com

All Rights Reserved

Advertisements

Odysseus Kosmos – Developer Diaries #10

house_le

(few moments from second ep =) )

Hey there, friends! Welcome back on board of “San Francisco”, a huge spacecraft travelling far, far way from planet Earth.
Today I’d like to discuss the puzzles and riddles in the game. Because no matter how great the game’s visuals, GUI or story are, most importantly the game should be interesting to play.
What are the means to create interesting game play? (Or, should I say, what means are we using? Well, firstly, you have to be creative and think outside the box! For example, we have our item interactions. Yes, items are basically the foundation of the entire quest game play: “find a pair of scissors to cut a ribbon” or “take a wrench to unscrew a nut”. And this could be fun; this is what we like about the quest genre. But when the entire game is played simply by going through all the options – there is no fun in that.
I’m sure that a decent quest requires at least one (ideally several) puzzles that cannot be solved by going through all options. And I don’t mean that players should guess the solution without going through all options. I mean that you literally won’t be able to solve the puzzle without finding some sort of unusual solution beyond the standard “find an item and use it” pattern. An AI “bot” should not be able to play the entire game, only a human being should be able to do that – than it will be fun for a smart player! The metal detector puzzle in “Grim Fandango” is a great example.
Another point that seems important for me is the structure of the game play. I am an avid believer in the classical quest format, and I’ve already mentioned that I don’t like the “scheduled access” to content. Let’s say, we have a lock on the door and players must find a key to open it and go further. The solution is obvious. There is no mystery here whatsoever. Once the door is opened, you get a new portion of dialogue. All players pass the game at a similar pace.
A good quest in my opinion is when having finished examining the locations you can continue playing in your mind, picturing various solutions that seem correct. Than you have a true fun quest. If this is impossible due to the automatically story progress – this game is not a quest.
Next time we are going to talk about the soundtrack or the game’s visuals. Thanks for your interest!

Odysseus Kosmos – Developer Diaries #9

wardroom_sit

Hey there, friends! Welcome back on board of “San Francisco”, a huge spacecraft travelling far, far way from planet Earth.
​Great news everyone! The game has been successfully released and started selling. We would like to thank all our backers – your support is greatly appreciated.
​Steam has also given us some support and featured our game on the main page with a huge banner for a while, which was also a great help.
​A few quick words on the pricing – this decision was made by our publisher. Currently we are selling the entire season. We trust the publisher’s opinion. And what’s important for us – the publisher guarantees that the season will be completed and all episodes will be released as planned. The stability is highly important in this regard.
​By the way, the next episode is scheduled for 1st of March! We’ll be waiting together.
​The episode is already in active development. The first testing will begin in January and the episode will be launched according to schedule. And the third episode is coming next summer.
​Also many thanks for your nice feedback. It’s just… WOW, thank you so much! Your feedback is what keeps us going. We are reading everything carefully and planning improvements in the next episodes based on your feedback. If you have an advice or a suggestion – please be sure to let us know. We are reviewing all feedback and we’re very interested in hearing your opinion.
​Now that the game has been launched we are planning to post developer diaries biweekly. Next time we will be talking about the in game art. And once again many thanks to all of you! Until next time 🙂

P.S. Odysseus Kosmos – Developer Diaries #8 – available at Steam Community Hub

Odysseus Kosmos – Developer Diaries #7

space_new

Hey there, friends! Welcome back on board of “San Francisco”, a huge spacecraft travelling far, far way from planet Earth.
One of the most important questions we have to discuss is: why episodes? Well, there are perfectly good reasons for that!
Probably the main reason is the time of development. We all know the situation when the development of an indie (or a mainstream!) project goes on and on for a few years. The devs keep making promises to their fanbase and the project release is constantly delayed and keeps on slipping for an indefinite period…
Well then, it’s different with us!
We have a perfect overview of the time of development for our project. Our slowest ship (game art) requires 4-5 months to prepare the required amount of art for an episode. In that case we better show the completed product now, rather than dragging the development for another few years. And if the game proves exciting for the audience, we will find a way to speed the development process.
The second reason would be finances… Game development costs money, that’s a fact. The artist must get his salary. We started using our own money, and now we have the support of our publisher. But until we are not sure about how well the game will be received by the audience, continuing the development for several years is very risky. If the gamers like our project and the game sells well, we will feel much more confident and will be able to work on the game faster.
As for the episode content, I am guided by the classical quests with chapter structure – for example, Monkey Island. The game is divided into several chapters, where each part is an independent logical fragment with its own goals. After completing the first chapter players face a new situation with new locations and objectives. And towards the game finale players open the entire gaming world and travel across all locations.
This is how all episodes of Odysseus are structured. Each episode is a separate chapter of the tale, and all of them are united by the storyline. Each episode includes about 4-6 hours of game play (and the price of each episode is fairly democratic). So having considered all pros and contras we’ve chosen this format.

Odysseus Kosmos – Developer Diaries #6

cabin

Hey there, friends! Welcome back on board of “San Francisco”, a huge spacecraft travelling far, far way from planet Earth.
And now let’s return to our tale of the game’s development.
As we’ve mentioned before, adding new interactions is fairly simple. But these also require hand drawn art content. Our lead artist Roman (also the second person in our dynamic duo of a team 🙂 ) and the game art deserve a separate story, but for now let’s just say that graphics creation is far more complicated than game assembly.
Therefore each episode is first created using placeholder graphics (which sometimes looks quite funny). Later on we gradually replace placeholders with final content.

old_01

The entire process of an episode creation includes the following stages: first we think the current story part through once again. I’m writing down locations required for this chapter, mini games, items and animations that we have to prepare now and which of these should be created first. At that time Roman is already drawing the first location (this is a very time-consuming task that takes a few months to complete).
Next I’m thinking the episode puzzle scheme through. What will the episode flow look like? What puzzles will be solved, which items collected? The answers to these questions turn into a huge document with dozens of pages. We may call it the “technical scenario” of the episode.
Next I’m assembling the logical part of the game using placeholder graphics (which I’m drawing myself, as I wouldn’t want to distract Roman) and writing the interaction script based on the technical scenario.
In result I have the alpha version of the episode that can be played through to the end but without mini games, dialog texts or sound and with placeholder visuals. But at that point we can give the build to QA specialists to get an idea of how much time will the episode walkthrough take and check the global logics for errors. We can even rework some of the puzzles, get rid of the unwanted ones or come up with new ones (which I’m actively working on by the way).
Here is an example – a placeholder mini game that was taken from the game finale. The player goal was to look for repeatedly appearing asteroids.

asteroids

As final art is completed I’m adding it to the game, replacing the placeholders, writing dialogs and in-game texts at the same time and scripting mini games in between. We’re ordering sound effects and additional art from outsource sound engineer and artists. This is how gradually the alpha version turns into a nice looking finished episode that will shortly become available to our fans!

training_room

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.

 

 

Odysseus Kosmos – dev.diaries #4

san_francisco_600x200_v2

 

Hey there, friends! Welcome back on board of “San Francisco”, a huge spacecraft travelling far, far way from planet Earth.
And now let us continue the story and focus on our spacecraft – “San Francisco” for a while.
“San Francisco” is a huge scientific spacecraft crafted by the entire human kind along with StarGaze corporation. It has been sent to the Gargan system with a specific goal. Its dimensions are 0,19×0,056×0,05 mi. The ship is equipped with propulsion systems and an experimental hyperengine. Potential practical distance of the engine is unknown. Battle weapons are not equipped. The spacecraft is designed for long periods in conditions of full autonomy.
Imagine yourself aboard a modern submarine completely alone… that’s what it would be like. Apart from the fact that our hero knows a lot about engineering and the spacecraft design and there is nothing but boundless deep space outside the windows. The ship is huge! There are hundreds of rooms and bays. Some of these players visit more often than others. Plus not the entire ship is accessible right away – not only due to the game logic, but also to picture the feeling of loneliness, endless space outside and this huge ship that became a home for Oddy. We are trying hard to capture these feelings.
There are residential areas, crew quarters and technical rooms on the ship, as well as large storages and navigation bays. The wardroom stands out in particular as the favorite place of the crew and the largest in the residential part of the ship. What a view!
A few words on the realism. Naturally, we are aware that in a hundred years space travel like that can stay a fantasy for the human kind. The game features a few fantasy conditions such as artificial gravity. But it’s a sci-fi game and details like that are required for the sake of an exciting story!
Next time we are going to talk about the technical and organizational sides of development.