Level design, entity spawning, and art.

Today was pretty relaxed with Gwen. I focused on entities spawning from bases and started drafting out a basic level guide. After yesterday’s adjacency mind-bender and working on the path follow stuff before that I thought I’d focus on something a little less twisted today.

Level design

I have to get this straight soon. Gwen is intended to eventually be an iPhone game and I’ve been drawing my canvas and placeholder images in the old iPhone resolution - 320px by 480px - as opposed to the retina display, which is 640 x 960. I’m not sure what the best approach is here - work in the smaller resolution (it just looks like it’s closer to the actual display size that way, giving me a better idea of what it will look like on a phone) vs the larger resolution. Either way I’ll have to have two sets of images in the end to account for both…

I’ve also been trying to figure out a standard for my entity sizes. Darcy linked me to this on Twitter, which says that the recommended minimum size of a tappable UI element should be 44x44px, so I am trying to stick with that. However, as the game is not meant to have any camera movement having the roads be this large seems to make things a bit cramped (as the nodes are ends of roads, I’m making the roads the same size as the tappable nodes…so if the tappable nodes have to be 44x44px, so do the roads).

I will have to do a lot of experimentation here - maybe even with making the appearance of the tappable nodes smaller than the actual tappable area as Stuart suggested. I think I’ll dig up a little notebook and do some brainstorming in my spare time on trains and such over the next few days. Sketching stuff out seems like it might help.

Entity spawning

Until today I had the base in the path array spawn one entity and have it move toward the destination via the path the player built when they pressed “Go”. In reality, this functionality was (and is still) incomplete. Each building is meant to spawn several moving followers. Different types of buildings have a different potential range of followers. So here’s what I did in my base1.js:

First, I set a min_people and max_people attribute at the very start of the code, with the other attributes:

[crayon] min_people: 1, max_people: 5, [/crayon]

These will be specified manually for each base entity (there can be more than one instance of the same type of base per level). So this base can hold anywhere between 1 and 5 people.

Then, this base’s init function looks like this:

[crayon] init: function( x, y, settings ) { this.parent( x, y, settings ); this.addAnim( ‘inactive’, 1, [0] ); this.addAnim( ‘active’, 1, [1] ); ig.game.base1 = this; this.name = ‘base1’ + this.id; // Randomly generate number of people in this base based on min_people and max_people setting this.batch_size = Math.floor(Math.random()*(1+this.max_people-this.min_people))+this.min_people; console.log (‘batch size: ' + this.batch_size); }, [/crayon]

As you can see in line 8, I generate a random number using the min_people and max_people values and assign it to the this.batch_size variable.

When “Go” is clicked, if all other conditions are met (the path is complete etc), the base’s spawn function is called. Hopefully my comments are self-explanatory:

[crayon] spawn: function() { // While the batch size is greater than 0, do this: while (this.batch_size > 0) { // Generate random number for slight spawn position offset var random_y_offset = Math.floor(Math.random()*(1+51-5))+5; // Spawn an entity and decrease batch size by 1. ig.game.spawnEntity( EntityBase1People, this.pos.x + this.halfwidth, this.pos.y + random_y_offset ); this.batch_size = this.batch_size-1; } // Deselect the path when all people are spawned. ig.game.playerController.deselectPath(); }, [/crayon]

Originally the path was deselected inside the init function of the actual follower entity after it was spawned. However, this caused the path array to be cleared after the first follower was spawned. This in turn meant that the path array was no longer there for the other spawned followers to copy, which is why I moved the function call to the base entity. The path is now deselected after all follower entities are spawned.

The reason I generate a position offset right now is purely for visual appearance (so that entities don’t spawn on top of each other). I may get rid of this later and just have them spawn in one spot.

The code for the spawned entity is also in the same base1.js file. Each base has its own types of entities - so certain bases spawn entities with certain attributes (so that things like speed can vary).

One of the most important parts was setting the collision for the followers to ACTIVE: [crayon] collides: ig.Entity.COLLIDES.ACTIVE, [/crayon]

In Impact, entities can have several different types of collision:

When an ACTIVE hits ACTIVE or PASSIVE, both entities move. My actual base entity collision is set to NONE - in this way despite the follower entities being spawned on top of the base entity, they don’t directly influence each others’ movement.

So right now, when entities are spawned they look like this as they move (they never overlap each other as the ACTIVE collision causes them to bounce back each time they run into each other). The movement is still not ideal - I’m in the _very _beginning stages of follower behaviour here, but I won’t go into this yet. The entities are killed when they reach the destination (eventually stuff will actually happen here - point addition and other checks). JavaScript ImpactJS entity movement

Which brings me onto:


Everything above is a two-second placeholder graphic I created just to be able to see something while building the functionality. So while I still think it’s early to worry too much about the art or start producing anything, I did get in touch with Simon about potentially sitting down and having a preliminary talk when we’re both at GDC.

I wasn’t going to even think about art until all of the functionality was in, but now that I’m brainstorming basic level structure this has made me think about what the look and feel of the game is actually going to be like (as well as visual properties of the individual entities). I never planned on doing art for this particular project myself. Simon was always in the back of my mind in terms of who to talk to first about potentially taking on the art direction as I’ve worked with him both at Interzone and other projects before and he’s amazing.

Judging by the environment I’m building I’ll need to take at least basic artistic elements into account. Better discuss the general idea now instead of realizing that I didn’t account for something art-wise and have to start tweaking spawning positions or other code later. I’ll be seeing Simon at GDC anyway and he doesn’t live in Perth anymore, so it might be a rare chance that I’ll get to speak with him face to face. We did briefly talk about art for this project a couple of weeks ago over lunch when he was visiting WA, but this was before I started any of the actual coding (before Gwen was even called Gwen) and I didn’t really divulge any useful information (other than “Buildings, Simon. Top-down buildings.")

Anyway, so that’s the progress for today. There is a long way to go, but I have a feeling I’m slowly getting there (very. slowly.)

© - 2021 · Liza Shulyayeva ·