Thursday, 15 September 2016 |
If you aren't in the loop, Steam basically added more ways to filter reviews and the default filter (and the resulting score) only take into account reviews by people that bought the game directly through Steam. External keys are left out (they are still there, they are just not included in the default settings).
Lots of people have been talking about this. You can see lots of developer reaction on RPS and on Gamasutra. You can also see some of the games that were most affected by this change here.
Here's how this is likely to affect Soldak from a developer standpoint:
The good: Hopefully developers won't be able to cheat their review scores any more by providing free keys to people (or just fake accounts) to write up fake positive reviews. You can see in that third link above that this has been happening. Hopefully this also stops the practice of people asking developers for free keys to write up a good review on Steam. We get a ton of these every time we release a new game on Steam. Frankly it's pretty unethical so we've never done this and it's time wasted going through all of this email.
The bad: Developers like us still try to sell as many units as we can directly to our gamers. We've always given Steam keys to our directly purchasers on request. In the past, sometimes this happens because we release the game directly before we get on Steam and sometimes these are people that just want to give us more support by buying directly from us. Either way these tend to be some of our more vocal fans and now their reviews will not be in the default filter and score.
The unknown: We will lose Steam reviews from our games sold through other means but end up with a Steam key. For us that means some bundles Depths of Peril has been in and a few portals that provide Steam keys that our various games have been on. I'm really not sure this will change anything for us. For developers that rely on things like Kickstarter this might be big deal.
From a customer standpoint (I do buy games, sometimes on Steam and sometimes not. I don't write reviews though):
The good: Now by default I only see reviews by accounts that actually bought the game on Steam. That should mean much more of the reviews are actually by real people and not fake crap. This should be nice. I can also always change the filter to look at all of the reviews if I want to.
The bad: For me personally from a customer standpoint, I'm not sure there is anything bad, but again I don't write reviews. So having said all that I looked at Depths of Peril, Din's Curse, Drox Operative, and Zombasite on Steam to see how it has actually affected us so far by changing the filters and seeing what changes. With the new stuff Depths of Peril's score actually goes up 1% and loses 2 reviews, Din's Curse loses 1 review, Drox Operative loses 4 reviews, and Zombasite loses 4 reviews. So overall we lost a few reviews and DoP score actually went up a little.
So what are your thoughts? Comments
 |
|
Thursday, 08 January 2015 |
We have recently enhanced the skills system in our upcoming game Zombasite with traits. Traits are passive skills that are meant to significantly change how you play and/or build your character.
There are 20 traits spread evenly across all 5 attributes (strength, dexterity, vitality, spirit, and intelligence) and are unlocked when you meet the attribute requirement (50, 100, 150, or 200 points). Only points allocated by you count for this requirement (i.e. a ring of strength doesn't help you unlock a strength related trait). All 20 of these traits are available to every class.
Traits can significantly change your character. This is because they have major positives, but also because they all have negatives. You will need to take into account the positives and negatives and make a difficult choice to take the skill or not. Since you still need to use a few skill points to get the skill, getting the skill is not automatic when you meet the attribute requirement.
I have a feeling that many people will design builds around the traits they plan on eventually getting. I hope it will even encourage some people to put points into some attributes that aren't typical for that class, like intelligence for a warrior.
To make all of this a little less vague, here are some examples:
Pierce - All projectiles pierce their victim and continue to possibly hit more enemies. Each projectile does 15% less damage though.
Vanguard - Adds your defense to all nearby allies, but your defense is decreased by 20%.
Pain Delay - All incoming damage converted to damage over time, however you take 25% more damage.
Blood Magic - Skills use health as your power source.Comments
 |
|
Friday, 12 December 2014 |
I'm usually worried about cannibalizing sales of our previous games so I try to keep some of the bigger things unique per game. I'm thinking of making an exception for classes & skills this time around. I think I'm going to keep the classes and skills in Din's Curse for Zombasite, at least as a starting point.
The hybrid stuff worked really well in DC and I think it will work even better with the trait stuff I've been working on (probably my next blog). We will of course change some of the skills to better suit a zombie game and rebalance everything.
For a change, I'm blogging about this before I make very many changes so it's a great time to get feedback from you guys. For those that have played DC, what skills do you think we should keep, which should we lose, and which should we change?Comments
 |
|
Thursday, 14 August 2014 |
The zombie apocalypse has occurred in Aleria. At least now we know who the enemy is and where all the danger is, right? Well, as is common in an apocalypse the instigator is just the first problem, but necessarily the most dangerous.
Don't get me wrong, the zombies are definitely a huge threat. Not only are they attacking and killing every living being they can find. Their attacks are highly contagious. Almost anything killed by them becomes a zombie. Even as little as a scrape from a zombie might infect someone and then they will inevitably turn sooner or later. The zombie tide seems indestructible.
The previous wars in Aleria didn't help, but the zombies have destroyed any semblance of society still left. There are no farms or supply chains still intact. Even much of the wild game has been killed or infected. The food supply has been decimated. You and your people must find enough food so that you don't starve. This will not be easy.
Unfortunately, everyone else is in the same situation as you and they don't want to starve to death any more than you. With everyone fighting over the limited amount of food left, humans and even some of the more intelligent monster races are forming clans to protect themselves. Some of them are gathering together so that they are strong enough to take what they want from others. It is possible to become allies with other clans, but when they are slowly starving to death, will they betray you?
Even within your own clan it isn't safe. Humans living on the edge are even more unstable than usual. Some people are just bad people and will betray your clan for gold, food, or for no discernible reason. Some will have personality conflicts with others that might lead to fights and maybe even killings. Some might not be happy with their share of supplies and get angry. Two men might like the same female and cause problems. You never quite know how different people thrust into a life and death situation will react, especially over time.
And last but not least, Aleria has always been full of monsters. They have survived wars, famines, plagues, disasters, heroes, gods, and many other things that have threatened their existence. A bunch of zombies isn't going to eradicate them either. Their numbers might dwindle, but they are surviving the apocalypse and still causing the usual mayhem: wars, uprisings, attacks, etc.
So what do you think is going to be the biggest danger to you surviving the Zombie Apocalypse in Aleria: the zombies, starvation, other clans, local in-fighting, or the surviving monsters?Comments
 |
|
Friday, 18 July 2014 |
I fixed some networking issues in our engine (specifically Drox Operative) a while back and the path I had to take to find the solution was interesting, so I thought I would write up a little of what happened.
The problem was that once a game progressed long enough, people were having a hard time joining the server hosting that particular sector. Easy enough, I thought, but no matter what I did I couldn't reproduce the problem. I even got some of our gamers to send me their save games that they were having trouble with, but still no luck.
Even though I couldn't reproduce the problem, I looked at the save games to see if there was anything interesting going on. What I found was one of the initial networking messages was so large that the networking system needed to create over 10 fragments for it (the system would send 10+ smaller messages). At the time, the system would throw out the entire message if it received an out of order fragment or any fragment got lost. I figured if the packet loss was very high, a message of that size would almost never get through. So I set my handy packet loss tool to drop 50% of the packets and sure enough, I could almost never get that message through.
So I go about making the system smarter about fragments. I made it so it would store all of the fragments and if it missed a fragment or got an out of order fragment, everything was fine and it would just wait for the other side to resend the message again. As long as the next message was the same as the first, it would ignore repeated fragments and just use the fragments it needed. This way sooner or later, even with bad packet loss, it will get all of the fragments.
So now everything should work great. I test it and the new stuff does exactly what it should, but it still doesn't work. Even weirder is I turn the packet loss tool off and it still doesn't work even though it used to when the tool was off. At least now I have a reproducible situation.
I debug the problem and see that it gets each fragment fine until a little after 8192 bytes. It wasn't exactly 8192, but it was near enough to that power of 2 that I was suspicious. I turned the packet loss stuff back on and now I started getting data after 8192 bytes but I noticed that I was getting the same number of fragments through each time. So the networking was only delivering a certain number of bytes before eating everything else. I did a little googling and found out that Windows defaults to a 8192 buffer size for incoming UDP packets.
Ok, so I've found the problem. I found the correct commands and now the networking is told to use a much larger buffer so it can at least hold one large message. I test again and it still doesn't work! :( I start debugging again. Now I see fragments coming through way past 8192, so that is fixed, but I get to around 32K and then one of the numbers goes negative. Again that sounds like another power of 2. In this case it sounds like a signed 16 bit value. Sure enough I find that fragments are using a signed 16 bit for an offset number. Again easy enough, I change it to a 32 bit value so that should never be a problem again, assuming we never generate messages that are over 2GB in size. :)
I test again and things finally work as they should! So in the end, my initial packet loss changes had nothing to do with the real problem that we were running into. The fixes to the actual problem were like 2 lines of code compared to probably 100s dealing with the packet loss. However, it still is a nice change because it handles packet loss much better on large messages. I'm still not quite sure why I couldn't reproduce the problem in the first place though.Comments
 |
|
| | << Start < Prev 1 2 3 4 5 6 7 8 9 10 Next > End >>
| Results 28 - 36 of 246 | |
|
Newsletter
Sign up for our free newsletter! |
|
|