Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411576 Posts in 69386 Topics- by 58444 Members - Latest Member: darkcitien

May 05, 2024, 03:16:34 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsCommunityDevLogsManifold Garden
Pages: 1 ... 25 26 [27] 28 29 ... 63
Print
Author Topic: Manifold Garden  (Read 395371 times)
Connor
Level 8
***


Smooth talker, musician. Loves all things 70s.


View Profile WWW
« Reply #520 on: January 14, 2015, 10:20:03 AM »

congrats! seriously, you deserve it, with the work you put in. nice work ^^
Logged

Firearrow games
www.firearrowgames.net

blitzkampfer:
https://forums.tigsource.com/index.php?topic=52009.msg1280646#msg1280646

too bad eggybooms ents are actually men in paper mache suits and they NEED to be agile
Sjonsson
Level 0
***


Multi-hatter. Level design get's the love.


View Profile WWW
« Reply #521 on: January 14, 2015, 10:37:03 AM »

Whoop whoop! Look who's going places! :D
Logged

Unity-chan is that ex that you'll never get over but on the same time will always regret.
oleomingus
Level 1
*


Oleomingus


View Profile WWW
« Reply #522 on: January 14, 2015, 12:49:03 PM »

Congratulations on the Unity Showcase! The art is certainly splendid.
Oh ! and the psychedelically-geometric-daily-loops look amazing.
Logged

 
Torchkas
Level 10
*****


collects sawdust


View Profile WWW
« Reply #523 on: January 14, 2015, 04:03:04 PM »

This better have a cynical villain with a charismatic voice.
Nice stuff. Artstyle is definitely memorable.
Logged

William Chyr
Level 8
***



View Profile WWW
« Reply #524 on: January 14, 2015, 08:13:15 PM »

This better have a cynical villain with a charismatic voice.

Unfortunately, you won't find any of that in RELATIVITY. Portal already did it, so why repeat that?  Wink
Logged

William Chyr
Level 8
***



View Profile WWW
« Reply #525 on: January 15, 2015, 10:39:26 AM »

Devlog Update #147 - 01/15/2015

RELATIVITY is on WIRED!

A Mind-Bending Game Being Designed in the Open

« Last Edit: January 18, 2015, 02:45:37 PM by Willy Chyr » Logged

William Chyr
Level 8
***



View Profile WWW
« Reply #526 on: January 18, 2015, 01:14:48 PM »

Devlog Update #148 - 01/18/2015

Group Critique Session Post-Mortem



Yesterday I participated in a group critique session with several other Chicago-based game designers. It was incredibly helpful and something I haven't really seen done before (at least not in the same format). Here's a write-up about the experience.

Inspiration

Several months ago, I read about The Depth Jam, a four-day intensive design retreat organized by Jonathan Blow, Chris Hecker, Marc ten Bosch, and Daniel Benmergui. Reading about that experience made me realize that while there are plenty of game jams to get beginners to make games, there is a lack of events for more experienced game designers.

Around that time, I had also attended PRACTICE, a two-day game design conference organized by NYU. Returning to Chicago afterwards, I wanted to create a format where in-depth discussions about games could happen. Chicago has a fantastic indie game scene, and throughout development, I have organized several one-on-one playtest sessions with other designers, and had been able to have very deep discussions about my game. However, I think there’s a tremendous amount of benefit to participating in a group with a more structured format.

I decided to organize an event that would fit this niche. I was originally calling it a mini-depth jam, but after we did it, we realized it was really more appropriate to call it a group critique session, since we weren’t actually jamming.

Participants / Projects

While I would have liked to open the event the everyone, due to the nature of something like this, it has to be a small group. Originally, we were planning on having 6 teams with 6 games to discuss, but due to timing and other circumstances, only 4 teams participated. In the end, I think this actually turned out well, because a full day of critiques is pretty exhausting (we were there from 10 AM to 4 PM), and 4 games seems to be just the right number.

To respect the other team’s privacy, I will not be talking about their projects or problems in detail, just listing the rough nature of it.

There were the participants:



My problems were concerned mostly with the design of ‘World 2’. Here are a few examples of the questions I presented:

1. Players can solve one of the major puzzles without realizing what they’ve done. Should it only be “playable” when players can see it, or can it be affected regardless of player’s location and visibility? What if player is in another world entirely? Should the mechanics still be consistent?

2. What are the “concepts” that you feel are being taught in the puzzles. Are the puzzles “clean” or do they feel muddled? By clean I mean that the idea that the puzzle is communicating is very clear and simple.

3. How does the world and level pattern compare to that of “world 1”. Does it get repetitive and feel like a checklist? Is this a positive or a negative thing?


Sean and my projects were probably closest in terms where we are in development. Both of us have been working on our respective games for quite some time, so the issues we were facing were quite deeply embedded within the project.

Benedict and Greg’s, as well as the Young Horses’ projects were both very early prototypes, so the nature of the problem was very different.

Preparation
About a week before, an email reminder was sent out to everyone to get a build of the game ready. Then on Wednesday, 3 days before the critique session, we all sent out builds of our games to one another.

Location



For the critique session, the Young Horses were very kind to allow us to use their office, which was pretty much the perfect setting for this event.  There is an area that has couches and a large screen TV. Whoever was presenting could use the TV to demo the game to show reference materials.

Format

The day started at 10:30 AM, and consisted of four sessions, each between 45 minutes to 1 hour.

Each session focused on one game, and would begin with the designer providing some context for the problem. This would usually consist of the designer playing through the game, and people would talk about the places where they got stuck or had issues.

After that, we would talk about larger design issues and problems, and try to work through them together as a group.

The playthrough at the beginning was in large part because this is the first session, so we all still needed to get familiar with the games and the issues at hand. I imagine for future critique sessions, we could probably jump straight into the problem since we will all have context.  

I went first, followed by Benedict and Greg, then Sean.

At 1 PM, we decided to take a break and go to lunch. During lunch, we talked about what were things we liked about the format, what things we could improve, and how this can be expanded to include more people.



After lunch, we returned for the fourth session, with the prototypes from the Young Horses.

We finished around 4 PM.

I think this was pretty much the right amount of people and the right amount of time. By the end of it, we were all pretty exhausted.

Conclusion

We all decided that the group critique session was very helpful and something that we’d like to continue doing on a regular basis.

Here are a few issues and tips to keep in mind:

1. Game Stage – Where a game is at (early prototype vs halfway in development) has a big impact on the nature of the discussion. A bigger game that’s more developed obviously has more to discuss and has deeper problems, but it also takes longer to provide context and explain the problem clearly. On the other hand, for early prototypes, it’s easy to get a sense of the problem and its context, but the discussion tends to be more speculative and more like a brainstorm. Lots of “what if” questions, but maybe not as much concrete solutions. One way to address this is to have different session lengths – not every project needs the same fixed amount of time or attention.  

2. Have good debug tools – this is more of a general game development tip, but is incredibly helpful in a group critique session. You want to have debug tools that can allow you to skip sections and make changes very quickly when presenting the game. For example, my game doesn’t have any debug settings (I’m working on it), and during the presentation, there was a bug and the character controller got stuck in an area with no way out. To get to the problem, I would have needed to quit and replay the entire section again. I ended up communicating the problem using pen and paper. Sean, on the hand, had a set of fantastic debug tools for Even the Ocean, and was able to make changes and adjustments on the fly when showing the game, skipping to different sections. This was incredibly helpful, and I’d recommend all games adopt this.

3. When sending out builds beforehand, tell others what feedback you’re looking for, and how long they should spend on the game – work-in-progress games always have bugs and areas that are poorly designed where players can get stuck. Let others know what some of these issues are beforehand, and particular areas they should be paying more attention towards.

Future

We are planning to do this again on a regular basis, meeting once every two to three months.

For something like this to work well, the group has to be quite small. For the next meeting, we wouldn’t need to provide context for our problems, and can dive straight into the issues. If someone new is introduced, then we would have to catch them up on the issues we’re facing.

I'd love to get more people involved in critique groups like this, but I'm not sure how to address that. We were thinking what would be great is to have multiple critique groups in the city, and hopefully the information here can help people start their own.

If you've done something like this before, or have any suggestions and questions, let me know!
« Last Edit: January 18, 2015, 02:44:55 PM by Willy Chyr » Logged

ofx360
Level 0
**


View Profile
« Reply #527 on: January 18, 2015, 04:16:12 PM »

Thanks for the write up! I would love to know what you're problems were and what ideas you and the team came up with to overcome it.
Logged
William Chyr
Level 8
***



View Profile WWW
« Reply #528 on: January 19, 2015, 08:24:53 PM »

Devlog Update #149 - 01/19/2015

Thanks for the write up! I would love to know what you're problems were and what ideas you and the team came up with to overcome it.

It's a little hard to explain the exact problem without going into a lot of details that would likely spoil the game. In the previous post, I included a few of the questions I presented to the group so you can get a nature of the discussion.

A lot of it was fine tuning individual puzzles. For example, some of the puzzles had methods in which you could brute-force your way to the solution, which is not something I want at all. We were able to come up with a solution for that. I was also trying to work out the thematic thread between puzzles, whether or not it was communicated well.

There were a lot of high level discussions, with people giving examples of games that did similar things which worked well, and which didn't.

UNITY 5

I have made the switch to Unity 5. Wow! I'm not going to lie, I'm pretty terrified.

I'm going to talk about why I made the switch.

Current Tech Problems I'm Dealing with

1. Player movement feels extremely clunky

2. After jumping to a wall, player will sometimes get stuck halfway in the floor before being snapped back up again, causing a very abrupt and disruptive feel

3. Sometimes player falls through walls/floors.

4. Cubes fall at a different speed than the player, meaning that the player cannot fall while carrying objects, which makes it impossible to solve some of the puzzles.

5. Sometimes triggers will think a cube has moved away

6. The teleportation system that makes the repeated world mechanic possible sometimes screws up and sends player elsewhere than intended

7. You can carry an object while being teleported.


As you can see, a lot of the problems I'm dealing with are due to all the game systems not working together. The way this happened is that for a long time, I didn't know what the game was going to be. The project is still just one giant prototype. When I wrote the movement code and the object carrying code, I didn't have the repeated world mechanic in mind. I also wasn't expecting players to go outside.

So as the scope of the game has expanded, and as the number of systems have increased, I've just been adding more and more edge cases to my code controlling movement.

All of these are the basics of the system.

But to go back now and fix things is a huge pain. So many things are interconnected that I fix one thing and break three others, and I can't run the game in the meantime.

To be honest, it's much easier for me to start a fresh project with a small clean world, and get the systems working right then.

So to rewrite, I really only have two options: Unity 4.3 or Unity 5. This is because these are the only two that support console porting at the moment.

Given how long I have left to work on the game, it makes more sense to go to 5. Also, a lot of the game depends on quick instantiation and shorter load times, which 5 is much better at.

So yeah, that's my reason for going to 5.

Day 1 with Unity 5

So far, it hasn't been too bad. There are changes to the API, and definitely some bugs, but all in all, it's working quite well.

ProBuilder works on it, which is great.

Cursor lock state seems to have some problems, which is a bit annoying.

Anyway, just getting started with the smaller project. I'm going it RELATIVITY REDUX for now.

I also finally figured out the unequal terminal velocity issue.

More updates in the coming days.
Logged

Lo-Fi
Level 1
*



View Profile
« Reply #529 on: January 19, 2015, 08:29:00 PM »

Wait, you can't port to consoles with Unity 4.6? Damn, I wish they had made a bigger deal out of that, I had no clue. Wasn't planning on updating to Unity 5 anytime soon.
Logged

William Chyr
Level 8
***



View Profile WWW
« Reply #530 on: January 19, 2015, 08:45:53 PM »

Wait, you can't port to consoles with Unity 4.6? Damn, I wish they had made a bigger deal out of that, I had no clue. Wasn't planning on updating to Unity 5 anytime soon.

Maybe it's in the plans? I don't know because they haven't announced anything.

When I was at PlayStation Experience, I asked a bunch of the other developers who were also using Unity to port to console, and everybody said it was either 4.3 or 5.

I remember getting pretty major performance boosts when I upgraded to 4.5, so going down wouldn't really work for me.
Logged

William Chyr
Level 8
***



View Profile WWW
« Reply #531 on: January 21, 2015, 05:23:20 PM »

Devlog Update #150 - 01/21/2015

Unity 5

Continuing to work with Unity 5. All in all, I think a lot of the changes that have been made are for better programming reasons.

However, it does take a bit of getting used to if coming from Unity 4.

For example, if you want to access canvas elements (the new UI system), you'll need to use the namespace:

UnityEngine.UI

at the top of your script.

Game Feel



Continuing to work on game feel. I'm now rewriting the carrying object system and the box system.

Terminal velocity of boxes falling is now equal to terminal velocity of player falling, so that's good.

Once that is done, players should be able to carry boxes while falling, which is a pretty important mechanic.

Motivation

I have to admit, I'm having a pretty hard time finding motivation to do this stuff. I think it's because I already did this about 2 years ago, and I have to read through a lot of old code in doing this. I've also gotten so used to working on designs at such a high level that's it's kind of annoying to have to come back and deal with basic physics and UI issues.

But such is the game dev life.
Logged

Mark Mayers
Level 10
*****



View Profile WWW
« Reply #532 on: January 22, 2015, 12:43:10 PM »

Overall, do you think the switch to Unity 5 is worth it for right now?
I'm pretty happy running 4.6 for a while until there is a truly stable release.

My game is much earlier in development than RELATIVITY, so making the switch now *could* be rather painless.
Logged

Desolus Twitter: @DesolusDev Website: http://www.desolus.com DevLog: On TIG!
William Chyr
Level 8
***



View Profile WWW
« Reply #533 on: January 22, 2015, 08:48:39 PM »

Overall, do you think the switch to Unity 5 is worth it for right now?
I'm pretty happy running 4.6 for a while until there is a truly stable release.

My game is much earlier in development than RELATIVITY, so making the switch now *could* be rather painless.

It really depends on the specifics of your situation. Are you planning on releasing on console? If so, when?

If you're in a super early stage of development, I might wait until 5 is stable.

Plugins? Timeline? Etc. 
Logged

Zaphos
Level 5
*****



View Profile WWW
« Reply #534 on: January 23, 2015, 11:06:41 AM »

How unstable is 5?  Have you run into a lot of weird issues with it so far?
Logged

How to Be a Tree | Voro | Realistic Kissing Simulator | twitter | Programmer at Epic Games
William Chyr
Level 8
***



View Profile WWW
« Reply #535 on: January 23, 2015, 04:15:14 PM »

How unstable is 5?  Have you run into a lot of weird issues with it so far?

I can't really say at the moment. I haven't run into too many weird issues yet, but again, I haven't been working with it for that long.

There are a few minor things, like cursor locking that aren't working properly at the moment, which are a bit annoying in that you'd have to write some workaround that you know won't be necessary later.

I haven't output a build to different platforms yet, which I imagine might be where a lot of issues are hidden right now.
Logged

William Chyr
Level 8
***



View Profile WWW
« Reply #536 on: January 23, 2015, 06:50:07 PM »

Devlog Update #151 - 01/23/2015

Game Feel Improvement - Object Carrying

Object carrying is one aspect of the game that has had some problems for a while. I decided it was finally time to sit down and sort it out.

SPRING METHOD

The object carrying script I've been using up until now was written about two years ago when I first started working on the project. I'm calling it the spring method because it uses a spring.

The gist of it is that when you find a box to pick up, i create a spring between the player and the box.

The values I use for the different spring properties are:

strength: 100
dampen: 5

I also set these properties on the rigidbody of the box:

drag: 15
angular drag: 15

(These values aren't actually that important. Putting it here more for myself to remember, should it be necessary in the future).

PROS
There are several things that I really like about the spring method.

1) It feels great



The feel when carrying the box is really nice. There's a slight delay between the movement of the box and when you move the camera or the player. While carrying a box, if you move backwards, its distance to you gets stretched a little longer, and when you move forward, the distance gets smaller. There's also a slight bounce at the end of a movement before it settles in its position. It's very tactile and really nice.

To be honest, I haven't seen object carrying done quite like this in other games before.

2) "Natural Physics" effects



You also get really nice "natural physics" effects, like when a box catches on a wall, it'll get hold up a bit and the distance will stretch, before it bounces back to the player. When you push a box against wall, it'll have a slight bounce back as well.

3) You can place the box on a ledge very easily



Placing objects on ledges above you is a really important game mechanic. With the spring method, it feels like a very natural, and is easy to do.

CONS

1) You can't fall while carrying an object



Part of the problem here is that the acceleration of the box is different than that of the player, but the spring is still a significant problem. At the values I've set it at to make it feel good, the box gets too far away from the player to feel right.

Even if I get the terminal velocity correct, there still is this weird freakish effect that happens when falling:



2) Unpredictable Freakout



Sometimes this happens. This is what happens when drag is 0. The drag on the box is not 0, but I've seen it happen every now and then when you're walking around with the box. It's a really hard bug to replicate so I haven't been able to debug it.

SINGLE RAYCAST METHOD

After playing around with different values of spring strength and drag, I decided to get rid of spring and physics altogether.

Instead, I just have the renderer of the box (let's call it the Phantom Box), with no collider or rigidbody on it, and have it parented to the player.

The position of the Phantom Box is set using raycast.

I had a single raycast coming from the center of the camera straight out a certain distance (what the length of the spring would have been). If the raycast hit a wall, it would get the point it hit the wall at, as well as the surface normal of that wall, and then position the Phantom Box 0.5 units away from the wall, so that it was aligned right up against it.

If felt pretty good, except sometimes the box would go into an adjacent wall:



You can get a better view in this image below:


The issue is that the raycast is only looking at the wall in front, but we have no idea that the wall on side exists, so the box is being drawn into that side wall.

This is no good.

CENTER RAYCAST METHOD

I'm calling this method center raycast method because it uses 6 raycasts, one coming out of each face of the cube, from the center:



Basically, what I do is I send a single raycast forward. I use the end of that raycast (whether it hits a wall or not), as a point from which to draw 6 raycasts (I call these secondary center raycasts).

I use the secondary center raycasts to detect walls and figure out location of cube.

At first it seems movement is good:


I can place the box on a ledge:


BUT, if it's in the corner, the box can go into the wall:


Since the rays are coming from the center of each face, none of the rays are detecting that adjacent wall, hence the box is drawn over the wall.

No good.

SPHERECAST METHOD

I tried using a SphereCast next. According to the Unity docs, it's sort of like a "thick raycast"

I was putting the sphereCast sphere inside the box, like this:



At first, it seemed to work quite well. The box was no longer going into the wall:



However, I then found a major problem: it's almost impossible to get the box on top of a ledge:



I believe this is because of the size of the sphere, it isn't able to spherecast over the lip of the ledge. Well, this isn't going to work then.

Also, while we're being nitpicky, it does dig into the wall a little bit (because of the curvature of the sphere at the edges of the box):



CORNER RAYCAST METHOD

This should probably be called Center + Corner RayCast method. It's like the center raycast method, but I also raycast from each corner.

So each face actually does 5 raycasts.

So along with the single raycast shot at the beginning to determine where to place the secondary raycasts, I have 31 raycasts:



Here's a sketch showing the different raycasts from the different faces a little better:



It works really well!



The box doesn't go into the wall at any point, and it's also easy to place the box above a ledge!

Oh, and check out what it looks like when you fall while carrying a box this way:



Aw yiss

FEEDBACK

Now that I've laid out my problem with carrying objects, what do you guys think of this the corner raycast solution? Is there a more efficient or better way I could have done it?

If it isn't too expensive performance-wise, I'll probably just leave it for now. It doesn't feel *as good* as the spring method, but it doesn't have any of the game-breakig bugs that the spring method had. It's also way more reliable.
« Last Edit: January 23, 2015, 07:01:00 PM by Willy Chyr » Logged

Zaphos
Level 5
*****



View Profile WWW
« Reply #537 on: January 23, 2015, 07:05:48 PM »

I think you could do corner raycast + some minor tweaking to give it that nice springy feel ...

For example sometimes if I want just a little bit of easing, instead of directly setting position I set the position to "actualPos = lastPos*lagParam + targetPos*(1-lagParam)" where lagParam is a value greater than 0 and less than 1 ... (this assumes you have a fixed update rate, for delta time this needs to be done differently)
Logged

How to Be a Tree | Voro | Realistic Kissing Simulator | twitter | Programmer at Epic Games
tysonibele
Level 0
***


View Profile
« Reply #538 on: January 24, 2015, 09:10:03 AM »

Quote
For example sometimes if I want just a little bit of easing, instead of directly setting position I set the position to "actualPos = lastPos*lagParam + targetPos*(1-lagParam)" where lagParam is a value greater than 0 and less than 1 ... (this assumes you have a fixed update rate, for delta time this needs to be done differently)

That's called a linear interpolation (lerp) Smiley

If I'm not mistaken, OP is using Unity? Unity has builtin lerp functions (Vector3.Lerp) that make the code a little more tidy.
Logged

Zaphos
Level 5
*****



View Profile WWW
« Reply #539 on: January 24, 2015, 10:00:41 AM »

Ah yeah, in Unity it should just be "actualPos = Vector3.Lerp(targetPos,lastPos,lagParam)" Smiley
Logged

How to Be a Tree | Voro | Realistic Kissing Simulator | twitter | Programmer at Epic Games
Pages: 1 ... 25 26 [27] 28 29 ... 63
Print
Jump to:  

Theme orange-lt created by panic