AQUABYSS

Developer's MiniLog history

November 15, 2021
A brief update on the situation. It's been a while and the beta tester team is, you guessed it, testing the game ;-) Their enthusiastic response made us very happy and motivated us to work even harder to fix everything they reported and let you play the game at the end of December. The deadline is a heavy burden, but we are doing our best to meet it!
May 13, 2021
Nothing like a late log entry. But as they say, better late than never ;-)  Some time ago a couple of enthusiasts from the German Amiga community contacted me, asking about a German version of the game. A poll was even created to get an idea of the interest in localization. The result was rather obvious—the vast majority of people even made it a condition to buy the game.  There was, of course, a plan to release a German version, but only some time after the official premiere. However, it would be hard to refuse one of the biggest groups of Amiga fans in the world, so we decided to translate it earlier and release both versions simultaneously.  Some may think that translating a text is a piece of cake. Well, in the case of AQUABYSS it's a piece of rock. There are many reasons to say that. Firstly, because of the large amount of text and its complexity due to branching dialogues (see the log entry from April 1, 2019 for more info). Secondly, because of the considerable linguistic differences between English and German and their significant impact on the display of text on the game interface (which is already finished and adjusted for short English expressions). Thirdly, because of the method used to create the dialogues in an external editor and the part of the text hard-coded into the game. There are a few more arguments, but despite the challenge, work is already underway :-)  This additional task is supported by donations, for which some of you have asked several times. The amount that has been raised so far is rather symbolic, but the Studio appreciates every gesture on your part, so thank you very much to everyone who makes the effort. If you are not registered on the German-speaking forum a1k.org but you would like to support the Studio, here is the address to which you can make a donation: https://paypal.me/agedcode | agedcode at gmail dot com Thank you in advance!
November 5, 2020
Good news!  Kevin Saunders, a truly great graphic artist joined the team and is working intensively in support of the project. He has already shown some concept art that perfectly matches the present graphic style. Couldn't be better! BTW, the illustrator position is also being taken (by an outside of the Amiga community member).  A few words from Kevin:  Great to be part of "Aquabyss" and see this new game come to life for our favourite platform - The "Amiga". When I looked at how long the game has been in development and how close it was to being released, it was a pretty easy decision to help out :-)  After getting a great behind the scenes preview of the game I have to say I'm pretty excited to see a game like this in 2020: Halfbright mode, OCS/ECS and funky steampunk look and feel makes this game certainly unique. The Amiga platform needs more Simulation/Strategy games such as this and looking forward to bringing this to life with Peter who is great to team up with, professional, friendly and passionate.
October 22, 2020
As announced this entry log is special because ... Today is the fifth anniversary!  Exactly five years ago, 22 October 2015, at 10:14 p.m., the very first lines of code were written and saved on my Amiga computer. However, if you follow the log you may recall that the game itself didn't start on Amiga. It reaches as far as 2002 and a different platform—the PC. But that's a distant history. Despite the Amiga's serious hardware and processing power limitations, the game has evolved into something much more advanced, and hopefully, more interesting. Five years seems like a long time, and indeed it is. But in game development, not so much. We have lots of examples out there where even a "simple" game (in quotation marks because from a developer side there's no such thing like a simple game) sometimes takes a ridiculous amount of time (yes, we hear ya! ;-)). AQUABYSS is not the most complicated game but it's definitely far from being simple. Needless to say, five years (from which we should take out some year and a half, if not more) for its development isn't much at all. We would gladly take a year or two more but postponing the release date is not helping at all anymore. Speaking of the release date...  There is good news and bad news  Let's start with the good news. The game is almost finished! YAY! If everything goes as planned then the programming side of the game, in general, will be finished in just a couple of weeks at most. By stating that we mean that no new features will be added, only some tweaking and elimination of bugs. The plan is to release the game in December this year! But there's at least two IFs.  As they say: No rose is without a thorn. The bad news is really bad, and sad. I suddenly lost contact with a great pixel artist I was working with. He was able to deliver some work but then something happened and I got no more emails. It was in November last year.  The above had some impact on the game. As you can guess we're lacking a pixel artist that could finish the work. Personally I will deal with part of it as I did so far (portraits and some missing interface, maybe more if time permits) but with other stuff someone else will have to deal with. Here it goes, an open proposition: We are looking for a pixel artist and a comic book/graphic novel illustrator  If you are an experienced pixel artist, or comic book/graphic novel illustrator (we need both) comfortable in Victorian/steampunk style and would like to join to help finish this project, then do not hesitate to contact us at: studio at agedcode dot com. We'll discuss the details in private.  The other bad news is related to beta-tests. In the recent past, due to a specific development phase, it was impossible to test the game (many things have been added and tested internally only). It means that if we are to release the game in December then there will be very little time for beta-tests.  A question for you dear readers: Would you like to be able to play the game in late December (where most will have free time and Ami-nostalgia intensified ;-)) or would you rather give it up and wait a couple of months more?  In the former it would mean that more bugs would have to be eliminated after the game is released. They shouldn't be a big deal but still, less time for beta tests equals more bugs and possible player frustration (which every dev wants to avoid). It's simple "physics". Postponing the release date by a couple of months would bring more comfort both in eliminating bugs as much as possible and polishing the game. But this stick has two ends. Five years is a lot of time and the work should already bring some reward and relief. This is not just a hobbyist project, it's a fully commercial one oriented to bring profit (we're aware that Amiga market is very tiny and won't make anybody rich but stil...). Other than that, no developer is ever happy with his current version and always thinks that there's a place for a fix and that something could be done better. So sometimes the best solution is to just release the game and work with the community in perfecting it. But that requires a comprehensive player that is willing to help, not to destroy the developers for their mistakes. In which group you're in? :-)  Please leave your comments on EAB or a1k.org* forum (preferable), or post a link to your local discussion of the topic on one of the aforementioned. *In order to access the a1k.org forum one has to be a registered user.
October 18, 2020
After another long absence of a new log entry, this one will only announce the next one, a special one, which will be published ... this Thursday! Come back and find why :-)
May 9, 2020
Many have been wondering and some have been asking about a new entry log, so it is definitely time for a new one.  There are a couple of topics to cover but this log will go deep into the hardware requirements. If we look above we'll read a "magical" statement: "Since it is still in development, we can only tell estimated parameters". And during the development, that often changes. Why bother and publish such information in the first place? Well, that is a very common practice between game developers. Almost every studio on different platforms does that and Aged Code is no exception. The devs initially are able to tell what configuration is needed to run the present build and most probably a couple of next ones, but nobody can be 100% sure whether it will stay that way until the release date. And since the game is still under development it should be perfectly understandable. Nevertheless, the interested ones always appreciate any information regarding the project, even if it's just an assumption. We hope you are one of them :-)  Memory  The minimum estimated requirement was 1 MB Chip and 4 MB Fast. Let's take a look at the following screenshot that represents current use of memory for the 0.9.990.1W build:  As we can see (yellow frame) it takes slightly more than 1 MB Chip so at the moment it is not possible to run the game on Amigas equipped with only this amount of Chip RAM. But don't be worried! The 1 MB Chip goal has not changed and we'll do everything possible so the final version could work on your Amiga (assuming of course that it has sufficient Fast RAM). Some cutbacks will be needed, but they will focus on things that are rarely used (like options screen for instance), and of course they won't affect the gameplay—both versions will have the same unchanged mechanics. As for the Fast RAM it is closing to the 4 MB but there is still a free margin for the things not implemented yet so this shouldn't be an issue. Again, we'll do everything possible to keep it that way because we know that the only expansion some of you have is that of 4 MB (one of my A1200 has a Blizzard 1220/4 and I'd like to see it working on that configuration, too). Naturally, like in the case of an extra Chip memory (2 MB), having 8 MB Fast will make things easier—there will be no need to destroy graphics during location change (among other things) and thus, it will speed up this often used element of the gameplay. One more thing: the game requires contiguous memory so any combination of expansions with an addressing gap will not work.  CPU  Although part of the game works well on a 68000 7 MHz, there are elements that require more, sometimes much more, especially the first time running—such as decompressing and loading the resources. If you go to the entry log of March 19, 2019, paragraph three, you will read that this question has already been partially addressed. However, lots have changed since then. In the first place, we resigned from the simple economy. The reason is trivial: because we can not work on both systems at a time and the latter is scarce. The goal is to release the game as soon as possible, so this decision has been made in order to accelerate the process. But that actually is a good thing because the real economy is something that changes the game from being dull and repetitive to being more alive, unpredictable and challenging. And because of that, you can take granted that no two playthroughs of the game will be identical. Isn't that a good thing?  "But hey! Didn't you say in that log entry about some electrifying 68060 CPU requirements so the real economy could work? Does that mean it is now the minimum CPU requirement?" Absolutely not! The good news is that after a long, intensive and tiresome optimisation it now works on a 68000 7 MHz! So this element of the game is no longer an issue. However, the real bottleneck is the sea part, or to be more precise—travelling. If you would look at it you would probably say that "it's nothing special, it's just moving dots on a map. I've seen games with more visual complexity and they still worked fluently on a bare 7 MHz". But you wouldn't see what happens when the time flows faster. Let's explain.  When submarines move—both the player's and the traders'—time accelerates like crazy and during that process lots of accelerated calculations have to be made. So, basically, when you are in a city (or idle at sea) the time flows normally and there is no need to do heavy calculations. And for that the basic 7 MHz is just fine (granted, you would like to have some more megahertz for faster processing of some elements like dialogue, article browsing or switching locations, but that's not a CPU killer). The true killer is real time geo-positioning for both the player and traders, traders' actions, dialogue and events checkings & executions and, on top of that, the aforementioned economy processing—production and consumption calculated for every city and every single article. Each of these categories have a bunch of subprocesses that need to be dealt with when the time runs like a speedboat. Let's be honest—asking the old poor 68000@7MHz to do it all is abusive. Of course it does work and it is playable but you'd have to have "the Amiga user patience" ;-) (pun intended). Nonetheless, it's all there and it works on our wonderful old but gold Amiga, whereas you would need some gigahertz on a modern PC in order to play such a sophisticated game! (Alright—I've exaggerated—but surely you've got the idea :D).  There is something else that can help us understand what we're dealing with. Every NPC trader in a game is practically like another player. So basically it is a "multiplayer" game and that requires a more powerful CPU. Let's see what they really are:  Every one of them has a personality with lots of attributes. They own a ship, exactly like the player does. These are the ships available throughout the game, not simplified ones. They undergo almost the same rules like the player: that is, they do not dock to cities that are too deep for their ship's hull endurance. They do not buy more goods than their cargo hold can store. With time they do upgrades of their ships and even change them completely. They can take city contracts. If they can't sell certain goods in one city they will choose another one where they can. Their geographic position is calculated exactly as of the player—no shortcuts there (that's heavy). The speed they travel on is based on their submarine class, engine installed and is affected by the cargo hold tonnage (e.g.: two of the same class vessels equipped with the same engine can differ in speed if one's cargo hold is empty and the other one fully loaded with merchandise). Now imagine, when a new game starts there are over twenty of them actively working and more and more become involved while the game progresses!  Someone could think: "Why bother, when the game could be simpler?". Yes, it could. But it would not give the opportunity of becoming multiplayer! Whoa, hold your horses. It is not multiplayer yet and it won't be on the release date. Even though it won't, part of the game's mechanics is being done with that in mind in case the community likes this idea and supports it in future. Personally I'm very excited when I think of a "massive" Amiga multiplayer game because, to my knowledge, we have never had such a game and definitely no game with that many possibilities.  Having said that, we hope most of the Amiga players will appreciate the fact that on their favorite computers is coming a game that uses almost no compromises in order to deliver modern solutions unthinkable some thirty years ago, even if the price will be a more powerful Amiga. Let's make use of all those new accelerators! =)  Hard Drive  This part is very interesting. I ran some tests on different configurations, so let's see how long it takes to get to the main menu in the game (again, for the 0.9.990.1W build):

	CPU:	Time (in seconds):
Amiga 1200	Warp 1260 100 MHz	8 s
Amiga 600	V2 68080 92 MHz (x13)	8 s
Amiga 1200	Apollo 1260 66 MHz	11 s
Amiga 2000	GVP 68030 50 MHz	13 s AT-Bus IDE 2 MB/s
Amiga 1200	Blizzard 1220/4 68020 28 MHz	17 s FastATA 8 MB/s | 18 s onboard IDE 1.7 MB/s
Amiga 3000	68030 25 MHz	18 s SCSI 3.3 MB/s | 19 s SCSI 1 MB/s
Amiga 600	9Tails 68020 28 MHz	18 s
Amiga 500+	Wicher 508i 68000 50 MHz	23 s
Amiga 500+	Wicher 508i 68000 25 MHz	30 s
Amiga 600	A6095 68000 7 MHz	1 m 22 s

Although these were not strictly scientific measures (just a timer in hand) they clearly show that loading the data is CPU dependent. On the one hand, it may surprise to see the results given from FastATA against the slow onboard IDE controller (with respective transfer speeds 8 MB/s versus 1.7 MB/s [both measured under SysInfo]). On the other hand, however, this further confirms how much it is based on processor power. Therefore, I think that we can safely eliminate the requirement of a fast hard drive, which is very good news for everyone. Let's strike through FastATA. Stay safe & healthy and until the next record :-)

October 26, 2019
This entry will explain how the main interface is composed and one of the city's locations. As can be seen above we are in the Market. It is one of the five locations that can be visited during the course of the game. But let's start with the upper HUD interface.  PLAYER'S DATA This panel shows current level, reputation, experience and funds. Level. Nothing much to explain really—a classic level up system based on experience points, which are acquired by different actions like completing a contract, fulfilling a quest or other efforts made by the player. Reputation speaks for itself. Player's reputation is built up (or down) during the course of the game. Having a negative reputation will block some possibilities and contacts, but will open some that are inaccessible for a positive reputation. Nihil novi in the RPG system. Funds are represented by the verns—monetary unit in the AQUABYSS' world. There are different ways of getting it and trading is just one of them; others are awaiting to be explored.  CITY LOCATIONS Present city. Simply shows the name of a city the payer docked his/her ship to. Market is the first location on the interface. It will be the most important one for those who will choose goods transportation as a base for their income. The prices are dynamic and depend on many factors like the city characteristics (economy, tech level, population) as well as on some unforeseen events. Next to the Market is Shipyard. It's also a very important location; after all, it's there where the player will be able to upgrade his submarine or eventually buy a new one. What would be a city without the Police? To keep law and order there must be a police presence. Among other things, they make sure the player keeps up with the contracts and hunts with a valid license. Those who break the law better make sure they know what are the consequences ;) Bar is a place where most of the NPCs can be met. It's there where the player can look for a task or get an update to the market prices from a distant city. In the story mode this place will provide many clues on the plot.  And last but not least, the Dock or the Docks. It doesn't really matter if it's singular or plural. What does matter is that only from this place the player can dock off of a city and start his journey across the deep. Without the harbour master's permission nobody can enter or leave the city. Date and time. A date like a date and time like a time. It flows forward and can be sped up if needed. Pay attention to it if you have taken a contract or a task that requires fulfilment before the deadline!  Another integral to the main interface element is the LogBook. It can be opened practically from anywhere. This panel provides the player with many log information so if your memory is short this is the window that you should open very often :)  Getting back for a moment to the Market. Most of the description speaks pretty clearly. What might need an explanation is last best known prices. How does it work? Well, if the player visits the market in another city, then his price log is automatically updated. Same thing happens when the prices are being acquired from another trader. This lets the player compare the prices in the present city against the others and make the best profitable decision. However, those log prices can become obsolete so make sure you have them frequently updated!  On the same panel there are red or green lights indicators (near the Depth header). It quickly shows the player if his actual submarine is capable of reaching the depth where the corresponding to the price city lies. If it's green then he doesn't have to worry but if it's red then only the hull upgrade or a completely new ship will be required to get there. Also, pay attention to the current tonnage level on the city's side. If it's low then the prices are higher, which can be attractive for sale, but not for buying, and vice versa. If an article is produced by the city it will have the lowest price possible, like in the case of Paris seen here where the cosmetics are produced. That's all for this log record. It will be some time before the next one, but we'll try to write something when we have a lot of new information to share.
October 20, 2019
So, you have been waiting a long time to see some update in this log. How about, instead of another text message this time we show you in-game screenshots? :-). We hope you like the form and style. Just bear in mind this is WIP [Work In Progress] so expect some changes (in fact, those screens have been taken back in July for a German magazine). Although the images speak for themselves (up to some degree), in the next entry we will explain in details what function perform some elements. Another update should come within this week (promises, promises!).
June 6, 2019
A quick update: Due to some family matters and abroad travel (not to mention prolonged health issue), the code has not been touched for almost a month. However, during that time there was some significant progress with the game's graphics. The development goes on...
April 7, 2019
As there were two editors mentioned in the previous entry log, we will describe the others in this one. Those who are not interested in the technical background of game development can immediately skip this entry, because they will be bored (although here and there appears information directly related to the game).  You are already familiar with articy:draft3, which is one of the two third party editors fundamental to the creation of the game. All others have been written for it, and they are as follows: the already mentioned importer/converter/ Dialog simulator, City and Ship editors, NPC creator and Map editor (these are the main and the most extensive tools apart from a few minor tools).  City Editor  Google Earth Pro (the second editor from a third party) is used to place cities on the seabed around the underwater world. Its data is exported to the xml format and then imported into the City Editor. All the other features of the cities are added there, including those mentioned in the entry log of March 19, and in addition to them several other options related to the locations in each city. However, the role of this editor does not end there. It also contains a list of goods and their prices in each city and the whole economic system (exactly the one from the game), on which we can test and simulate any changes introduced. Graphical charts and some functions allow us to compare prices in different cities and see possible profit. Although the editor does a very good job it is the human that in the end approves all the data. Price in economic games is one of the most difficult things to balance, so we make every effort to achieve the best possible result. A little spin off that is actually related to the Ship and Map editors: Why Google Earth Pro and not something simpler? Because the game world, i.e. the map, journeys and locations take place on real geographical coordinates. Of course, it would be much easier to put everything on the flat X and Y axes, and this variant has been tested. However, using real latitudes and longitudes allows for much more: One pixel contains a certain area, which gives a lot of possibilities. For example two or more ships can occupy the same pixel but in fact be at some distance from each other. You can also see different speed of the submarines, that are not artificially slowed down, which would have to happen in the "flat" version if their move was based on pixel coordinates. Distances between cities (and spots on the map) are not contractual but real (they cover with those of Google Maps or Earth Pro in at least 99%). Is there an Amiga game using similar latitude/longitude method? We would like to know. If not then this one will be different. Whether it is good or not, will be judged —as always— by the players ;-)  Ship Editor  Not only ships are created here, but also their basic components: engines, hulls and devices. A certain level of physics is applied, thanks to which the change of engine or hull parameters affects the speed of the submarine (with or without cargo), and the whole can be seen on various charts. Additionally, the value of these components, as well as of the whole ship is automatically calculated, which is then reflected in the game itself. One of the locations in cities is the shipyard, but not all cities have it. Each shipyard specializes in the production only of certain ships, engines, hulls and equipment, so buying a specific model is associated with the discovery of the right city.  NPC Editor  Basic characters are created in articy:draft3, but all the rest of their characteristics are given to them under a separately created editor. Each of them has way more than twenty parameters, which we hope will enrich the interaction with them. These, among others, include the city of origin, reputation, work (this in turn is divided into two shifts, which means that e.g. the employees of the captain's harbor master office who give permission to dock and leave the city change depending on the working hours); others are: attitude towards the player, willpower, likes, friends and/or enemies, side tasks, etc. This editor also simulates possible conversation outcomes based on different level of the player's attributes.  Map Editor  The decision to use real geographical coordinates was made at the very beginning of the game development. Considering the power of a 16-bit processor, this choice may seem strange. Of course, it works better on a processor that is a bit faster than 7 MHz, but in our opinion the benefits are worth it. In addition to the above mentioned in the spin off to the City Editor, another is the fact that the map of the world is based on a real map, and this is very valuable for education (you can always explain that you not only play, but also learn the map of the world! ;-)). For this purpose the Mercator's projection is used. But as the whole, action of the game takes place under water, a bathymetric map of the seas and oceans was also used as a reference. In other words, the depths are also reproduced, although of course in general outline and with some compromises. The map of the world at the moment is quite large: 8192 x 3982 pixels (more than 25 width and 20 height of the Amiga Lores screen which is being used in the game). However, it will probably be reduced by 50%, as travelling longer distances can be tiresome (this is still being discussed with betatesters). Making such a map is very tedious and takes a lot of time because of the limited colour depth and the world at such resolution, although not complete, is still huge: full east-west width and up to 70 degrees north and 60 degrees south. This editor loads all the map chunks and helps us see how it will look and work in the game.
April 1, 2019
Although AQUABYSS is not a typical representative of the RPG genre, it requires some kind of dialogue system. At first it was supposed to be a very simple system with dialogues included in the main code. But soon it turned out that this method, as well as the plot, required something else because it quickly resulted in a very hard to follow headache-causing mess. It was a no-go. I started to look for a ready-made editor that would solve this problem. Unfortunately, free editors offered very simple features, and even paid ones did not impress. As several editors have already been created for the game, I decided to write this one as well — but then I came across an editor previously unknown to me. A professional piece of tool: articy:draft3. I fell in love and decided that there was no point in reinventing the wheel. Of course, this meant that the time spent on creating the previous editor was lost forever. What's more, there had to be written another editor that could import, convert and simulate dialogues created under articy:draft as if it was on Amiga, because the raw data by itself could not be used on it directly. But the change and additional work was worth all the sacrifice in a way, because such a sophisticated editor with many possibilities "forced" the creation of a better dialogue system.  But here began the first obstacle — performance. The implementation of a LUA-esque scripting language was out of the question because the requirements for the dialogue system alone would be very high, and the condition I set myself was a 68000 7 MHz processor. After doing some research I concluded that there was no other option but to write such a system myself and check its performance. It took some time, but the effect is a reasonable speed of over a thousand dialogues (including dialogue groups) on such a 7 MHz CPU. Of course the next dialogue does not appear immediately, but considering their number, as well as the processing of many scripts during the search for the possible nodes, the speed is satisfactory (however, in the end it is the players who will judge whether this is really the case and not us, the devs ;-).  What characterizes this system? Creating dialogues and branching is practically unlimited. These can take place simultaneously between the player and one or more characters, with or without his participation. There can be set several alternative answers, loops, returns or jumps to the chosen dialogues, as well as dynamical removal. The dialogues can be grouped into external packets and easily exchanged during the game, in theory increasing their number endlessly. That's the structure, but there are also scripts.  Each dialogue and dialogue group can be scripted. Here are some examples of what can happen during a conversation: A player can pay or receive money, gain or lose reputation points, gain experience points, receive or complete a task, receive or give an item, or influence someone's attitude. Additionally, a display of an image or a whole sequence can be triggered, or even certain technical parts of the game can be manipulated, such as switching on and off graphical element(s) . . . and the list continues. Some dialogue lines appear only if the player has the appropriate level of an attribute, such as TRADE. If he is offered a task or an item to buy, the player can pay the required amount or bargain by selecting a special dialogue line related with the aforementioned attribute. Success depends not only on the level of that attribute, but also on the characteristics and current attitude of the NPC with whom the conversation is in progress.  This description could continue, but I try not to forget this is just a mini log :-) Finally, I'd like to show a little sneak peak. On the following screenshoot we can see how an exemplary conversation layout looks under the articy:draft editor. In this case it's a generic dialogue used for a conversation with practically any NPC in the game (just remember what has been told about spoilers so do not expect too many details, only a general idea):
March 24, 2019
Just a quick update. There was an old part of the code that was creating a nested loop and thus lots of CPU throttle (essentially a bug, but with such a huge piece of code it's very easy to overlook something despite ones effort). So no 060 needed anymore for the real economy option ;-)
March 19, 2019
Was there a game in the past on the Amiga that would compare with AQUABYSS? One can find many similarities to some, which is not a secret, but we cannot recall just one game that could resemble all its elements. Is that a good thing or it is not? As with everything in our life people's opinion are different. In ours there is a place for every type of game, especially on the Amiga market. How could we describe the genre of this one? With just one word it'd be difficult. See it for yourself: It has elements of trading, exploring, adventure, RPG, upgrading, quests and deals, as well as achievements (we hope that players will want to share publicly with others their statistics and achievements motivating that way to some funny competition :-)).  With so many aspects of the game, it would be nice if we talked about [at least some of] them. So in this entry we'll look at trade, economy and cities. As mentioned before the goods are produced in the underwater world by cities themselves. Not all cities produce goods. But those that do produce only some of them. This allows them to coexist. That of course means other goods have to be transported from one city to another. There are twenty two different articles: from the cheapest one —coal— to the most expensive —machines. We're doing everything possible to make use each of them in gameplay. How? Let's take as an example coal, scrap metal and iron ore — the cheapest merchandise on the market. Selling them will not make you rich so why bother and not to sell more valuable steel or even the most expensive, machines? Well, you can buy steel but first a city needs to produce it. In turn, to produce it the city needs the proper resources which are, yes, you guessed correctly, coal, scrap metal and iron ore. Of course you may leave that to other merchants but if you engage personally then you may change the outcome for yourself (unless some other mean trader will buy half or all freshly produced material from under your nose ;-)). Other option for those cheap commodities is signing a deal with a city that is in need of them. Of course you'll need a certain level of reputation in order to be accepted as a contractor. But apart from making some verns on selling those resources to the city you'll get an additional contract payment bonus! But there is a catch: you'll need to deliver a predetermined number of tones of the specified raw material before the contract expires. Otherwise you'll get less or even nothing, as well as you'll lose some of your reputation. As to the machines they will not be manufactured if there is no steel. So as you may see, dear reader, buying and selling just one type of merchandise is not that simple.  Speaking of the economy in the AQUABYSS' world, how does it work, you may ask? There will be two systems available to the player's choice: real and simple. The real economy is a set of very complex mechanics. But don't worry, it all happens "under the hood" so there is no need to operate it manually nor study intricate details. All you need to know is just the basics that are no different than the world we've lived in for the last couple of thousands of years: buy low, sell high ;-). In the real economy there is no R[andom]N[umber]G[enerator] involved — all prices are shaped by traders (and the player, if he decides to participate in this profession) as well as events, city population and city characteristics. Speaking of the latter, every city is represented by: Economy, Technical level, Security and the aforementioned Population. Cities "consume" goods so also the current tonnage, be it low, normal or high (it's actually very fluent, not just those three states) determines the final price. The whole economy situation is saved to the save game so it accompanies to the player for the rest of the game. But there is a price for such sophisticated economy system — CPU power. If you own a fast turbo card and have been disappointed that there is so little games taking advantage of it then you shall be pleased. The tests have shown that only the fastest Motorola CPUs can handle it in real time, and we're speaking of 68060 or the FPGA implemented 68080 (it may work tolerably on 040 but wasn't tested yet, so it's difficult to confirm or deny it at the moment; of course the requirements will have to be updated, especially recommended requirements, but for now they will stay as they are). Does it mean the whole game needs one of such powerful processors? Not necessarily. Generally you would need it only for the real economy option. There are other elements of the game that can make better use of a faster CPU but they are not that power hungry; and they are as follows: the merchants-NPCs system (AI: travelling and trading), sea events and dialogue engine. But because the game is still under development we'll have to wait for the final verdict...  In the next entry we'll talk about the dialogue system.
March 9, 2019
Oh, time flies sooo fast! It's been almost two months since the last entry log. But that doesn't mean development has been on hold. On the contrary, the project has been worked on intensively (above you can always find current version of the game and its date).  Where were we? Ah, yes — spoilers. In order to avoid unnecessary temptation for those who don't want spoilers, there'll be none of those on the storyline — not before the game is released. That decision stands. But... Let's gather all the information that has been given so far and add some new info...  First of all, we've been told that the action of the game takes place in an underwater world. There are cities on seabed located on different depths. Cities exchange goods, and some cities also have their own production, which can give better prices for the buyer. There are non player characters [NPCs]. Some of these are traders. But the trading aspect is not limited to NCPs only — the player can also choose to trade in order to create profit. There are possible dialogues with NPCs. The player has attributes so there must be an RPG developing system. There are submarines and upgrades. Finally there is a storyline linked to uncle Jules and, with time, to some other characters — be it related with the main plot or side quests. It's been said twice already that this is a sandbox game — an open world where the player has free will to choose how to make his living there. After some mandatory storyline script introduction he can decide if he wants to follow the plot. Whether he chooses it or not, his action will impact his reputation, how he will earn his money, with whom he'll make friends and with whom he'll make enemies...  More info will be published in a week or so, so stay tuned.
January 15, 2019
I hate spoilers. Whether it's a movie, a book, a gift from a friend or an adventure game — I hate spoilers. A very best friend of mine is the opposite: He hates surprises! Yes, he will fast forward a whole movie to see what's going on in it — because he doesn't want to be surprised. Then he may watch it. That is a great example of how diverse we can be — even best friends :-). But as to me I've always hated spoilers and I don't think that'll ever change.  What does that have to do with the AQUABYSS game? Well, one of its fundamental aspects is the plot line; a story that makes of the game something more than just a set of mechanics. Although, as mentioned before, it is optional, some players will choose to follow it. That is one of the most vital reasons why there is not much information about the game so far. Another reason is that all the graphics aren't done yet. We're using some temporary pictures as placeholders, and some of them are copyrighted. Obviously the game can not be presented to the public in that state.  Alright, so myself and some of my mates belong to the "spoiler haters". How about those who don't care, those who like it all straight-revealed no matter what? I guess, to respect that group and let it decide, I could do some, just some, exception by revealing additional details. This will be done in the next log entry. Thus: Be warned, there will be a spoiler that will destroy the surprise for you! ;-). The recommendation is that you completely skip it if you want to live the story as if it was for the first time.
December 26, 2018
Hello, I am Roald Strauss aka Mr.Lou / Dewfall Productions; the musician of Aquabyss. I've been asked to tell you a bit about myself and my work with the tracks for Aquabyss, so here it goes.  My interest in computer music goes all the way back to the 80s, when I discovered that I could create music on my Amstrad CPC464 with SOUND commands and DATA lines in BASIC. After creating over 50 tracks on that computer, I moved on to the Amiga where I created more than 100 MODs with Protracker and 20 DBMs with DigiBooster Pro. (The full story can be downloaded from www.8bitMemoirs.com).  I also had a passion for hobby game development, and even managed to create a few cellphone games with my better half. Creating games and MODules for them was a big interest of mine. However, I was sad to see how game developers slowly started to turn their backs on the MOD and XM formats in favour of MP3 files. Not their fault of course, since all online music libraries seemed to only offer streamed formats. So, I decided to create IndieGameMusic.com to have a place where musicians like myself could offer ready-to-use MOD and XM files to game developers (while still offering streamed formats too).  Time flies. IndieGameMusic.com has been online for 10 years now, and during that decade I've had my music used in many games — but I never did any project work. That was an intentional choice because project work can be (and usual is) extremely time demanding and difficult — especially when the author of the game is passionate about his project. Nothing will ever be good enough for him. When you have a family and job to take care of, there's simply no time for such projects. That's why I prefer to create my tracks in my own time (with my own passion) the way I want them to be, and then offer those to whoever may find them useful. I still believe that's the best solution for all parties.  But when Peter reached out about MOD files for his Amiga game project "Aquabyss", it was difficult to turn him down. The challenge of creating something great with MOD files was too intriguing. Of course, after only a few weeks, I was reminded again exactly why I've avoided project for the past 10 years. ;-)  Peter is a prime example of a deeply passionate game developer who only wants the very best for his game in all aspects, which makes it extremely difficult to create something he's 100% satisfied with. But I'm doing my best to produce some high quality music for Aquabyss, and I hope the end result will bring you all lots of entertainment, and that the game will blow everyone away. [Peter: Well, maybe blowing away would be too high expectation but I'll be happy if people find it interesting enough to play it for more than just couple of minutes :-)]  Here's a preview of the music:
December 9, 2018
The idea of creating AQUABYSS dates back to 2002. As mentioned before, a couple of games served as an inspiration, and initially the background of the game was set in the futuristic scifi world. Although science fiction was always my favorite I felt it wasn't appealing to me with that force anymore. So I thought, how about joining scifi and history together? I didn't have to invent anything. Two well-known writers, considered by many as the fathers of science fiction, did it already: Jules Verne and Herbert George Wells. Their fantastic imagination inspired many people and Verne's novel 20000 Leagues Under the Sea and Well's short story In the Abyss impacted me most. Instantly I knew I had the world I was looking for... So what lies beneath that surface after all?  As you have probably guessed the action of the game takes place in the underwater world. Couldn't be any other way. Initially the game was simply called ABYSS but it seemed to be too common and not very distinctive. Eventually connecting Latin word aqua with English abyss have given the title you already know. It seems to reflect the game's environment perfectly: infinite depths of water. So what the heck is the game about?  If you connect Verne's novel and Well's short story you'll have underwater journeys and civilization. In the world of AQUABYSS there are cities built and populated by humans. Those cities are scattered on the seabeds. The goods they produce are transported by traders in theirs submarines trying to make some verns: the currency of the Aquabyss. In order to reach cities constructed on lower depths a hull upgrade or even a complete change of submarine is needed. Non player characters spend their free time in local bars where they can be asked some questions or even get a profitable task from them. Whether they'll talk to you or not depends on your reputation, the story, which is totally optional in this open world, or some RPG attributes that help to persuade interlocutor. (But to temper your reach imagination you won't see figures walking on a scrolling screen. You'll see only their portraits and static screens.) How does the player end up there, and what is his part in the story? Well, that will be explained on another occasion...
December 7, 2018
I'm Peter and I'm the founder of the Aged Code Studio. The announcement of AQUABYSS woke up a lot of curiosity and many questions. We've got a lot of positive feedback and we are grateful for it. Primary focus is on the game-developement but I will of course do my best to keep you informed about the progress.  You all are asking and guessing what's the game about? Well, I'll give you some clue but before I'll do that let me take a note on something...  Many of you, dear Amiga users, have your computers equipped with expansion cards with Fast RAM and even faster 68000 Motorola processors but still with only 1 MB Chip RAM. Old games dedicated to 1 MB usually did not require additional memory. We, at the studio, think that it would be a waste of this new hardware of yours if there was no new game that could make a use of it. And you have probably noted that minimum requirements to play AQUABYSS have changed. It is now a minimum of 4 MB of Fast RAM. But the good news is this change allows presently the game to work on 1 MB Chip RAM. There are still some features to add but the goal is to keep it that way.  I promised to give you some hint about the game genre. Let me tell you that inspiration for it was based on games like Sid Meier's Pirates!, Elite Frontier II, Freelancer, Aquanox and some other good games. However the game does not contain arcade elements and, as it was said on other occassion, it's not a 3D type. It's rather slow pace action where you can play it with a cup of tea or coffe and have some snacks.

Updated on 11-05-2020

Copyright (c) (2002)2015-2020 Aged Code | agedcode.com