Jul 5, 2018

WolfQuest: Classic - loboLoco

https://youtu.be/eBpLVAHvxHI

Raising pups is the core mission of Slough Creek: choosing a den, keeping pups fed, defending against predators, building pack affinity, and getting them safely to the summer rendezvous! In WolfQuest 3: Anniversary Edition, we will be updating and improving the pups. Here is a sneak peak of some new animations that we know you will love!

FAQs

Will there be more dens?
Yes, with the bigger maps, there will be more dens to choose from.

Can we dig? Can we make our own den?
No, not for this update. Digging wherever you want is more complicated technically than you might imagine! As is choosing your own den locations.

Can we go inside the den?
We know this would be a very popular feature, but remember that dens are small, dark, and crowded — not much you can do in there except curl up and sleep. So that makes it tricky in various ways, but we understand it would be a popular addition.

Can the pups be newborn?
As in earlier versions of WolfQuest, the pups will a appear when they are six weeks old and big enough to live outside the den. It would be fun to have them when they are newborns but they don’t do much except sleep and whine. Maybe someday.

Will there be variable litter sizes?
Yes. Litter size in WQ3 will vary (probably between 4 and 7, but we’ll tune that during beta testing).

Will pups have personalities?
Yes, they will — just like your mate!

Will pups have different coat colors?
Yes, if you missed the pup genetics video, go check it out! Genes Behind the Scenes at Read the blog post/description for FAQs about coats colors.

Will our pups get ill?
Yes, there will be a chance your pups might get sick and they also might or might not recover.

Are all the predator improvements going to make it impossible to defend our pups?
No, you will be able to choose the difficulty level, as in the current game. We will calibrate the gameplay so you can successfully raise your pups even with wilier coyotes and more dynamic stranger wolf packs.

Can we play as pups?
We know lots of players would love to play as pups! Maybe someday!

Can we continue with our pups after getting to the summer rendezvous site?
Yes, the upcoming episode Tower Fall will continue your life with pups. In the first weeks of June, the pups frolic at the rendezvous site in Slough Creek while their parents bring them their first meals of fresh elk meat. When the elk herds move down into the Lamar Valley, the pack follows — only to find other packs have already established territories in the valley. So they journey further south, up and over Specimen Ridge, then down into the valley of the Yellowstone River. There, on the banks of the Yellowstone, with Tower Fall thundering nearby, the pack makes a new home amidst fellow predators and plentiful prey. Here the pack will stake out a new territory, protect their family from danger, and raise a new generation of skilled hunters. The Tower Fall expansion will be an in-game purchase that we think will be about $6-8. It will be released later in 2018 (after WQ 3).

Can our pups grow up and help raise the next generation of pups? Can they stay with our pack or disperse?
Keep in mind, even at the end of Tower Fall, your pups will still be only eight months old. Someday we hope to add a winter episode that would last through spring, when the next litter is born. Wolves generally disperse at about two years old.

When will WolfQuest 3: Anniversary Edition be released?
We are still hoping to release the game later this year but do not have a release date yet. Why so long? We started out making a new episode (Tower Fall) but soon realized it would be better to update the whole game first. If you have been following our progress, you know that we keep thinking of awesome new improvements and WQ3 will be a whole new game from the ground up. We know it is hard to wait and we appreciate everyone’s patience. We think it will be worth it!

How can I support WolfQuest game development?
• Buy the game!
• Tell your friends that WolfQuest is a great game! Games sales are why a little game about wolf ecology is still going strong after more than ten years.
• Give WolfQuest as a gift to a friend! Steam and itch.io make it easy to gift games.
• Buy the music extras and consider leaving a tip.
• Donate to game development
• Follow, subscribe, and support WolfQuest on social media and Steam. Good buzz keeps WolfQuest alive.
• Write reviews. Great ratings and positive reviews from our fabulous players make a huge difference. Take the time to give WQ some love wherever you are online.

We appreciate all the ways players support WolfQuest! We truly wouldn't be here doing this without you.

Jul 5, 2018

Patch 1.29.3A: First Blood, New Skins and Important Optimizations

Hunt For Gods - giufuf

Do you want to discuss with us or propose your ideas?
Comment down below or join us on:

Discord: https://discord.gg/eKKpdjY

Reddit: https://www.reddit.com/r/HuntForGods/

Telegram: https://t.me/huntforgods

We are waiting for you! :D
_____________________________________________________________

Game:
[Novità] Added the skin: "Mavi The Grey"
[Novità] First Blood! Now the first player (Hunter or God) who kills an enemy Hunter within the first 80 seconds of each round, gets twice the levels up for that kill and all his skills’ cooldown reset to zero

[Feature] It is now possible to activate/deactivate Vertical Synchronization in the options menu
[Feature] Now you can select the type of soldier to spawn at the beginning of the round

[Tutorial] (Hunter) It is now easier to survive during the tutorial

[Modifica] (God) The view can be zoomed more
[Modifica] Artemis’ Ultimate Skill is now a “target” skill
[Modifica] Wyzo now uses the same view of melee characters

[FX] Added a sound for the effect of the following items:
- Dragon's Tooth
- Martus' Talisman
- Last Chance

[Localization] Updated tooltips in French and Spanish of the following items:
- Valitudo's Shield
- Sheridan's Mask
- Isiro's Armor
- Falea's Crown
- Boots Of The Cat
- Fool's Fury
- Bracers Of The Valiant
- Losfire's Magic Seal
- Vemonia's Glory
- Justice Of Sargo
- Breakthrough Halberd
- Last Chance

[Optimization] Improved the synchronization of all living units’ position
[Optimization] Optimized management of hunter's positionable skills
[Optimization] Optimized network consumption related to players’ movement
[Optimization] (God) Reduced heavily the load of the 3D icons on the CPU

[Bugfix] Fixed some rendering problems with some parts of the map at low quality
[Bugfix] The Hephaestus’ skill 3 is now correctly visible
[Bugfix] The particle effect of Demonic Yokpull’s footprints works again
[Bugfix] The particle effect of the Last Chance is now correctly visible
[Bugfix] (God) Fixed a bug related to the Smart Cast
[Bugfix] Fixed a minor bug related to the Hephaestus’ Ultimate Skill
[Bugfix] Fixed a bug for which the God tutorial could not continue
[Bugfix] Fixed a bug for which the game could crash when killing a ghoul

[Balancing]
--- Yokpull ---
—Skill 2 --
- Stun Area: 3/3/4.5 -> 4/4/5

Client:

[GUI] In the lobby, you can’t choose anymore the type of soldier to use in game

[Bugfix] Fixed a minor bug related to the enemy icons shown in the lobby

Jul 5, 2018

AI War 2 v0.748 Released! "Macrophage Teeth"

AI War 2 - x-4000 (Chris McElligott Park)

Release notes here.

This week hasn't exactly gone as I expected, but it's been very productive. I had planned on working on the lobby, first of all, but then some performance-unfriendly saves came to light and I decided I'd work on that instead. The biggest hog in large battles is the vis-layer movement of ships around, and last release I talked about how I was going to look into System.Numerics and DrawMeshInstanced to solve that. I also basically decided to upgrade to Unity 2018.2, even though that's still in beta, because it has some things we need.

Well, that didn't happen either!

Badger fixed up the "unit testing" program that we have for the sim layer, and for the first time I fired that up. It's an area that was previously out of my domain, but that's been expanding a bit lately just due to necessity. At any rate, I spent almost all of this week on performance improvements to the sim layer.

Badger also fixed some notable bugs, such as the Macrophage not actually doing damage when they attack. That concludes my summary of the release notes other than to talk about performance.

Enjoy!

Chris

I again wanted to mention: we have a new Steam Developer Page. If you go there and follow us, you'll be notified about other upcoming releases (including this one, of course).

Performance Hunting

I've tried using three different profilers in this period: NProfiler (which is awful despite promising big things), JetBrains dotTrace (which seems fine), and RedGate ANTS (which is maybe a bit better, but it's hard to be sure).

At first these tools were lobbing up really juicy bits for me that I was able to majorly optimize, leading to quite a bit of savings. I spent way longer than I expected just trying to optimize squareroot again for our use cases, and finally cut that to a tenth or less of the load it used to represent.

I thought I was going to have to create a new form of data structure for tracking lists of entities in our code, and I came up with one in my head that I haven't implemented yet (a wrappered, pooled, linked-list structure that is super fast at adding, removing, and iterating, but has no random access possible). It turns out that the things that I thought were going to require that MAY have been a profiling artifact, but the vote is still out on that. I'm undecided on whether or not I need to make an adjustment there.

At the moment, what I am winding up finding is a suspicious "speed limit" on the sim code that is related to the framerate in some fashion (and no, it's not any of the obvious things; in this case it's a virtual framerate, but that still adjusts the speed limit). At any rate, that's the next thing I need to dig into, because I think no other changes I make will show a result at the moment because all the background threads are presently running below that speed limit, making it the limiting factor. Some of the later performance improvements I made show up with no benefit in actual gameplay yet, but they show up fine in unit testing if I set the virtual framerate really low. Fun for soon.

One of the things that I've observed is that the background threads aren't hitting the other processors on my CPU as much as I expected, which was suspicious to me. I've gone in and looked around, and my first thought was that our threads are spending too long transitioning from idle to active. I'm still not sure that isn't the case. We're using Thread.Sleep(1) in order for them to wait while being alive and then turn on as soon as a bool is set that says "your data is here -- now go!"

The problem is... apparently Thread.Sleep doesn't guarantee that it will only wait one ms. Instead it will apparently average 12-15 ms. That is an eternity! No wonder things are not very busy on the secondary processors. So that's no go.

I started using SpinWait to spin the cpu instead of Thread.Sleep(1), and that does indeed peg the CPU at 100, but there's 88% wasteage on spinning according to the profilers when that happens. That's going to slow down the main thread and lose framerate as well as making the other threads slower to sync, too. So that's really kind of a no-go.

I need to figure out what that mysterious "speed limit" in our code is and get rid of that, and that will solve a lot of the problem. Other than that, though, I've got to figure out a way for the multithreading to be a bit more snappy in when it does things and stops doing things. Right now it's 12-15ms at best from the word go to it actually doing anything (on almost a dozen background threads, individually).

We could supposedly use the Monitor class to help with synchronization, but I'll be honest that I don't yet fully understand how that would best be used while not pegging the CPU. Offhand, it sounds like using objects to lock against and monitor instead of using a bool to check against -- still one per thread -- but I'm not positive. Any multithreading-in-C# experts in the crowd that want to help out? Either with some explanations or taking a look at our code, or even making some changes on your own? We're pretty slammed, workload-wise.

Anyway, another option that is still on the table is potentially just switching to using the ThreadPool or some other form of multithreaded job class rather than threads that we keep warmed up and running and managed on our own. That might be the simplest approach, we shall see. I've done this in plenty of applications before, but none with ms-level speed required. AI War Classic only had one secondary thread, and it didn't block the sim when it was idle, so we never ran into this with it. With Stars Beyond Reach, we used a ton of threads, but it was done in such a way that a 12-15 ms lag was utterly invisible.

So that's what's going on lately!