next »

[The_RonJones]

I just gotta say your level creations are really sexy... Looking forward to seeing more

[archgame]

[archgame]

EDIT: Some people have asked, so I thought I'd post the answer here. The footage is not edited, straight from the pre-alpha (you'll notice a part where we have difficulty climbing a building towards the end ).

And we are back! Now that finals are out of the way and Franklin Cosgrove completed his thesis, we should be posting here more regularly. To kick off the summer, we made a quick

. You can see some basic setups to associate the player with the controls as well as a number of avatars that are swappable and the different perspectives they provide as well as the ability to switch between these perspectives, it all ends examining one characters platforming ability and how this is associated with a particular type of architecture.



The audio effects (most notably the walking) still need some tweaking, but the music concept is in place as described earlier, hopefully this video gives an idea of how it actually works. While we went into a lot of research and conceptualizing of the macro gameplay, making this video highlighted that we still have a long ways to go on the immediate gameplay. Currently the robot peices are highlighted with a particle emitter, however, we'd obviously like to get away with this as it does not fit the story (although the particle emitters on characters fit with KiGi (robot) perspective as we imagined them as a data stream that his perspective made view able). We are still tweaking the gameplay and objectives, in the video everything is relatively fast paced; we would like to slow things down a bit and give an actual chance at exploration, without the anxiety of time limits and necessary objectives (see our reflections on Majora's Mask in a previous point for further thoughts on this). We have really been inspired by Killscreen's recent articles on Boku no Natsuyasumi. We'd love to hear people's suggestions on how to improve the gameplay.

Also, we just like to take a moment and thank all of the people that have helped us get to where we are with the game, although we are a two man dev team there has been a lot of help along the way and we are really grateful for that.

[archgame]

Camera Logic



0) Player capsule with transform vectors.

1) Camera Rig (sphere) updates its transform position based on the player's transform position.

2) Camera Rig moves with the player with a smoothing function.

3) The Main Camera is made a child of the Camera Rig, with an initial offset vector in the Z and Y direction



4) When the Player rotates, the Camera Rig rotates; this allows the camera to be constantly following the player from behind. Currently "L2" is set so when triggered the camera returns to this follow state. Camera view is referenced above.



5) When the player engages the right joystick, the Camera Rig has the ability to rotate around the Player's up vector, while the Camera Rig's position is still updating with the Player's position. This allows different horizontal views to be set. Camera view is referenced above.





6)A Pivot is made the child of the Camera Rig and the parent of the Main Camera. The Pivot functionality is separated from the Camera Rig as the Camera Rig is orienting along all three directions to align with the Player's transform, given the inverted spherical nature of the game's environment. For a planar platformer, the Camera Rig could act as the Pivot.

7)The Pivot allows a rotation to occur along the Player's right vector. Camera view is referenced above.

8)The Pivot's rotation is accompanied by adjustments to the Main Camera's offset, allowing for an extended view of the surroundings. Camera view is referenced above.



9)The Pivot also provides for the ability to rotate in the opposite direction, however this causes the camera to rotate below the ground plane.

10) When the ground plane collision is detected (meaning the Main Camera vector passes through the ground plane, similar to the architecture collision discussed earlier), the Main Camera is set at the location of the collision (on the ground plane).

11) When the Main Camera is set at the ground plane, the view clips with the Player's avatar. To avoid this, the Main Camera is slide along a plate in the Y and X directions, providing a planar offset to avoid clipping. Camera view is referenced above.



Aside from working with the camera, we have also begun to work more on shaders. We noticed Unity 5.0 shaders allow for shadow, while the legacy shaders (which we have been using on the architecture as the project was started in Unity 4.0) do not allow for shadow projections. We tried simply swapping the shader, but the city did not look the same (while the self-illum functioned better, the opaque facades turned to black when far away, giving the city a much more ominous atmosphere). We are working on making a shader that allows for the windows to illuminate, provides a vertical gradient on the facade, and maintains the color from a distance. Eventually we will begin to add more texture through bumping and detailing to the facades.

[archgame]

New Gameplay video. The previous video did not contain the camera (previous post) nor some of the newer shaders, basically this one looks nicer. Additionally, going between our computers today, we discovered that the controls worked slightly different. On one computer Kigi's double jump was easy to trigger, while on the other, the double jump would trigger simultaneously when going for a single jump. To fix this, simply added a boolean that would only allow a jump to happen once the input button went back up after going down (the slight echo of the jump sound gave away the problem). Seems like this is probably standard procedure for most games I imagine.





Enjoy the video, would love to hear any thoughts.

[archgame]

Two new songs "Back In The Rain" and "Graduation" for your Saturday afternoon while everyone is #screenshotsaturday'ing it up (started a #speakershotsaturday on twitter btw). Also changed the album artwork, totally got the idea from the previous gameplay video start screen. It felt good to start off the summer vacation with some laid back music making, it had been almost three months since I had put anything out. If you aren't into the boom bap, check the page later on Sunday night I'll be posting two beats sampling Pokemon Red/Blue's "Bicycle Theme" and Legend of Zelda Ocarina of Time's "Lost Woods" on violin.

We are currently working on submitting a late build to IndieCade (although we already submitted one to the earlier deadline), still trying to perfect the Unity 5.0 shaders now that the camera work is improving. One thing submitting builds has helped us with is the struggle between pacing a game and making it interesting. For HomeMake we aren't interested in a twitchy platformer, but more of a laid back exploration platformer. Submitting builds has helped us keep the exploration smooth, while still maintaining levels of interest; just because the pace is slower doesn't mean the experience should be any less immersive and entertaining.

[archgame]

I was super excited to wake up to an email informing us that HomeMake has passed the first round for BostonFIG! This is the first festival we submitted too, so naturally this was very exciting news for us. We have to submit a build of the game by Sunday 10 EST, so we'll be developing that over the coming week. If anyone wanted to share their experience from BostonFIG's second round last year, we'd be more than happy to listen! (We just submitted a late build to IndieCade last night, so we've got a build ready, it's always a challenge of how quickly to allow a judge to progress through the game; too fast and they don't get an actual feel for the game or too slow and they don't make it to the interesting part of the game).

In the meantime, I wanted to share some subtle changes we've made to the game. A Big one was updating all of our shaders to the new Unity 5.0 standard shader. Not only are we hoping this helps with optimization, but the new shader is really easy and intuitive to work with. One of the biggest changes we have enjoyed is the emission color and intensity. I've posted four screen captures below. The first shows what happened when we simply changed the shader from our legacy self-illum shaders to the new standard shader. As one can see, the city lost all of it's color (the buildings in the foreground still maintain their color though), as the buildings move away they become black and white.





After playing around, we realized this was related to the emission color of each shader. We adjusted for this and were able to realize a slightly more vibrant version of our previous city. I was going to include a screen capture of the original city also, but I deleted all the old emission gifs we were using for the legacy shader because they used transparency and that isn't necessary with the new shader, another great addition.





Another thing I changed briefly (one that had been bothering me for a long time) was the particle emitters that locate the robot parts to build Kigi. Before they were this basic sprite animation we had developed, but they didn't fit into the atmosphere we were trying to craft, they simply located the parts the best. In discussing gameplay at a micro-scale, we decided we didn't need the player to be able to find the parts so overtly. I'm sure most people here are well versed in game mechanic rhetoric from Jonathan Blow's Braid, which is what we were trying to follow when designing our puzzles in the beginning. However, we realized, first we want our player's to initiate a certain level of interest in exploring before opening up the entire world to them. One of the big desires our game has is for the player to explore the city, and if we make the puzzles super obvious, they will feel too led, and worse, when the puzzles become less obvious they could miss them all together. Towards this aim, we simply used a spark particle emitter on the robot parts, jacking the emission intensity up to well over 50 so the sparks would still be visible from a distance (as sparks in the real world would be). In the bottom image it is important to note how much easier it is to see the spark with the ground as its background, apposed to the spark on the roof with an emitting facade as its background. Something we'll have to take into account when designing puzzles.







Another thing you'll notice in the pictures is the subtle light reflection off the ground. We are trying to keep the ground as dark as possible, while allowing the player to stand out against it and provide a believable plane for the buildings to sit on, while adding to the overall atmosphere.

The final thing we did, was include a pause screen which shows the player controls (actually this is now our default start screen until we get a legit loading screen in place, also includes a transparent black plane). We thought this was important for sending the game out, knowing that people would have the controls a button push away (In English/Japanese, will likely include Chinese/Korean too).



Two big things we'll be working on next are improving the climbing (right now the most bootlegged part of the game) and creating a camera that can handle character jumping (right now if a character jumps too high, he'll just float off screen). I'm thinking of adding another pivot, this time at the plate position that only rotates when the character is jumping. After that we'll begin making additional puzzles for the other characters present in the world at the moment, it still feels too sparsely populated.

[archgame]

Our biggest take away from the MIT Game Lab studio was the benefits of play testing, it often points out extremely obvious flaws in the game. Typically we like to play test in dark spaces, ideally with a projector and good sound system; we are trying to mimic the environment of a basement (the spot we both typically played games in as kids), if we could find an old couch, we'd probably bring it along to our play testing locales.









We have learned a lot from play testing, especially in regards to character and camera control. Recently it became obvious we needed to add a zoom function to allow the player to see potential architectures for scaling and traversing. In the screen captures, one can see the different angles now possible by pressing down R3 (we had to redo our controller graphic too, although this wasn't super hard). The top picture shows the architecture that needs to be platformed on, giving an idea of its height. The second shows the standard view, which is all we had before the zoom feature. The third picture shows the zoom, and the player's new ability to see ledges for platforming. The final view shows the building towards the top from a zoomed out perspective. Now we have to find a way to make the avatar stand out against the building, they becoming difficult to see the farther the zoom.

In adding the R3 button, we ran into a problem I had been ignoring for awhile, while using the Playstation Dual Shock 4 controller, some buttons were creating a double input (we are using Jays2Kings DS4), meaning I would press R3 and it would simultaneously set off the options button. After an afternoon of digging around the net, I learned that Unity tries to map the PS4 automatically, alongside the input from the DS4. In order to fix this I had to hide the input on the DS4, after which it worked fine.

A positive coincidence of all this was I had to remap the PS4 controller, basically mimicking an Xbox 360 controller input. Luckily, one can now use either a PS4 or a Xbox 360 controller to play the game, this should be really beneficial when we send out our game to a number of people for beta testing. We are still debating what if any keyboard controls to provide for the game, likely we'll use a typical 'wasd' with a mouse for the camera, but we are unsure how to handle some other buttons like the triggers.



In preparing for BostonFIG round 2, we have been tightening up some loose ends we've let float. One thing we have smoothed out is our quasi-tutorial, which has buttons floating when they can be pressed (above the characters head, ready for a swap in the picture above, Playstation circle button in case that isn't clear). We are simply trying to make the buttons subtle and as unobtrusive and immersive as possible, I kind of wish controllers had LED buttons, that way one could simply light up a button on the physical controller when it could be pressed, taking the tutorial out of the screen completely.



We haven't talked about story much on here, so I thought I'd fill in some of the blanks in order to describe this particular gameplay we have been working on (probably a spoiler alert, but nothing too serious). First off, in our gameplay video, you'll notice the initial character Iso gathering parts. These parts are pieces of Kigi, a robot he has been working on. After he gathers the required pieces, Kigi appears. When Iso body swaps with Kigi, Kigi's perspective can now be accessed (the glitchy one above, Iso's perspective being the standard one). The idea behind the game mechanic is that each player has a unique platforming ability (i.e. Iso only has a single jump, while Kigi has a double) and a unique perspective (i.e. Kigi's glitchy perspective and Iso's standard). The perspective is more than just a visual overlay though, in the image above one can see a stream of white particles emitting from the left (and if one squints, there is another stream of particles off in the distance on the right). So along with the glitchy visuals, Kigi also has this ability to locate other swappable characters based on these particle (data) streams. The game play comes in when you start swapping and mixing perspectives with different platform abilities. We are still working though some of the other puzzles, but we should have those up shortly.

This would be a lot more obvious as a gif, given the fact that movement is what sets the particle stream apart from the background, but my gif capture spazzed out, probably due to the glitchy perspective I imagine, maybe next time.



Lastly, HomeMake made an appearance in the Graduate School of Design's commencement exhibition, you can see it bottom center along side a number of other stellar projects. During the actual ceremony, postcard's featuring all the projects were available.

[archgame]

Sunday night, with less than an hour to spare, we submitted our build for BostonFIG!!! Had some last minute hiccups (per the usual), but it all worked out. We enjoy festivals as they give us a deadline, which helps push us to complete tasks, else the perfectionists in us might get away. For the build we really wanted to concentrate on having all the characters playable, with relevant perceptual changes. The most successful character was Yagi (the deer). When swapped into, the world changes to a washed out winter scene. In this mode certain flowers are still in bloom, while others have withered; one can imagine how this becomes a puzzle prompt when parred with different flower locations that Yagi may not necessarily be able to access due to its single jump. This is really the first perception, where the environment changes (requiring some new code that doesn't let the visuals change until the relevant environment has swapped; without we were getting epileptic inducing strobing of the ground). While this is a minor step, it is something we are excited to continue to explore in the future with likely grid swapping and building changing/transforming/moving during particular perceptions. From the beginning we have been interested in making a system of game mechanics that generates variable gameplay experience, which we can weave into a universe/narrative.







Lastly, I just wanted to mention that our song "Back In The Rain" was featured on IndieCade's #soundwall. You can find it here if you are into tumblr or here if you are more the tweeting type (which now has soundcloud integration!). I stumbled upon their soundwall about two weeks ago, it has a lot of quality and varied game music, which can be a great way to find new games. HomeMake music can be found in it's entirety here, currently working on some modal jazz pieces.

[archgame]

Our first public showing of HomeMake was a review for an Immersive Landscape class, where one of the critics pointed out that while our city appeared to have differentiation, it was in fact a homogenous sphere of urban fabric. Since this critique we have been busy designing difference into the system. Recently we have attempted to add three suburban based neighborhoods into the city.

For us the notion of suburbia, or better a contemporary familiar domestic setting, has always been important as the beginning of the game. A number of our favorite games and most memorable levels occur in this environment: Pokemon, Zelda OoT, Paperboy, Ni no Kuni, and Earthbound (Tolkien even uses this environment as the starting point for his famous stories).







The first suburban neighborhood has open yards the player can run through.







The second suburban neighborhood has houses closer together which allow the player to move between roofs.







The third suburban neighborhood has houses that all touch, creating narrow alleyways (ryoji).

There is still a lot of work for these neighborhoods to capture the environment we are seeking. First, the facade material will need a decent amount of work, getting the lighting just right to give the neighborhood a more quiet feeling. Second, the addition of other objects in the environment will begin to describe what type of suburb it is: street lights, gardens, trees, mail boxes, signs, gates, fences, etc. I wanted to post these pictures to give a sense of where the neighborhoods began before placing all of the objects.

You'll also notice the buildings are now assembled from a roof and a wall. We had to implement this as the character collider and camera raycast needed to act differently when colliding with the side of a building or the roof of a building. Unfortunately, when viewed form across the sphere, the city lost a bit of it's polychromatic wonder, so we are now looking at how to edit the roof material so it differentiates from the wall while still allowing the original urban aesthetic.

[jctwood]

It is incredible to see how far the project has developed and changed since I originally laid eyes upon its beauty. Excited to see what is coming next. Urban generation is a passion of mine.

[archgame]

@JctWood thanks, it's nice to know the change is noticeable, one reason I enjoy keeping the devlog. Although, we still have a way to go to develop the game we are imagining, but the encouragement is much appreciated!

I realized while I talked about suburban elements in the game, I never fully explained our reasoning for wanting it as the initial level. We imagine that most of our players will be coming from a suburban setting in reality, and we believe these types of settings act as a threshold between a players reality and the entirety of universe we are designing. In doing so we hope the world we have designed is relatable and vice versa, allowing the player to relate aspects of the game to their world.

We've been trying to zoom in on the district and add micro elements, that will eventually aid in the gameplay. As a test I just reinserted trees, light poles, mailboxes, and sidewalks into one of the suburban districts. I'm happy with the diversity it gives the streetscape and we'll continue crafting unique urban elements for each district.

Additionally we've implimented a culling script on the camera for various sized objects, currently we have two settings, medium and small. The necessity for this comes from the spherical nature of the environment, we can't have everything always culled or the player would see a void when they looked up to the city. However, we also don't need the polygons on flowers rendering if the player is across the sphere. Right now the culling seems to work well, it's no less noticeable than in other open world games and we are happy with it.

[archgame]

Added three more districts with unique architecture massings in HomeMake. This first one is supposed to be one of the denser districts in the city. Likely it will have a more unpolished atmosphere, narrow alleys, and multiple pencil towers; like if the countryside was multiplied, stacked, and repeated until it was so dense the countryside was no longer mappable, but a ghost of its atmosphere was still there. I've also finally gotten around to adding aircraft warning lights to the tops of the towers. I love cinematic shots that show urban landscapes at night with these gently pulsing lights. It really gives a sense of breath to the city, from that distance it tends to be the most noticeable form of activity in any city. This is our first attempt at bringing the city to life.







The next two districts aren't entirely new, but we have adjusted their urban grid and split the architectural massings into facade and roof. This first one is intended to be a place for subculture development in the city. It provides a necessary density, with highly heterogeneous spaces. There will likely be a lot of activity within the building blocks and between the streets.







Here is the final adjusted district. It is imagined as an entertainment district. The smaller scale objects will be key to making this district pop and come alive. We'll be adding a number of digital and neon signs that should add a lot to the atmosphere. We are still debating on what to do about the roof textures, we'll likely run a few tests soon. Finally, if memory serves me correctly (which it rarely does) these are the first screenshots I've included which contain the stats while playing the game. I'm not an optimization sensei by any means, so if anyone has any input, that would be great to hear.

[JobLeonard]

Now this looks like it's a different game... subbed

[archgame]

Code:

using UnityEngine;
using System.Collections.Generic;

public class Atmosphere : MonoBehaviour {

	public AudioSource[] atmospheres;
	public GameObject[] objects;

	private Vector3[] centpos;

	private Transform playerPosition;
	private float distanceAway;
	private float distanceSet;

	private int district = 0;

	private float[] atomset;
	private float[] atomlerp;
	private float mixadjust = 0.005f;
	
	void Start () {

		centpos = new Vector3[objects.Length];
		atomset = new float[objects.Length];
		atomlerp = new float[objects.Length];
	
		for(int i = 0; i < objects.Length; i++){
			centpos[i] = objects[i].transform.position;
			atomset[i] = 0.0f;
			atomlerp[i] = 0.0f;
		}
	}

	void Update () {

		distanceSet = 1000.0f;
		playerPosition = GameObject.FindWithTag ("Player").transform;

		for (int i = 0; i < objects.Length; i++) {
			distanceAway = Vector3.Distance (centpos[i], playerPosition.position);

			if(distanceSet > distanceAway){
				distanceSet = distanceAway;
				district = i;
			}
		}
		//MIXER
		for (int i = 0; i < objects.Length; i++) {
			if( i == district){
				atomlerp[i] = 1.0f;
			}
			else{
				atomlerp[i] = 0.0f;
			}
			atomset[i] = Mathf.Lerp (atomset [i], atomlerp[i], mixadjust);
			atmospheres[i].volume = atomset[i];
		}
	}
}

@JobLeonard Thanks, much appreciated! Hopefully it will continue to be different in interesting ways.

I don't think we've ever included a screen shot straight from Unity (not in my recent memory at least), so I thought I'd include one. I also am excited by the fact that in the game view one can begin to differentiate parts of the cities. I'm sure they will need to be stitched back together eventually, but for now this is a nice departure from the city's homogeneity.

Aside from physical differences, one of the most powerful methods for achieving a given vibe in the city is to use a soundscape. The audio is able to give the city a feeling of being alive that would take a ton of animation effort to achieve a similar quality. I've also included code for the different district atmospheres I've produced. I didn't post the atmosphere sounds to soundcloud as they aren't that interesting on an individual level, but when they are layered with the music they sound really nice. I've kept the atmosphere on similar time signatures to the music so ideally it not only gives a sense of place, but adds a acoustically harmonious element to the experience. I've decided not to use three dimensional soundscapes for the atmosphere as keeping it two dimensional and a child of the camera gives me much better control over the quality and the threshold at which the soundscape changes. All the musical pieces are treated similarly so this made sense, I think character sound effects will be the only sounds not tied directly to the camera. Again, Unity 5.o's mixer was seminal in giving me a new channel to add the atmosphere and effects to it.

I'm currently trying to tweak the avatar controller. I know awhile back I said I had landed on a definite scheme, but I was wrong (I think that is like the fourth time now). So the reason Unity's Character Controller component works as it does is because it treats the Y axis differently than the X and Z. I thought I would be able to work around this, but after some testing, it really appears this is the main issue (i.e. when the controller needs to switch the axis between positive and negative it always freezes). I've already successfully swapped everything to a rigidbody, physics based controller, which was surprisingly more simple than I expected. As expected however, it works slightly different, so now I'm working on tweaking that so it works well.

We are aiming to send out a beta build to our backers before the month is over. Aside from working on the controls, we are trying to decide exactly how much to include and what will give us the best feedback for our game. Additionally, we aren't sure the best method for distributing the build: Google Drive, itch.io, gamejolt, etc. If anyone has suggestions that would be great to hear.

[Voltz.Supreme]

Mind melting! Keep the visuals crazy rather than busy

[archgame]

Long time no devlog! I was teaching summer session and it just ended, now it's back to HomeMake full time, well at least for August until the semester starts in September.

Right now we are focused on getting enough into a build so that we can share it with our backers and get the kind of feedback we are looking for (i.e. not the character controller jitters, but more along the lines of this part of the world made me feel "x" and I would like to see more "x" or I thought the game would have "y", basically not a bug report, but more conceptual feedback).

One thing we haven't talked about a lot on here is the number of gaming articles we read and how this continues to mold, shape, and lately confirm the direction our game is going; these articles are a great way to situate our game in a larger context. Recently a few articles really stood out to us.



This first one appears on Killscreen, a publication we can't recommend enough. The first article is "You'll Sniff Out Fun in this Urban Dog Simulator" by Ethan Gach. The article high-lighted a number of issues we are looking forward to exploring, namely what does it feel like to be in a system when you aren't the systems main client and what is it like to experience a familiar environment with an unfamiliar avatar. Furthermore, we have a fox character "Sandwiches" who we've always imagined operating in a similar way to these dogs.



Lately we have been trying to create a lot of episodic content that fits into the game mechanic system we have created, Katherine Cross' article "What Brings a Virtual City to Life?" solidified to us that we are indeed heading in the right direction with our episodic content as a means to add life to HomeMake's Galaxy SEED. To quote Cross: "Making cities lifelike in a single-player game requires giving players a means of interacting with the place without violence." I can't remember if we have specified this before or not, but we are trying to limit HomeMake's gameplay to non-violence, not out of any ethical dilemmas (one of my favorite games is Tekken), but more in that we view the trope of violence in video games as a limiter to the creative possibilities in games and in including violence, it further distances the game's system's ability to relate to context outside of gaming.



Another article that we felt related to HomeMake's ambitions was "Muse Answers The Question: What if John Lennon Helped Create Earthbound?" by Michelle Ehrhardt (I can't find her on twitter, if anyone knows I would love to follow her). We've enjoyed a number of Pixeljunk games so it was no surprised the studio was involved in this game. To sum up Earthbound/Muse = LoZ:MM/HomeMake.



Lastly, we'll go over some recent coding developments. The first involves the movement of water inside the Galaxy SEED. A number of scripts manipulate water by simply adjusting each vertices' "y" position, however this will not work on the interior of our sphere. I created a script that basically does the same thing, but instead of adjusting the y position, it moves the vertices normal to the surface of the sphere. Next up is getting some fish in the river and lake for some quality fishing referencing one of our favorite activities in two of our favorite franchises: Pokemon and Zelda. I found Vector3's static function Vector3.MoveTowards seminal in creating the script, it took a lot of math out of the equation.



One of the episodes we have been working on involves a Ferris Wheel (fun fact, I went to school with the great grandson of the inventor of said contraption). The wheel will be great for providing a different panorama of the city and giving an icon for navigation purposes. Furthermore, the movement (again) brings added life to the city. There was a bit of a challenge in getting the avatar to ride in a carriage nicely. I had to create a script that disable the character controller and updated the avatar's position with the position of the carriage. He's really small, but you can see Iso riding the wheel. I think I'll make some special camera states just for the Ferris Wheel, I like the idea that there could be a camera state that mimics the one from Childish Gambino's 3005.





The park will be the only retreat from the urban fabric, although we hope to create moments of peace within the city to contrast with the hustle and bustle found throughout the city; I wouldn't be too disappointed if moments in the park felt like a Miyazaki film.

[jctwood]

Wow Water! I have to say I never expected that. 3005 is a great song and a selfie cam is fairly mandatory in games these days.

[archgame]

@Leo J The line between busy and crazy is always a fine one, I don't know if we are necessarily going for crazy either though, our ambitions are to design an urban landscape that is exciting for us to inhabit, we appreciate the concern though and we'll keep the busy in check! We hope in the end certain parts of the city have a high level of busyness and others are more laid-back, boarding on Miyazaki rural. This is something we've experienced in Tokyo with its egg shell urbanism, whereby you can move from an avenue of tall modern buildings to a back alley with lush vegetation and older, smaller structures, creating very distinctive atmospheres within the city.

@JctWood The water is key to a few exploration episodes that involve Yaji (the deer)'s perspective swap, which freezes the water turning it into a traversable surface. 3005 is indeed an excellent song! I hadn't thought of the camera in terms of a selfie camera but I like that name; additionally it would force us to finally confront the faces of our avatars (we've had some extremely laughable attempts, we'll have to make a post showcasing this).







I feel great today because we finally nailed down our problem with the character controller (for those keeping track: 1)controlled with animations, 2)controlled with transforms, 3)controlled with character controller component, 4) physics based controller). The physics controller has been working great, the controllers have continually used code and built off of the previous controller script and they have each improved. The only problem with the physics controller was a slight jitter. This is a pretty common problem with physics controllers in Unity, but after exploring unity forums for the past two months and trying every solution I was about ready to give up. Today I sat down determined to once and all figure out this problem, commenting out each line of code until I found the root of the problem. No matter what combination of commenting I did, I could not find the roof of the problem; I thought I was going crazy. I decided to try some other characters (we normally stick to Iso for testing things out). While trying another character I noticed "Apply Root Motion" was checked in an Animator, a legacy from our very first character controller script. After unchecking it, the jitter went away, although now I'm left with completely uncalibrated control parameters which will take some minor numerical adjustments. Looking back this was a pretty noob mistake and I'm just happy and relieved to have it behind me.

We've started populating the park with procedural vegetation, previously the trees have always had pretty standard colors, but we were trying to adjust them to get that deep forest feel. Additionally, we want the forest to feel like a HomeMake forest, the rest of the environment has a distinct art direction and we need the forest to follow suit.



Lastly, I posted a new beat sketch last Friday, LA Rush. I made it during my bus ride to and from NYC where I met up with a friend for a night to catch up and reminisce about Tokyo, Architecture, pub concepts, etc. Most of the songs for HomeMake are pretty laid back, but Franklin wanted a more upbeat one, so I modeled this one after

from Cowboy Bebop (episodes Honky Tonk Woman and Wild Horses), thought it was appropriate for my trip. We've been compiling the songs on a HomeMake Playlist on Soundcloud if you haven't heard any of the previous ones.

[troyduguid]

Big fan of this project - I love seeing games that reflect their creators personal background/other professions.
The art style/tone gives me a distinctly early 2000's vision of the future, (I guess stuff like Dead Leaves, Jet Set Radio) is this something you were going for? I dig it, feels new and nostalgic at the same time to me.