Jump to content

Deadonstick

Members
  • Posts

    13
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Deadonstick's Achievements

0

Reputation

  1. About the Editor For a bit of context here, because I'll be expanding upon things like development stages aswell as my personal estimates for how long certain activities will take, I thought it'd be a good idea to explain a bit on what basis I make these estimates. I am a software developer. More specifically, an Embedded Software Developer. This basically means I primarily use low-level unmanaged languages like C and C++ to program hardware (like a microwave, a robot arm, whatever). Although this means I have a good grasp of more technical programming I must admit I lack knowledge of game development which generally uses vastly different paradigms, techniques and skillsets. Although I still believe I can give decent estimations; I am open to the possibility that my lack of knowledge regarding game development could mean I am off by several orders of magnitude. With that out of the way, let's get started. Preface I love Avorion, I really do. It's a game unlike any other that's tonnes of fun to play with friends. The shipbuilding system is meaningful and people can make amazing things in it. However I do believe that Avorion is going to head into a brick wall of critics with the current development schedule and won't stand the test of time. According to the Steam store page Avorion is set to be released in Q3 of 2018, also known as September. Development Phases For those of you who don't know the exact meaning of the traditional development phases: Pre-Alpha: Project is not yet ready to be formally tested, core features are missing and development is focussed on getting the core features working aswell as the software infrastructure. Alpha: Project is not feature complete although the core is mostly done, development is mostly focussed on adding more features and fixing critical and major bugs. Beta: Project is (almost) feature complete, development is mostly focussed on fixing bugs and polishing. Release: Project is done. Now admittedly with the advent of ubiquitous internet these development phases are often heavily abused. We've all heard of games being released in what used to be called Beta or even Alpha stages of development (shoutout to Bethesda). It's also becoming more and more common for games and software to correctly use these development phases but in an incremental sense. In the incremental sense every update/expansion pack/DLC goes through these stages seperately. So something like World of Warcraft will go through Pre-Alpha, Alpha, Beta and Release each xpac. Where is Avorion? Games like Avorion in Early Access are even more confusing in this sense. Avorion itself isn't yet feature complete and likely won't be for a while. It still faces some fundamental issues like the scaling issue: http://www.avorion.net/forum/index.php/topic,4528.0.html. Then there's also the issue of ship movement speed which makes proper PvP nearly impossible because an opponent can simply accelerate to 10KM/s to get away making aiming impossible and being able to rapidly outrange your opponent. Then there's the whole issue of anything outside of the galactic core rapidly becoming obsolete and dead content, drastically reducing the effective size of the universe. These are just some examples of relatively huge issues that require a fundamental change of how the game functions to solve. This isn't a case of bug fixing or tacking on extra content, these are fundamental problems with how Avorion handles speed, scale and space that keep it from being a great game. Personally, I believe these to be placeholder features and as such an argument can be made for Avorion still being in Pre-Alpha, simply because the core mechanics are so hilariously broken (in the "easy to abuse" sense of the word) that it's hard to see them in the final release. Then again, according to the official roadmap we are in Alpha.. The Current Roadmap https://avorion.gamepedia.com/Roadmap The official Avorion roadmap as you can see addresses none of the issues I've raised (and I'm sure you all can raise plenty more). So, assuming that Boxelware believes these issues aren't important enough to fix before the release that means we are simply missing a lot of features. This means we're in the alpha stage of development. As it currently stands it took 3 months to get from the beta release of the Economy update to the beta release of the Combat update. We know that after this Combat update II will hit, which focusses on graphical improvements mostly. So, we have til the end of Q3 2018, which is September, it's currently Februari so that means we have 7.5 months. Say it takes a full month for the first Combat update to go from beta to stable; 6.5 months remain. Then let's be generous and say it'll take a total of 1.5 months to beta-release, test and proper-release Combat update II; 5 months remain. Now let's be extremely generous and say that the entire rest of the roadmap can be done in a single update as large as the first Combat update (which took 3 months and say plus one for testing); 1 month remains. After this Avorion is feature complete and moves to beta-release. Assuming this very optimistic schedule that means we have a grandtotal of a single month that we'll be spending in beta. In this month every critical and major bug has to be fixed for it to qualify as a full release. The Choice As it stands Avorion is a decent game and I am confident that in the months leading up to the release the quality will improve further. I believe that with the current roadmap Avorion will end up being branded as a "fun game with a decent quality". I also believe that it will not stand the test of time. After all, there's only so much amusement that can be had by grinding until you have a ship so massive that no content is worth doing anymore. Multiplayer servers will die out over time because no meaningful interaction can be had between players. Either side in a PvP combat scenario can choose to disengage whenever, there will be no wars for resources because a sufficiently large ship can clear a sector far quicker than the enemy can respond, and most of the universe won't be worth visiting due to it being too low level. Following the current roadmap I believe that to be Avorion's fate, an amusing quirky creative game with some quality assurance issues that does decently well. Not exactly a worst-case scenario I know. But, then again, I believe that if the release date is pushed back, if the developers and the community look at Avorion's core features with a critical eye. If time and energy is spent in solving some of these fundamental issues that it can be much more than that. Avorion could be the first multiplayer X3 (already something that people have been asking for for years) with all the benefits of a voxel game. If Avorion manages to do that and do it well it'll be remembered as a true milestone in the pages of gamedesign. The first of its kind.
  2. I am currently struggling with figuring out how I can put these cargo shuttles to work. I know you can put them inside of a station and have them automatically (though very slowly) transfer goods to another station but that's not what I want. My use-case is as follows: I have a dedicated cargo ship that has to make regular trips to a sector filled with XXL mines of various types. I soon figured out that manually docking to each and every one of these stations and transferring the goods to my ship to then dumb them into a stationary cargo container (which is just a ship without engines because Avorion doesn't have stations that can be used as an all-purpose cargo containers) is supremely tedious. So I purchased some cargo fighters, put them in my hanger and assigned them to squads. I then figured I could remotely transfer goods from a targeted station but I can't seem to figure out how. So my question is, how do I use my cargo fighters so that I can empty out my stations without having to dock?
  3. With the current way gathering crew functions I'd think that hurting and killing crew is a bit of a dick move. Considering you can spend hours upon hours finally training a specialist to a high level just to have him broiled alive :P. That being said, a weapon that adds heat to the enemy ship is an amazing idea and a great addition to a proper overheating system. It can either be a seperate weapon like a flame or plasma thrower or a special type of block. This special type of block would allow you to extract heat from your ship and transfer it to the projectiles of whatever weapon is mounted on said block, essentially adding heat damage to your weapons. The amount of heat transferred shouldn't be too large though, to avoid undermining the entire point of the overheating system to begin with.
  4. Well I already found a bug and fixed it, so you may want to redownload it. I also added a seperate version for those of you on the combat-update beta branch. Word of warning though, although these modified events only occur approximately once every 3 hours (or every 2 if you have more than one player per sector) they are fully capable of converting any sector into a scrapyard.
  5. Love all of these changes. I do, however, have two pieces of feedback one major, one minor. The minor piece of feedback, you said: Which implies that the owner of such a ship can be everyone in the entire universe. What I believe you meant to say was anybody, which means that any singular person in that universe can be the owner, rather than the whole thing. Yes I know, it's very minor. As for the bigger piece of feedback: I feel like this update fails to address one of the fundamental issues with combat at the moment which is how scale is handled. As of current, a bigger ship is without fail always better for combat. I made a whole thread about it here:http://www.avorion.net/forum/index.php/topic,4528.0.html. But, long story short, meaningful fleet combat and player-defined ship classes can't happen until there is a real benefit to having a host of smaller ships in your fleet. As long as larger ships are the basically-indestructable-though-hard-to-turn behemoths they currently are it will simply take far too many smaller ships to make any meaningful dent. This problem is far worse in PvP because larger ships also have the highest top speeds and as such can simply choose to disengage whenever. Whilst I understand that this update isn't the final definitive update for combat I do believe this is an issue that has to be fixed as quickly as possible. In a creative shipbuilding game there's nothing worse than creativity being useless in the face of bigger numbers.
  6. That's a little contradictory, is it not? DPS assumes that an average is taken, and the cooldowns and whatnot are taken into account there. I think the problem lies not in wrongly assuming an ability to indefinitely sustain the maximum DPS peak, but rather in not accounting for the cooldowns in DPS calculations. I point you to the following mod: Ohm/DPS Calculation Display. It actually does take all these factors into account and gives very accurate numbers that more precisely indicate what you can expect of your Turrets. I propose that these calculations be integrated into the main core code of the game, and used for all DPS calculations. That way, derivative values like the omicron numbers and turret selling price based on DPS should follow suit automatically. DPS can be a measurement of peaks aswell rather than long-term averages. In EVE Online for example they split DPS into two numbers, one taking into account reload cycles and one that doesn't. Imo that should be the way DPS is handled in Avorion too. After all, depending on the health of your ship, one number might be more important than the other. A massive carrier might care more about what the sustained DPS of his opponent is whereas a more modest cruiser might only care how quickly this guy can vaporise him.
  7. Actually the way Avorion currently handles scale IS physically accurate. In space the square-cube law is king, which essentially states that the surface area of a ship (and thus the drag) scales with the square of the ship's size whereas the mass and engine-power does so with the cube of the ship's size. When you are totally physically accurate in this sense (and leaving aside material strength and heat resistance constraints) this means bigger ships are faster than smaller ships. Even more hilariously, larger ships are just as manuverable as smaller ships because the mobility items also scale in effectiveness by the cube of their size. In real life, despite mathemathically larger ships always being better, this is balanced through material strength and the inability to manage waste heat. You did give me an interesting idea though.. I believe balancing larger ships can come through the introduction of a heat-management system. In space in real life one of the issues you run into is managing waste heat. Although space is cold, it is also empty. Unlike here on Earth there's nothing to remove the heat from you and as such you can only get rid of heat by radiating it away, which happens only via the surface of your craft. This new system would mean that all blocks get rebalanced to properly scale with the cube of their size. That meaning, that disregarding the new heat system, a tiny ship that turns at 4 rads/s, accelerates at 4km/s and such will do so regardless of how far you scale it up. To balance this however each ship should be required to manage its waste heat. As your ship grows larger you'll gain the cube of your size in heat to manage but only the square of your size in heat you can get rid of. So say we take the ship "Tiny Terry" and scale it up by a factor of a thousand to get "Big Bertha", Bertha would have to get rid of 1000^3 (aka a billion) more heat but only has the capacity to get rid of 1000^2 (aka a million) more heat. This means that Bertha is now 1000^3/1000^2 = 1000 times more prone to overheating. In order to manage this she'd need to install a buttload of blocks that get rid of this heat or risk overheating. Overheating in this case means that your ship's efficiency drops when you get too hot, after that your ship simply stops functioning (think like in Mechwarrior). Overheating should be a function of power used. So that when you are in combat, zipping around, firing lasers, you overheat faster and you can cool off by turning off systems. Currently, the only thing perhaps preventing one from flying a ship as big as they can is the trade-off in how easy it is to fly. The ship gets a higher top speed but sucks at (de)accelerating and turning. But as I said, this is sort of a moot point when both mining and combat require very little of this due to turrets turning independently (not to mention fighters make it even less required). This proposed new system however will soft-cap the effectiveness of larger ships, eventually requiring you to replace systems with heat management blocks at a greater rate than the other systems grow in size. I say soft-cap because it'll still take a while for your ship to heat up and some people might still make insanely large ships that don't overheat as long as they don't fire and turn at the same time for example.
  8. Introduction Leaving aside all of the more specific complaints regarding combat and trading and such for now I believe there's a singular core issue that is the root cause of a lot of Avorion's problems. The issue I am talking about is the issue of scale in Avorion or, more specifically, the issue of how the player scales in size with regards to the universe. Scale Progression When a player starts his journey in Avorion he starts in a tiny mining drone. In this drone a single sector is a rather huge chunk of space and attempting to cross that sector can take quite a while. When you eventually do cross your sector you've probably found an asteroid that seems rather big and takes quite a while to strip mine. However we all know how it goes, before long every asteroid the game throws at you evaporates before your mighty mining lasers, every enemy seemingly blows up automatically, your cargohold is almost entirely empty because you simply can't find enough goods to buy from stations, you can let enemies fire against your mighty shields and armour for literal hours without fearing for your life and attempting to seek enough specialists for your capital ship is a lost cause. The Two Sub-Problems There are two sub-problems that make up the "player-overscaling" issue. The first is to simply have a more varied scale for the universe. Currently everything from the galactic edge to the core is (roughly) the same size, which is kind of a shame. The universe becomes more dangerous the closer you are to the core but not by changing its size, only by changing the materials of which it is made. This is a great progression IF the player followed a similar progression, but players grow in both material type AND scale. Having the universe do the same is, in my opinion, part of the solution. This essentially means having some asteroids and enemies large enough that even the most hardcore powergamers need some considerable time to deal with them. The second is that currently in Avorion bigger is almost always better. Bigger ships have the most firepower, the highest durability and (counterintuitively) the highest speed. The only thing that you trade away for a bigger ship is your turning speed (which is irrelevant for combat because turrets turn independently) and the price (but what else will you spend the money on anyway?). The solution is to this problem is difficult because you'd need to balance the natural health and firepower something of a large size provides with something else that a smaller ship would provide. Worst of all, this solution would have to work across all size ranges (which is a problem only Avorion has to deal with as only it spans such a massive continuous set of sizes). Conclusion Personally I believe that if solutions to these problems can be implemented properly we have opened the way for meaningful fleets. Fleets consisting of various sizes and specializations that truly test the creative and planning abilities of the players. It would make ship design more meaningful and allow us to move away from the slew of "jack-of-all-trades" ships Avorion currently consists of. And, of course, it would mean that the player can feel like a part of the universe again. A universe that is grand in scale and in variety of scales. Rather than the current reality of the player feeling like an untouchable God annoyed that his ship is so effective that most of his time is spent trying to find a sufficiently large asteroid to mine or for his GODDAMN JUMP COMPUTER TO FINALLY FINISH CALCULATING. However, the implementation of a solution to these problems is difficult and I cannot casually figure one out currently. Hence why I am asking everyone here, including the devs, to think of a viable solution for this terrible issue that is haunting us all. Except of course for those who love roflstomping the entire universe and feeling huge, which, I can get too.
  9. Omicron is a poor representation of weapon efficiency. In one of my playthroughs I ended up with a few million Omicron because I had supremely powerful Railguns with burst-fire, unfortunately they would overheat after three volleys and needed to recharge for a minute. The Omicron unit assumes that you can indefinitely sustain whatever the maximum DPS of your turrets is. In my experience the most powerful turrets tend to not do sustained fire very well.
  10. GitHub Page: https://github.com/Deadonstick/avorion-commands Original Author's GitHub Page: https://github.com/nthirtyone/avorion-commands The original version of the Avorion Commands Package was made by nthirtyone and added a bunch of cheat commands for the player. You can read all about what the original package offers on the GitHub page listed above. As for my version, it simply adds a single command that I found to be missing in the original version; the ability to instantly fill your ship with a maxed crew. A maxed crew in this context meaning a crew of maximum level specialists that will have your ship operating at peak efficiency (100% or 130% when applicable). This removes the tediousness of having to find or train high level specialists yourself, especially for huge capital ships. Full disclosure, this command replaces the original crew. Installation: Dump the scripts folder into your Avorion scripts folder. Usage: Type /crew epicfill when in game. avorion-commands.zip
  11. Nope unfortunately not. This is my first time using the forums and I accidentally uploaded twice.
  12. Github page: https://github.com/Deadonstick/avorion-extended-xsotan-attacks This mod adds two additional xsotan attack events, both much harder (and rewarding) than the default four in the base game. It also increases the firepower of large Xsotan ships in the entire game. The larger the ships get, the more turrets they will carry. In addition to the default four: [*]"More strange subspace signals, they're getting stronger." (Small group of Xsotan ships) [*]"The signals are growing stronger." (Normal group of Xsotan ships) [*]"There are lots and lots of subspace signals! Careful!" (Large group of Xsotan ships) [*]"The subspace signals are getting too strong for your scanners. Brace yourself!" (Larger group of Xsotan ships) I have added the following two that occur less frequently and only when you are close to the galactic core (disttocore <=150): [*]"The subspace signals are strong enough to induce nuclear fusion in your sensors!" (Massive group of xsotan ships with sizes ranging all the way up to 100x the largest xsotan ships included in the four vanilla attacktypes) [*]"There are lots and lots of weak subspace signals aswell as a singular strong one." (A hilariously large Xsotan mothership with a lot of small escorts) Installation: Dump the contents of the zip into your Avorion scripts folder. EDIT: I fixed a bug in the code causing the Xsotan Mothership to not be sufficiently deadly. In addition to this fixed version I added one that works on the Combat Update beta branch. avorion-extended-xsotan-attacks.zip avorion-extended-xsotan-attacks-combat-beta.zip
×
×
  • Create New...