• entries
13
5
• views
1045

# Pets, Hail, and UI Improvements: It’s the VMD3 for August 6th

1263 views

It's the weekend, and that means another edition of the Village Monsters Dev Diary Digest (VMD3)!

Like last week I have a bit of housekeeping to do before diving in. Longtime followers know that I've tried several different ways to present progress updates, but none of them have really 'stuck'. However, it seems this weekly format has really been working for me.

As such, I went ahead and created an archive for every Dev Diary Digest I've posted since I started doing them. If you missed earlier editions, or if you just want to see how far I've come, then please do take a look!

Anyway, onto the update

Pets
I may have shared this anecdote before, but the road to pets was a serendipitous one

A few weeks ago I was working on debugging critter behavior, and for whatever reason I was testing it in the player's house. As I kept going in and out of the house it occurred to me how much I actually liked having a critter there - it was sort of like having a pet! Wouldn't it be cool if that was an actual feature?

This week I was able to prototype this idea:

Here's how it works: first, you gotta catch a critter. Then, walk up to an special item (currently a pet bowl) and select the pet you want to tame. You can only tame one at a time, so choose wisely

At first, all critters start out as "Wild", and they'll act much like they did before you caught them. Over time, if you feed them and treat them well they'll increasingly become tame and more affectionate.

Tamed critters will also continue to behave similarly to their wild versions, and they'll retain any unique attributes. For example, if you catch a Snowflake Elemental he'll make your entire house cold; good during the summer, but not so good if you have a lot of fish on display...

Hail / Thunderboomers
I always enjoy working on weather systems, so I took a detour to add a new weather type - Hail

I had to improve the weather system to handle the little hail pellets, and these improvements should help with any 'ground based' weather effects in the future...leaf piles in the fall, snowdrifts, rain puddles, and so on.

I then went ahead and added more sound effects to the various weather types. I also added a minor feature where weather sounds can still be heard indoors at a lower volume. It's surprisingly atmospheric, especially during thunderstorms!

UI Improvements (Map, Inventory, Notices)
Finally, though I generally don't like it, I also spent a great deal of time on UI work. I've never enjoyed UI work, not even at my last job where functionality was preferred over looks, but I'm actually pretty happy with how things shook out this time.

First, I added a map for the village to the Compendium. It's very basic and just lays the foundation for future maps:

I then added movement to various notifications. I like it a lot better than the notices just appearing suddenly.

Finally, I completely blew up and reworked the inventory. I actually did this some time ago, but I added an extra layer of polish and usability this week. It's unquestionably better than the old inventory, but that's not saying much - the old one was really bad!

Anyway, that's it from me. As usual I also added a lot of minor things, quality of life improvements, and bugfixes, but nothing I need to call out. Have a good week!

## 1 Comment

The hail looks good!

## Create an account

Register a new account

• ### Similar Content

• A new entry in the devlog for 13 Ronin, a retro 2d samurai fighting game, this time it's about implementing the logic for the computer player.
Happy coding!

• By Seer
Currently if I was to program a game using C++ with SFML or Java with LibGDX I would render game objects by calling "object.render()" on the game object. Although this makes it easy to access the information necessary to render the game object, it also couples rendering to the game logic which is something I would like to move away from. How can rendering be implemented so that it is decoupled from the game objects?
I wish to know how this can be done in the standard object oriented paradigm, so please don't suggest that I use an ECS. Thank you.

• Hey,
So I have got this asteroid type game and today I encountered a new issue while testing this game.
What happened was that two asteroids were close to each other and I shot a bullet at them. The asteroids were so close to each other that a single bullet could collide to both of them.
It collided and my game crashed there itself. I figured out it happened because two asteroids and one bullet collided in the same frame.
This is the code -
void Collision::DoCollisions(Game *game) const
{
for (ColliderList::const_iterator colliderAIt = colliders_.begin(), end = colliders_.end();
colliderAIt != end;
++colliderAIt)
{
ColliderList::const_iterator colliderBIt = colliderAIt;
for (++colliderBIt; colliderBIt != end; ++colliderBIt)
{
Collider *colliderA = *colliderAIt;
Collider *colliderB = *colliderBIt;
if (CollisionTest(colliderA, colliderB))
{
game->DoCollision(colliderA->entity, colliderB->entity);
}
}
}
}


void Game::DoCollision(GameEntity *a, GameEntity *b)
{
Ship *player = static_cast<Ship *>(a == player_ ? a : (b == player_ ? b : 0));
Bullet *bullet = static_cast<Bullet *>(IsBullet(a) ? a : (IsBullet(b) ? b : 0));
Asteroid *asteroid = static_cast<Asteroid *>(IsAsteroid(a) ? a : (IsAsteroid(b) ? b : 0));
Bullet *bulletMode = static_cast<Bullet *>(IsBulletMode(a) ? a : (IsBulletMode(b) ? b : 0));
if (player && asteroid)
{
player->playerCollided = true;
//AsteroidHit(asteroid);
//DeletePlayer();
}
if (bullet && asteroid)
{
collidedBullets.push_back(bullet);
collidedAsteroid.push_back(asteroid);
//AsteroidHit(asteroid);
//DeleteBullet();
}
if(bulletMode && asteroid)
{
collidedBulletMode.push_back(bulletMode);
collidedAsteroid.push_back(asteroid);
}
}


void Game::CollisionResponse()
{
if(player_->playerCollided == true)
{
DeletePlayer();
}
else
{
if(!collidedAsteroid.empty())
{
for(AsteroidList::const_iterator collidedAsteroidIt = collidedAsteroid.begin(), end = collidedAsteroid.end(); collidedAsteroidIt != end ; ++collidedAsteroidIt )
{
AsteroidHit(*collidedAsteroidIt);
}
collidedAsteroid.clear();
}

if(!collidedBullets.empty())
{
for (BulletList::const_iterator bulletIt = collidedBullets.begin(), end = collidedBullets.end() ; bulletIt!=end; ++bulletIt)
{
DeleteBullet(*bulletIt);
}

collidedBullets.clear();
}
if(!collidedBulletMode.empty())
{
for (BulletList::const_iterator bulletIt = collidedBulletMode.begin(), end = collidedBulletMode.end() ; bulletIt!=end; ++bulletIt)
{
DeleteBulletMode(*bulletIt);
}
collidedBulletMode.clear();
}
}
}

in my game->docollision() -
whenever an asteroid and a bullet used to collide, the collided objects get collected in collidedasteroids and collidedbullets respectively. When two asteroids collided with the same bullet, the two asteroids got collected safely in collidedAsteroid but the single bullet got collected in collidedBullets twice, so when the deletion was happening, the second time iteration of the bullet couldn't find the respective bullet and it got crashed.

How am I supposed to approach this problem now?

Thanks

• How to calculate angle between two points from a third point with the help of D3DXMATH library?

• i'm game designer without coding skills.
i came here looking for Companions with Compassion; i must Retrieve mobile gaming industry overview.
no matter where you live in this World; please step out it's about time. language barrier won't be problem between us.