Greetings Citizens, It's been just over two weeks since we last posted news, so it's well due for a dev blog! By now most of you will have discovered that the last release we did caused some serious issues with stations and saving block changes. As a player, these severe issues can spoil your mood to play the game and in some cases also result in you losing in-game progress. As a game development team, we’re aware issues like these lose our players trust and support. Additionally, having to do several hotfixes also eats away time in every new release cycle. The release cycle, as it stands, is scheduled for a release every two weeks. Sometimes we extend major releases (such as NPC factions) to go through multiple release cycles. However, we try to stick to the two-week schedule as best we can. During this cycle, we have to plan, develop and test every release. We've found that it's hard to put a meaningful amount of content into a release in only two weeks, especially since we can't add anything new during the testing phase (currently 2-3 days) before release. What tends to happen is that after a release is sent out at the two-week mark, hotfixes are needed, we then lose even more time for the next release cycle. Adding more testers to our testing phase wouldn’t help in the sense that a tester’s job is to mainly maintain Phabricator and to report any dev issues along the way. It’s a never ending task and finding volunteers that will do this for a long period has so far been difficult. We've come to the conclusion that the current two-week release schedule is unfeasible for a team of our size. It's inefficient, unmanageable and it's not beneficial for our players or us. For these reasons, we've decided to work on a new release cycle, to eliminate/reduce severe issues in new releases and allow us to get more work done.
New release cycle
The changes we want to do here is to extend our release cycle to “as long as we need” with Dev Blogs to keep everyone up to date with what we’re working on throughout the release cycle.This gives us more time to do some long-term tests without feeling the need to rush a release out and then having to hotfix afterwards. This approach also lets us monitor any performance issues that pop-up and resolve them before a live release. Although this should already be more manageable for testing, we would like to minimise the risk of any issue going unnoticed during pre-release testing. Therefore, when we think it’s ready to go, we will inform you about all the dev build changes in a news post but not do a live release. That would be our release candidate which will be used for public testing. You can check those changes out on our test server and help us out by reporting any issue you find. We even have a few servers that want to run this release candidate on a backup of their entire server database to give us even more coverage. Having the community involved in the process before the release goes live will ensure we catch as many issues as we can, avoiding the need for as many hotfixes after it goes live. If you encounter any new issues, please report them here, and we’ll make sure to prioritise them correctly to fix any annoying or severe issues before live release. We’re planning to do these release candidates on a Friday if possible, and we estimate it will take roughly a full week before it can be uploaded to the release branch. This will allow us to get a lot more work done, as the two-week release cycle was holding us back quite considerably, often reducing features to minor gameplay and decorative updates while we didn’t make as much progress with bigger features as we would have liked. The most popular updates like the rail update did have long release cycles, so we already know that it pays off. We’ve written our different phases out here although they’re still subject to change. A lot depends on how well our next release will go when following these rules.
Bug spring cleaning
The two-week cycle also left bug-fixing in a poor state as we were always forced to fix bugs affecting the new features, and then hotfixing, neglecting other bugs that continued to get pushed back more and more. In light of this, our first usage of the longer release cycle will be the quest to fix all bugs that have a priority above “normal”. This is long overdue. We have also decided that when we release, the release should have fewer bugs than the last release. Not only will this make the game a lot better over time, but it will also free up resources for our testers, as fewer bugs will have to be processed. We understand that it was a bit frustrating for new testers to see their bug report(s) in queue waiting to be fixed for so long. This is also something we want to resolve through this process.
Power update
With regards to the power update proposal we shared with the community. We have worked on ironing out the flaws in our concept and were hoping to have been able to present our revision a week ago. However, we’re still not quite ready to share our revised proposal just yet. Some of you mentioned it was hard to judge a system with a lack of details which is why we’ve been working on it for a while now. It turns out that it’s not easy to find a complex system where every block has a purpose and affects different portions of your reactor. We’ve toyed around with several ideas such as heat management and reactor shapes, but the hardest part is finding a good base and sticking with it. For now, watch this space.
Current changes
Our primary focus these past few weeks has been on bug fixing, addressing all of the higher priority bug tasks that were still in queue. Fifty of them have been addressed so far, although testing is still required to make sure they’re resolved. With bug fixing also comes some small features, such as the ability to toggle cloak/radar jammers on fleets. We’ve also been looking out for those annoying issues that aren’t necessarily a high priority but can still sour gameplay experience after encountering it too many times. For example, rolling a ship has always resulted in odd behaviour, and we’re very close to fixing it right now. Our next release will require some extensive play testing; we’re sure our community will be willing to help us out As always, thanks for playing StarMade ~ The Schine Team
StarMade
Schine, GmbH
Schine, GmbH
2014-12-04
Action Indie Strategy RPG Adventure Simulation Singleplayer Multiplayer Coop EA
Game News Posts 115
🎹🖱️Keyboard + Mouse
🕹️ Partial Controller Support
Mixed
(2175 reviews)
http://www.star-made.org
https://store.steampowered.com/app/244770 
The Game includes VR Support
StarMade Launcher - Linux [2.38 M]StarMade Launcher v2 - Linux [239.03 M] [0 B]
The universe is a vast, mystical, beautiful, awe-inspiring place.... the universe is yours.
Built for scalability to facilitate massive fully interactable objects, almost anything is possible. Gameplay elements have been skillfully constructed to bring the ultimate space sandbox experience.
Dive into your own unique universe, and choose your path.
Key Features:
- Procedurally generated infinite universe, with quadrillions of galaxies - The universe is massive. It'd take approximately 10,000 years to cross from one end to the other! Singleplayer and Multiplayer worlds can be heavily customised with our extensive config options.
- Developed for scalability- We have a broad range of graphical and performance options that cater to our low-end users as well as those with heavy rigs and servers.
- Advanced Build Tools - Powerful and easy to use building tools, quickly design awesome ships, stations and bases. Including functions: Copy & paste, undo, redo, replace, symmetry modes, shape assistance systems (spheres, cycles, torus and more) and rotation of templates.
- Modular Weapon Systems - Combine weapon systems for countless configurations of weapons. From sniper beams to swarm missiles.
- Comprehensive Rail & Logic Systems - Use the rail system to build moving parts. You can do anything from simple elevators, sliding or rotating doors, to complex cranes.
Tinker with our logic systems to control any system in the game, be it weapons, lights, rails, or explosives. Logic covers all basic gate types for convenient use (AND, OR, NOT, DELAY, Flip-Flop), allows in flight control and wireless connections between entities. You can use it for simple things like timers, switches, buttons. Or, build complex systems like working clocks and even a real CPU. - Community multiplayer (dedicated servers) - Play with others in our community hosted servers. Our configs allow administrators to customise core game mechanics for a tailored experience. Most settings can be tweaked to squeeze the best performance out of hardware.
- Platform independent (Windows, Linux, Mac) - StarMade is completely platform independent. We support the three most widely used operating systems.
- Free to play in alpha - We offer the full game free to play while in alpha development. Play our game through this period for free while in return we receive invaluable feedback and bug reports.
- OS: Ubuntu 14.04 - 64 bit
- Processor: Intel Core i3 (2nd Generation and above) | AMD FX 6xxx or equivalentMemory: 4 GB RAM
- Memory: 4 GB RAM
- Graphics: Nvidia GeForce GTX 260. 275. 280. 460 SE. 550 Ti | AMD Radeon HD 4870. 5770. 4890. 5830. 6770. 6790 or equivalent with OpenGL 2.1Network: Broadband Internet connection
- Storage: 3 GB available spaceAdditional Notes: 2GB of memory must be available for StarMade. Lower specs may work by modifying graphics and other performance options. Try out our demo to get an indication for your system. System components such as Integrated Graphics cards may not be supported. Requirements may change in further updates.
- OS: Ubuntu 15.04 - 64 bit
- Processor: Intel Core i7-2600 @ 3.4 GHz | AMD FX-8320 Eight-Core @ 3.5 GHz or equivalentMemory: 8 GB RAM
- Memory: 8 GB RAM
- Graphics: Nvidia GeForce GTX 560. 650 Ti. 750 | AMD Radeon HD 5850. 6870. 7790 (or equivalent)Network: Broadband Internet connection
- Storage: 3 GB available space
[ 5951 ]
[ 3198 ]