next »

[archgame]

We are currently looking at redeveloping our game’s character controller for the fifth time. At this point, our other side projects are becoming fruitful enough that we have extra capital and it seems that it might be wiser to hire a programmer to do our character controller instead of us continuing to bang our heads. Before posting on hiring boards however, we wanted to get input on the scope of work and how to best articulate and define what we are looking for. Towards this end we developed the following scope for the character controller.

(We also started a new thread over in the Business forums of Tigsource and it'd be ideal if any comments about the Character Controller would be put in that thread to keep things neatly organized and continue the discussion already happening).

Character Controller Scope

Introduction:
The character controller will be used on multiple playable characters and will therefore need to have variables exposed publicly for easy adjustment in the unity editor as well as booleans for each function to determine if the player has the ability to do them. A controller input script will be provided, from which all input should be derived. Additionally a Mecanim tree will be established with animations input (although this is subject to change with programmer input). It should be assumed that whenever “up” is used in the function descriptions, it is referring to a direction vector related to the character's base and center of the sphere. For further clarifications on the desired move functions the programmer may reference Wind Waker for all functions except the Jump function which they should reference Super Mario 64 for the initial Jump and Super Smash Brothers for multiple Jumps. Using the Super Character Controller, the character controller will need to perform with the following functions:
 
1. Idle:
Character is grounded and after a certain amount of time will begin to cycle through three idle states.
 
2. Walking:
A joystick push of any value less than a full push (i.e. 1.0) will move the player forwards at a rate determined by the walk variable as defined by the direction of the joystick as it relates to the current camera position whereupon the joystick will move the character towards the top of the screen, away from the player. While moving the character should reorient its up orientation each frame.
 
3. Running:
A full joystick push (i.e. 1.0) will move the player forwards at a rate determined by the Run Variable as defined by the direction of the joystick as it relates to the current camera position whereupon the joystick will move the character towards the top of the screen, away from the player. While moving the character should reorient its up orientation each frame.
 
4. Jumping:
When the Jump Button is pressed, the character should move in the up direction by an amount determined by the Jump Variable. While Jumping, the players forward direction should be locked and any forward movement should be added to the Jump direction. There will also be included a Number Of Jumps Variable which will determine how many sequential Jump functions a character may perform without returning to a grounded state. If the Jump Button is pressed while Jumping and the maximum number of Jumps as defined by the Number Of Jumps Variable has not been reached the character should move in the up direction by an amount determined by the Jump Variable. When the character reaches the height as determined by the Jump Variable, the character should switch to a Falling state.
 
5. Falling:
When a character is not grounded (as determined by the characters distance to a surface with the appropriate grounded classification), the character should enter the Falling function, unless in the Jumping or Climbing function. While in a Falling state, the character should be moving opposite of the up direction with the addition of any forward movement at a rate determined by a global Gravity Force Variable. When the character collides with a surface containing grounded information, a landing animation should play and the character returns to a grounded state. If the character has any forward movement, the character should immediately transition to either a Walk or Run state depending upon the Joystick variable, and if there is no forward movement, the character should transition to an idle state.
 
6. Climbing:
When the character is within a globally defined range to a surface deemed climbable by tag and the Climb Button is pressed, the character will enter into the Climbing state. The Climbing state is entered into with a Mounting Animation. While in the Climbing state and the Joystick is pressed in an up direction the character should move in the up direction parallel to the mounted surface (not the center of the sphere). If the Joystick is pressed down the character should move in the opposite direction of the up direction parallel to the mounted surface. If the joystick is pressed to the left or to the right, the character should move to the left or right of the mounted surface. The character will exit the Climbing state when the become grounded, reach the top of the mounted surface, reach either side of the mounted surface, or reach the bottom of the mounted surface. All dismounts except for the top surface dismount will play the standard Dismount animation when entered into. The top surface dismount will play the Climb over animation and the character shall be moved in a negative perpendicular direction of the mounted surface into a grounded state.
 
7. Swimming:
When the player enters a surface deemed swimmable and the difference between the ground surface and swim surface is larger than three/fourths the character’s height as determined by the Height Variable the character shall enter the Swimming state. The swimming state is entered into with a Swim Enter animation. While in the Swimming state a joystick push will move the player forwards at a rate determined by the Swim Variable as defined by the direction of the joystick as it relates to the current camera position whereupon the joystick will move the character towards the top of the screen, away from the player. While moving the character should reorient its up orientation each frame and its position on the swimmable surface, the animation will be adjusted to make it look as if the character is below the surface.
 
8. Floating:
When the player enters the Falling state and the Jump Button is held down the player will enter the Floating state. While in the Floating state a joystick push will move the player forwards at a rate determined by the Swim Variable as defined by the direction of the joystick as it relates to the current camera position whereupon the joystick will move the character towards the top of the screen, away from the player. While moving the character should reorient its up orientation each frame and its up position as determined by the distance from the player to the sphere when the Floating state was entered into.
 
9. Driving:
While in the Driving state a joystick push will move the player forwards at a rate determined by the Drive Variable at an acceleration determined by the Acceleration Variable as defined by the direction of the joystick as it relates to the current camera position whereupon the joystick will move the character towards the top of the screen, away from the player. While moving the character should reorient its up orientation each frame. While in the Driving state, joystick presses outside a defined range will have no effect on the characters movement (i.e. the character will not be able to immediately rotate in 180 degrees, but will be forced to turn at a rate similar to a wheeled vehicle).
 
10. Pushing/Pulling:
When the character is in a defined proximity to an object that is pushable and the Push Button is pressed the character will enter the Pushing state. While in the Pushing state the character will reorient so that the characters forward direction is perpendicular to the nearest surface of the object. While in the Pushing state if the Joystick is pressed up the character and object move in a forward direction as defined by the perpendicular orientation direction. While in the Pushing state if the Joystick is pressed down the character and object move in a backward direction as defined by the negative perpendicular orientation direction. While in the Pushing state if the Push Button is pressed, the character exits the Pushing state.
 
11. Sitting:
After a determined amount of time the character will enter into the Sitting state. The Sitting state is entered into by the Sitting Enter animation, which transitions into the Sitting animation, which is a random series of three animations. When any Button or Joystick is pressed by the player, the character exits the Sitting state with the Sitting Exit animation. The Sitting state is also determined by the proximity of a sit-able surface or ground, which will determine which animations and where the character is located.
 
12. Interact:
While in the Idle state and the Interact Button is pressed the character enters into the Interact State. While in the Interact state the character plays an animation determined by the nearest interactable object. For example if the nearest object is an NPC, the character will play a Talking animation. For example if the nearest object is a collectable, the character will enter into a Pick-Up animation. If the Interact animation has an exit time, this will determine at what time the character will exit the Interact state. If there is no exit time for the Interact Animation, pressing the Interact Button again will exit the Interact state.

Also recently posted a new mix to chillanimebeats (it's good for summer drives and general hanging out vibes).

[archgame]

Just posted an updated draft of our character controller scope over in the Business forums (this time with the addition of a Camera Controller scope). I think we'll probably post the job towards the end of the month, hopefully people will be interested.

While we are sorting out this character controller and camera stuff, I've still been trying to keep busy with other aspects of the game, in the mornings I've been working on the city, trying to get the urban massing down so that I can switch over to architecture scripts.

At night I've been doing some speed-run character modeling just to force out ideas and get new things ticking (sort of the quantity over quality motto atm). We'll polish soon enough.

[archgame]

Realized it would be good to get some technical expertise on the character controller and camera scope, so I started a thread under the technical forums. We'll be posting the job at the end of the month (it's a long dense read just a heads up).

Also tonight, HomeMake's good friend Mahmoud gave a talk about the game's audio at the Southbay Game Dev Meetup!

And lasty, some speed-run character designs from the last few nights. For those curious about their design's and the process, I suggest a short read of Jonathan Lethem's The Ecstasy of Influence (an essay I came across during my architecture thesis, which hasn't left my mind since as both beat culture and architecture history are pro-sample/typology based design processes).

[archgame]

Earlier in the week we posted two job listings looking for a programmer for our character controller. We've gotten a lot of really quality responses about it and were a bit overwhelmed with the amount of people interested in providing some much needed programming help on the project.

$5-$10K Character Controller Script (Tig Forums)
$5-$10K Character Controller Script (Unity Forums)

Aside from sifting through the interested programmers, I've continued revisiting how the city is designed. There's a sketch showing some really dumb diagrams (definitely not as elegant as our earlier ones), by dumbing down the design at the urban scale it's allowing for a more iterative and holistic approach to the city. I also broke the script up so I can work simultaneously on fine tuning the overall urban massing and design more specific architecture. The output of the urban massing is always a six sided form, which will act as the building envelope. So I can begin designing architecture objects to go in these forms and still have the ability to change the overall city without having to deal with elements at the architectural level. Additionally the dumb geometry will act as a sort of billboard for loading and unloading the detailed architecture.



I also included a shot of my grasshopper script to show how it is organized in a similar manner to the sketch (also in the sketch there is a small diagram I sent to Cory explaining the new urban design workflow).



Here's a rendering of the current state, which isn't complete yet (I've got a list in a text document on my desktop I'm working through). Conceptually I'd still like to see more boundary blurring as well as variation between areas. That's the goal, maximum blend and polycentric variation. I'll also have to change my render settings, that's a pretty bad image, but it's late and I've got work in the morning.

[archgame]

Just posted our 22nd update for our kickstarter backers and published our second build on itch.io (currently the project is only being shared with a secret URL, will probably make it public around the holidays, also thinking of posting to itch.io's devlog too). With the help of Sundae Month, we've finally got the controller issues hammered out for the most part, though we'll still be working on those, really aiming for that smooth feeling.

This quarter we are aiming to publish a lot more frequently to itch.io in hopes of iterating and getting feedback so that we make sure we are moving the game in a good direction and not bike shedding.

Also, we've got a new instagram and twitter, which we'll be posting to (mostly visual things and event announcements etc., if you only follow on tig you won't miss anything, but it's just easier to post on twitter (and personally I find it easier to follow content on twitter)).

[archgame]

Just updated the build with more camera controls and some small audio tweaks (made it so that drums don't come in until the game starts and added ducking to audio routed from the drum track on Unity's audio mixer).

[archgame]

A lot of our playtesting feedback has been expressing a desire for the city to be more differentiated. So last night, we set up twenty cameras in different neighborhoods around the city and I made a script that automatically exports and compiles screenshots from all these cameras, so we can have weekly iterations with the goal of moving towards unique looking parts of the city. This will be the first screenshot, and hopefully the development will be obvious through subsequent iterations (just in time for #blocktober!)

Has anyone used Unity's player heatmap analysis? I'm debating whether I should learn how to use it or if I should just write a script that outputs a text file from each playtest. Does anyone have experience documenting playtesting in this way? I figure I'll just have my playtesters send me a text file from the game's temp folder? I've never done anything like this so any advice would be most welcome.

Also shoutout to neko.works [3D JRPG Light Fairytale] for putting me onto this Dark City asset store find.

[nathy after dark]

I don't understand much of what I'm reading/looking at in your first post but I can tell it's awesome and maybe with sleep I'll be able to figure it out. 

[archgame]

@nathy grrl: We are trying to figure it all out too!

Hit up Omocat's pop-up shop this weekend to check-out Omori and also swung by IndieCade to meet Sundae Month and play There Might Be Ponds, also caught a glimpses of Innerspace and That Blooming Feeling.

Updated the build again this weekend. Made a map to track player movement, tried to automatically pop-up the persistent.datapath folder upon exiting the game, but it pops up a completely different folder (the play test file is in the correct location though)?

Code:

System.Diagnostics.Process.Start("explorer.exe", Application.persistentDataPath);

We'll continue to update the build, I'm interested in making the players stand out from the background a bit, not necessarily making them more noticeable, just unmuddel it a bit.

[archgame]

Updated the build with tweaked controller and camera scripts. Also reinstated the switch particles (cleaned the script up a ton, runs much smoother).

The games getting pretty close to the point where we'll have to start optimizing it. I created a layout design for a loading and unloading script which I'm still working on, but I was wondering what other people have found works best for optimizing? Do you just watch the (Unity3D) Profiler and see what is taking up the most resources?

Also added some new songs to the game, mostly melancholic chords from a rhodes.

Just pulled 126 billable hours (two weeks) at the day job, so haven't gotten to the dioramas yet.

[archgame]

We are showing the game in VR in two weekends at Dopium (In Chinatown). This week we'll be making sure the VR is implimented along with getting networking to work correctly as we want to project along with having VR (every event I have attended with VR is so much better when people see what's going on inside the goggles). If you are around Los Angeles on Nov. 4, come say hey to us at Dopium.

https://www.eventbrite.com/e/dopiumla-one-night-of-culture-creativity-cuisine-in-chinatown-la-tickets-37349096152

We've also been messing with some new shaders, so hopefully we can make something of those soon.

[archgame]

[archgame]

[archgame]

Got the play test tracking implemented. For our demo build, the game outputs a csv file that contains information about location, camera, and character. We are hoping to begin compiling maps of people playing the game in hopes of finding out how they are exploring the space.

I also began designing our loading system, game is getting a bit heavy. Since the city is a sphere, there are a number of points distributed evenly around, each associated with nearby scenes (which are broken up into massing and detail, so there is a LOD for the scene loading too).

One of our play testers requested some way to feel their progress or map their exploration. We are resisting the use of maps to create a better sense of exploration, adding something to indicate player/game/character progress seems like a really good idea. Our immediate thought was something similar to the masks of majora's mask, but we haven't used any UI elements at this point and don't want to start now.

[archgame]

Updated the build on itch.io, now with floating abilities, which proved to be the chillest way to traverse the city.



We also showed the game at 2426 last night alongside Slamdance DIG!.



Just trying to add content to the game atm.

[archgame]

tl;dr additional tips for optimizing additive scene loading?



As one can imagine, our city contains a lot of data and we hit a wall recently were it became really tantemount that we figure out how to break the city up to load in more manageable chunks. The system uses a number of points (each with a list of areas attached) and the player's distance to these points to determine a list of scenes to load, using Unity's additive scene loading. The code below shows the function for taking a list of scenes and adding them to current scene.

Code:

private void LoadList(List<string> scenesToLoad)
{
    foreach (string newScene in scenesToLoad) 
    {
        AsyncOperation async;
        async = SceneManager.LoadSceneAsync(newScene , LoadSceneMode.Additive);
    }
}

As one can see by the profiler posted, there is a spike in CPU during gameplay when the scene(s) are loaded. Resulting in one or two stutters. Is there anything I should be doing differently in the above code? Does it matter where an AsyncOperation is defined? Should I only set one scene to load at a time an only load the next scene when that one is done loading? From searching on the web one thing I'm going to also experiment with is initializing objects not immediately upon load, but i'm still debating the best way to do this. Another thing, once I build the game, where is the proper folder to store things so they don't take up memory and only load when they are called? I seem to recall something about a "Resources" folder.



I've also output a map of player's running around the world from a recent playtest. Not exactly sure how we'll use this information, but glad to have it!



Lastly, I've been doing more detailed modeling with the assumption that I'll be able to load and unload objects in the city.



tl;dr additional tips for optimizing additive scene loading?

[archgame]

I've just finished up tool development with the anticipation of iterating through city designs faster than we previously were. For our current city I've created four tools although I'm sure there will be more.

Tool 1:
The first tool (which doesn't have any graphic components) was written for rhinoscript and automatically exports the city into the correct fbx format, in the correct unity folders, meaning whenever I use the other tools to iterate the city, exporting all the ports is a single click of the button (previously this would take about 30 minutes with all the file naming).



tool 2:
While 95% of the city is generated through scripting, I did create a tool that allows for singular massing placement while correctly orienting to the sphere and topography, while also being baked into the correct set of related massings. This will be used for things like schools, towers, museums, etc., that are generally idiosyncratic to the surrounding urban fabric.



tool 3:
Tool 2 along with the urban massing script provide a generic box urban fabric, which feeds into the third tool. This tool takes a hand modeled piece of architecture (mesh/brep/point/curves) and morphs it into the box massing, allowing for easily iterating through architectural detail, while still conforming to the urban landscape.



tool 4:
The fourth tool is an addition to the player tracking script. This tool has the ability to take a screenshot with the press of a button and this screenshot location is added to the player tracker output, allowing for post-testing red-lining and coordination with the model outside of unity (making orientation inside the sphere as easily as possible for adjusting the massings).



One last thing, HomeMake will be at Rockage 7.0's indie dev tables through South Bay Button Mashers. The event is at AFKgg, so check it out if you are in the area, would love to have some in person feedback.

A final note, while day-dreaming lately I've been thinking about the story/narrative of the game and I've recently landed on an idea that involves being lost, I think I can script it easily enough by the end of the quarter and don't want to say too much more until I have a working prototype. In the meantime, I'm going to get back to iterating through the city's architecture.

[archgame]

Showing a new build for the indiedev showcase at AFKgg Gamer Lounge for Rockage 7.0 if anyone is in San Jose.







Spent the week updating the camera and controller scripts for the indie game showcase today. I also added the new city for the first time, along with the old city, so the build is currently a frankenstein of a game, but events like this and continues build iterations are forcing me to make my tools and workflows more efficient, which is helping get design decisions in the game faster and see how they are actually feeling. Three project deadlines at work this week so I'm going to spend the weekend watching movies and reverse story-boarding with the aim of getting some cutscene ideas for a short intro to set the mood and one to introduce the main objective. Next week I'll be getting back into modeling architecture and architecture details to instantiate in the city. A big thing I realized after doing this build is I need to work on shaders and materials, all the colors seem a bit muddy and I'd like them to pop more like they do in anime, while still being influenced by lighting conditions. I've four images below from sources which have the shader qualities being aimed for (ours being a combination of the four or influenced by them). If anyone has material/shader advice, it'd be much appreciated.




Showing a new build for the indiedev showcase at AFKgg Gamer Lounge for Rockage 7.0 if anyone is in San Jose.

[archgame]

Rockage sounds like it was a huge success on Saturday! The game got a lot of feedback and some new thoughts. It always feels really good to have people continually playing the game as it progresses, a really good reality check and reminder what this gamedev is all about (Shout out to a good friend of HomeMake and their girlfriend for hanging out with the build all day and chatting with people).



After the showing, I created a new map tracking the play testing from Saturday. This map I color coded based on which character the player inhabited at the time. The below pie chart breaks down character embodiment by time (apologies that the two colors don't match, I need to work on my google charting skills).



The chart indicates that people seemed to overwhelmingly prefer Kigi (the robot), which does make sense as currently this is the most developed character and one which out of this set had the most abilities (except for the Red Kigi, which appears to be the only character no one found or didn't switch into when they did, which is a shame, because he could hover!). Another take away from the map was that no one made it to the far side of the sphere, usually people make a full loop. This particular build did have the most "things" in it, so maybe it's a sign that the city is becoming more intriguing and people are taking the time to explore. I find these maps (and the history of cartography) fascinating and it would be cool to derive a game mechanic from this.



Having to output a new build so quickly for Saturday's event was a good catalyst for further design improvements. Since breaking out the city generation into multiple processes I've had to decide where to implement processes that were previously global. Case in point, I decided to encode the building massings with a naming scheme that indicates a lot of information about that particular massing so I don't have to recalculate it when instantiating architecture or details, which allows for a set urban distribution to tie the city together while still providing differentiation. I have an example and explanation of the naming scheme below, which each mesh will have a unique version of (also by massing I mean an extruded four-sided polygon mesh that represents the general size of the building).

Description:
District_SubDistrict_BlockNumber_ArchitectureType_MaterialType_Floors_FootprintSize_CornerType

Schema:
L#_#_###_A#_M#_F#_F#_C(L/R/N)

Example:
A1_3_344_A3_M6_F12_F68_CL

[archgame]

Working on some game mechanic and narrative aspects of the game in parallel and ended up creating this gif. Originally started as text, then a comic via note cards frank santoro style, and realized adding some movement made the concept more readable. Still not quite sure how the mechanics will work, a couple different directions it could go. The main idea is that the player would revisit a place to have found it changed, that sort of moment when you feel at home and lost at the same time.