Usagi no Charade, a.k.a Up the Rabbit Hole, is my pilot project for developing with Unity.
This is a third person adventure/platform game that started 3-4 months ago as a series of experiments recorded in my unity tech blog and my youtube.
I am designing this platform game as a microcosm involving live organisms and smart(er) AIs
About me: previously I released several games on the iPhone/iPad; before doing this I worked with a couple of companies as a scripting platform architect and game framework builder. So, Iām a game system builder who learned (the hard way) the difference between building systems and building games.
Today my focus was on tweaking the day-night cycle and experimenting with solutions to break down my level file as I want bigger ground meshes and the importer easily chokes on these (big level file with lots of big meshes = slow ).
Living organismsā¦ ? Iām chewing on this whenever I find time:
Iām responsible for the overall game concept / design; I write the code; I do level design and a lot of modelling. However several artists kindly help with this project, notably with concept art, animation and organic modelling.
Note: one motivation to track this here is that I hope to find people that want to do similar stuff (so, focusing on real-time / 3rd person 3D ) as Iām thinking of releasing the underlying APIs / framework and need sponsors. So, you can PM if you are interested or if you have work to offer in similar area.
I will updateā¦ maybe every 2/3 days, at least weekly I think.
Iāve been setting up a workflow to generate nicer details on the terrain. I write āgenerateā because it doesnāt involve much modelling ( this part is done in Blender, not Unity) .
Here you can see a very rough Cycles bake (left platform) which doesnāt do justice to what this can achieveā¦ Baking with Blender Cycles is really good news for people using Unity Free. I have a mini project thatās more suitable for this soā¦ later.
See my previous post for link to (updated) live build.
The reason big meshes and long import times wonāt do for me is that this would literally kill my level file. I probably need to write an automation. Would be curious to hear of anybody who tackled this before.
Would the character be able to run ? About level design you could use reusable platforms and premade roads segments this could help you speed up the level making.
Good work.
Modular design would speed things up, and quite possibly avoid the so called ālarge meshesā issue. I wanted to give myself a chance to do more focused, more detailed work by focusing on a small space thoughā¦
Run? Same idea here: trying to make more things happen in a smaller space (to the point, of course, where running would be dangerous/undesirable).
Maybe I got this wrong? As I see games where the character can run but actually their running speed is 120% of a normal walking speed, and the walking speed is 50% of that. I wonder whether this is about pacing the game without the āAw sheās moving so slow, she canāt even runā psychological gotcha.
Letās go back into Unity with a new video showing a different part of the map, and a different time of the day (if video is too dark on your display come back a bit later, recalibratingā¦ )
The changes involved a trivial modifier stack, geometry is 3 times heavier, frame rate not a concern (frame rate you see in video is irrelevant).
The scene now takes 5 minutes to import into Unity; I wrote a script to chunk the level file but 5 minutes isnāt atrocious, so I may bear with it for now.
Looks great. My only suggestion is a name change. Up the Rabbit hole sounds like something you are probably not going for. Maybe just change it to āDown the Rabbit holeā. You game though. Again, it looks great.
I wouldnāt be so sure. I mean, I know exactly what it sounds like.
Even so itās a working title and like many things it is subject to change.
I had the idea of an ill-tempered, fussy main character, this is evolving into an interpretation of the queen in Alice. So, aside from a bad pun the idea of looking at Wonderland from the other end of the scope helps putting design elements in perspective.
If it acts as a deterrent - say for instance discouraging people from checking this threadā¦ then itās a bad working title.
I finished cleaning up after improving the terrain (the new terrain is uneven in many places, which arguably looks better, but needs more work).
One interesting workflow optimisation was introducing ground constraints. Thereās a key shortcut to place objects on the ground but custom constraints are useful if we update the ground after placing objects on it.
Improved navigation when transitioning between indoors and outdoors
These transitions are tricky because the control scheme is not the same in 1st person (indoors) and 3rd person (outdoors).
When transitioning to indoors, first person controls are āeased inā using a gain parameter. A typical annoyance that this alleviates is when entering a building while holding the right arrow key, the view would start rotating to the right.
When transitioning to outdoors, I use a āwait for releaseā approach thatās trickier to get right. The idea is that, we lock on previous input until the navigation input pattern (which keys are pressed or not) changes. But we donāt want to read keys directly because this wonāt be compatible with keyboard-less platform. So it has to be done via Input.
In pseudocode:
Lock walking direction Yield until input magnitude decreases Yield until input magnitude increases Unlock walking direction
Other stuff
Iāve been working on Blender scripts to use blend files as asset libraries and correct other export annoyances but I hit a quirk thatāll force me to do things in a roundabout way. (<= please click on this if youāre familiar with blender scripting and think you may be able to help)
Finally, Iāve been playing with visibility polling to avoid unexpected behaviour (e.g. PC attacking an off-screen NPC). Wonāt be much use in my case because visibility culling isnāt precise enough (I understand that this is meant to help optimising, so I was probably abusing the APIs in this case).
Nice, the character could really need something to āgroundā the character, like a simple blob shadow or similar, seems like she is floating around and hard to tell exactly where she are on the terrain, the low camera angle does not help either. Keep it up, looks interesting so far : )
When the sun angle is low, intensity drops and shadows disappear. This is by design: long shadows on the ground would end up looking pretty bad.
However, having a bit of a shadow under the character is important (visually, but also functionally to define its relation to the ground) So Iām thinking of activating shadow-casting from a vertical source and using a little trickery to mask the transition. Stillā¦ a blob shadow may work better.
Talking about shadows, hereās a little teaser of the next update:
These models arenāt final but already much better (I hope) than the dummies we had before. As usual refining geometry causes small landslides (meaning: design changes).
I am cutting corners as much as possible to quickly move to the next significant improvement. For example, I initially thought that I needed many variations around the original house design but this may not impact quality as much as, say, furbishing said houses. So I make do with only 3 variations.
āAdaptive refinementā is really the way that this project is done so, it would be hard to say whether anything you see here is final. I hope not. Is it wasted work, then? I donāt think so, in the sense that each iteration (visually as much as technically) provides input for the nextā¦ Would be happy to have opinions on this.
Gameplay and usability are lagging behind so we have a topic for the next update.
The walking animation is somewhat not enought natural and smooth , it is final animations or prototyping ?
Red characters should be more alive, their animations are too simplistic
Some particle effects when the character hits the red mobs will do better job
The game looks lot more like some platfomer with ennemies all around, looking at the level i would expect to be able to run, jump , smash ennemies, instead of adventuring.
By adventure i would expect bigger structures, lot more objects and mechanisms to look at and use, and ennemies you must put out using mechanisms and tricks instead.
Perhaps making the game more action game and keeping the adventure part for puzzles and mechanims would be better ?
I suggest you to post a first demo to gather players reactions and decide what direction to keep or change than.
Anyway thatās a big amount of job you already made, a really good job, but i find the game would need really a minimum texturing style and choose better lightening and shadows also.
I really hope weāre moving away from the āMario 64ā visual feel. It brings somewhat incorrect expectations about how the game should play.
Visually thereās a lot of work to do. Mainly adding elements, detailing and, like you mention, texturing but not something very complex as I like to keep a cartoony style. Tuning light and color is a little tricky because I want to keep the day/night cycle which involves calibrating many parameters over and over (thinking of trashing this but I canāt get myself to give up).
And weāre trying to make this work with the free editor.
About the game mechanics, it works more like a platform game but without much of a commitment to the genre.
Early we could see the possibility of adding āpoint and clickā puzzles, especially indoors. However Iām not interested in implementing this in the game - instead I really want to develop gameplay around the AIs that Iām implementing - if you tried the live build you might have noticed that the NPCs basically do whatever they do, but without much impact on the gaming experience. I donāt really know how to bring this into our game, but others have than it well (e.g. Waking Mars) so letās try to create something fresh.
I was trying to improve lighting and visual feel this morning, I found the result interesting:
The new lightening makes the level looking lot more good now.
Bu the animations are bad, i mean the heroine anim is like a statue walking, and the speed walking is faster than anim speed. Also the ennemy has no real cartoon animation.
Keep improving
Today Iāll be talking a little about how I cope with workflow issues.
A problem Iāve been trying to mitigate for a while is how the large size of the main level file is kinda slowing things down because of re-importing over and over as we make changes.
This post is a bit low level but I hope to get some feedback about how other people are doing this.
Here you can see that Iām building a pond on the right. Doing this in the main level file would be a pain as I like to play-test as I go. Anyway, the original situation was:
I resaved the main file, moved everything but the platform I want to modify to hidden layers (using the little script I posted) and linked the house as a group (tutorial), and this is how the work file looks like:
Interestingly, groups are picked up by the FBX exporter. However since the export script gives control over which layers are being exported, this is not a problem (I donāt want to re-import the house every time as I make no changes to that).
As this is a pilot project Iām trying solutions on a case basis. I wouldnāt do this for every platform/area in the game. With a little more scripting it should be possible to eliminate these issues.
This was literally a 10 minutes modelling and animation challenge. Didnāt come out too badly imho but more to the point I got a batch of modelled creatures and nobody handy to rig them so it stays in the queueā¦
Why not simply exporting objects individually ? You import only modified objects this way ?
Why not breaking the platform in many separate parts ? like breaking it in lower parts, higher ones, norths , south , east parts etc ā¦ or simply make modular reusable platforms that is less work and as good results.
Breaking your scene in several parts means you could use LOD and culling for distant parts also.
Of course the scene is broken into several parts (~80 objects). So the problem isnāt there although, weāre not doing this to please the importer, as this would be as pleasant and productive as chunking files to fit them into floppy disks.
I get the idea of selecting and exporting objects one at a time (or a few at a time) and I can see how artists with no scripting skills would resort to this as a means to push slow updates into Unity files. There are two reasons I donāt want to do this manually.
It is slow, and tedious. You need to select the objects you want to update. You need to browse to the folder containing your assets. Then you have to give a meaningful name to the object youāre exporting. Of course doing this once has never been a problem. But, asking why Iām not doing it this way is like asking why every application has a āsaveā option next to āsave asā. And the answer is simple: because nobody even want to press the save button. Even if it doesnāt take much time, it is distracting.
The relationship between the *.blend file and the *.unity file is in the artistās head and nowhere else. I can easily see how this would lead to lost assets, fbx files without blender counterparts. And more generally, a bloody mess.
So Iām happier with setting up a separate file in the way I described, as it allows me to get in a smooth test-modify-retest loop. I find it patchy but not unworkable.
You already suggested using reusable/modular stuff andā¦ I have already replied
Iām going modular when it works for me, and finding patience when it doesnāt.
