Well ever since I started development I knew i wanted to try and implement some form of motion controls since it'd be pretty cool and fit the game play model well. Initially I was literally going to try prototyping with my android/Google Cardboard duo and a PS Move controller for motion controls. I remembered the Vive too and knew I couldn't afford that huge price tag so I figured I'd send Valve an e-mail telling them about my game and the worst that could happen is them not replying or telling

me to go away. So I did and then literally not even 48 hours later they sent me a code for a Vive and I was elated. Long story short I got a dev kit and am working with that now. I think I may order a Leap Motion (they are very cheap actually) and add support for that too (later on, again trying to prevent feature creep).

Long story short ya motion controls (particularly the Vive's and maybe leap motions) are something I'm aiming for at launch.

Ya. To be honest I really was kind of expecting no reply lol. I'm not sure if they liked the idea enough to send me one or if they just decided "who cares?" and sent me one. Either way it was definitely a big confidence booster and has helped tremendously in the development process.

The tricky part has been trying to make it work well as a seated experience. The game was designed from the ground up to be open world. I really would have liked to have made it [mainly] room scale but I feel that it would have butchered what I originally had in mind to squish it down. That and my room is so damn tiny lol.

Look I want to keep the peace and all but what exactly happened with this selfless character? If you don't mind taking about it.

I'm impatient

Before anything even happened this morning, I wanted to talk to @Tyyppi_77 about smart pointers

Your thing was supposed to be a real quick comment, @Sie

Wait Mick is selfless?

@Tyyppi_77 I thought that would be good because then you'd know it's me lol

I guess so

I mean, by definition they only existed in that form as the result of severe conversation problems

Just to be clear, I am well aware of having several personalities. That means it's not the "crazy" kind of multiple personality, just the regular kind lol.

Ok you can probably still just drop std::unique_ptr in most places

I'll assume you already know the basics of smart pointers?

So I'll cut into the meat of C++ specifics: The unique_ptr is basically just a wrapper on a regular pointer

But it has one detail that kindof rubs you the wrong way at first but makes sense after a while

You can't copy it

If you have two unique pointers a = 0; b = new Thing(); and you do a = b;

then you'll have b == 0 after that, and only a keeps the pointer

By obeying this rule, you'll never let more than one class own the pointer

And since only one class ever owns the pointer, the unique_ptr can call delete for you when it falls out of scope

Yeah you use them as value objects

But their value is the pointer

unique_ptr

And yeah that looks right

Yes

I would if I found one that wasn't sketchy :/

Everyone just says "USE SHARED_PTR EVERYWHERE UR WELCOME"

You cannot pass a unique_ptr as lvalue iirc

as this would copy

You're being one of those C++ guys

We're not trying to read the standard word for word, we're trying to develop an understanding, so that reading the manual will actually be a useful exercise.

People misinterpret the manual when they don't already have some level of understanding.

@Tyyppi_77 So if you're calling a function, 99% of the time you'll just pass a direct reference

The unique_ptr and shared_ptr only really need to show up in class members in normal cases

Yeah, or even by value if it's smalle

Basically when you're in a class method, and the class owns the pointer, you can use the pointer "directly"

It's only when ownership can transfer, that you should use the smart pointer

Now with that premise: Use shared_ptr everywhere. You're welcome.

jkjk

@Tyyppi_77 If you are passing "down" then you can use the raw pointer, if you are passing "up" then you use the smart pointer

Basically imagine that as long as you have the smart pointer, the pointer works

Imagine this: you have a smart pointer in scope, and you call a function inside that scope, the function returns and the smart pointer still exists.

The smart pointer still existing means the pointer is still good. You could just pass the raw pointer

You can retrieve the raw pointer easily, yes

foo(bar.get())

Think from the called function's point of view: That pointer is constant from the first line to the last

No need for memory management

=> No need for smart pointer

You'll have to give me an example of what your factory idiom looks like

Or I could give a simple example

Ok this is just a detail:

You technically can use unique_ptr<> there, because you can combine it with std::move wherever you call the function

auto ent = std::move(createEntity(...));

But probably not the best idea lol

Only because I'm assuming your entities get their pointers copied all over the place

So this is the job for shared_ptr and weak_ptr

In short, shared_ptr<> adds a reference counter

So you can wrap your pointer in a shared_ptr and make as many copies as you want, they all increase the Ref count. When they are all deleted whoever take the Ref count to zero deletes it

Ok peace!

wtf

No

This is not the job for shared_ptr

@NaCl Come on now, lets hear your proposal...

unique_ptr

XKCD never ceases to be relevant.

@NaCl Please explain what was missed above when we discussed unique_ptr vs shared_ptr directly?

I'm refering to factoryMethods

That's not specific enough to decide yet.

Really, please share your specific insight here

<bursts in> Got a flag on that XKCD, are such things not cool here?

There is no need for std::move

We love XKCD here lol

Heh, OK, looks like someone already cleared the flag :)

<vanishes>

cpp.sh/75bt

@BenN It is pretty spammy use of it though, and by a user who caused trouble earlier lol

@NaCl Still using move

not explicitly as you implied

Uh... but still technically, which was the problem earlier

unique_ptr is appropriate for a single-onwer situation

This is a single owner situation

oops

I think his style will fit with a mixture of shared_ptr and weak_ptr best

Because there are several incompletely coordinated systems which might want to keep the entity data alive for a few moments even after the original gameplay code is done with it

And also there are systems that would like to monitor the entity as long as it exists, but don't care to keep it alive if someone else deletes it

I've been wondering for a while, @NaCl, is this your real face?

...yes

yes it is

:D

Hello internet

I think since putting up cognizer on my website (much through the testing) I've burned half a gig of download.

it's not limited by the host, provided it's in service to a website.

I just hope they live up to that claim.

I even asked directly about hosting a webgame, they said it was acceptable use.

are you sure they understood "webgame" correctly?

I'm pretty sure

I asked "If I host my game on my website, and it gets popular and takes a done of download, am I abusing the service?"

they said "no, that's acceptable."

@Tyyppi_77 I'd use a std::unique_ptr and an std::experimental::observer_ptr/raw pointer for this purpose. You rarely ever really need std::shared_ptr. An example I somehow think of first, where it really is needed together with std::enable_shared_from_this, would be a scene graph.

See also stackoverflow.com/questions/8706192/…

@NaCl You rarely ever really need more than some transistors and a soldering iron...

That is a huge exeggeration

So is yours.

That's the point.

No, it's not. How is it an exeggeration? It's proper use. Don't forget the additional overhead shared_ptr's add

Opinion. Drop that entire train of thought

Entity A references some data from Entity B, but Entity A does not keep Entity B alive... What happens?

Entity B's unique_ptr falls out of scope when Entity B is deleted, and now Entity A's reference goes null

Sure, no crash, but now you have an Entity A with corrupt internal state

The additional overhead argument, imo, is the only valid one.

You say corrupt, I say exception. It just depends on the importance of the data

Exactly, it depends on the data.

Meaning that there is some set of data that causes it to be important.

And especially on the code-design itself

Which means a program that handles general data, must handle that case to be correct

The fucked up part is I agree with you, @NaCl lol

Why is that fucked up?

ahhh data: the power of reconciling everyone

@NaCl Because I'm having to make an argument that contradicts my own preference

I guess the only fucked up thing is that I, mostly, don't need shared_ptr's to ensure correctness

In comparison to your preference

But in @Tyyppi_77's case, I think he might end up having a really annoying refactor to separate all the Entities from the data they might share

Like bad enough that he might just put it off until his version 2 when he was gonna do networking, since that also will require a re-write of half of the way things work

I wouldn't refactor anything, really

It works, it's almost done, it's ok

That's why I bring up shared_ptr

Even though using unique_ptr is possible, I'm not sure it's trivial to add on

I don't see how that would mean less overhead

Because he wouldn't have to separate objects from the data they share

But it's centralized anyways, isn't it?

Which thing?

"I do have a single vector that mainly manages the ownership"

(dunno how to make quotes, lol)

Have you ever written a game?

That's what @Tyyppi_77 said

Ah

Hint: Things do stuff with other things. You're not gonna get away with packing all the entities into a corner and not letting anything else touch them.

I know. You're insulting my intelligence now

Do you think I couldn't remember his quote 2 seconds ago?

That was just a test of that permalink thing

Don't get mad

I'm not. Don't project

I don't

Lets get to the point and stay on it until it's done please?

> Entity A references some data from Entity B, but Entity A does not keep Entity B alive... Entity B's unique_ptr falls out of scope when Entity B is deleted from the main list, and now Entity A's reference goes null. Now you have an Entity A with corrupt internal state.

Make this not true.

Oh, it's objectively true. Ok good talk.

I already replied to it

I rejected your opinion.

Make it not true. Oh it's objectively true? Cool. Someone's at the door

You can't reject my opinion. You can only keep your own's and say mine is shit

Cool opinion. I reject that.

can we please stop bickering in here

<3

@Tyyppi_77 Do you really think it's worth it now?

If so: Don't forget about std::make_unique :)

@NaCl Using std::unique_ptr is most of the time worth it more than using raw pointers. You might have memory leaks without you knowing about it! (Unless you really know what you're doing.) There is no overhead to unique ptrs, so why not!

Yes, I agree with you.

I really need to try and do something... I've hardly put any work at all in to my game this week...

Been feeling a bit crummy, and I also discovered codefights.com/signup/EqrAqFej7Dtgv6rRf/main

That site is dangerous to a programmer like myself...

But I have learned a lot in the process!

So when I release my little demo (for play testing purposes) on my site do you think people would mind filling out a quick 5 question poll (like on the right or left hand side of the game window that will be embedded)?

@PearsonArtPhoto That looks like a refereal :P

@Sie can't hurt to put it if they're allowed to ignore it

It's more like a way to link up with people if they join the site, so I have people to compete with.

@sie I'd fill it out if I enjoy your game and feel the need to tell you something you could do better or some bug I encountered

I'm thinking about implementing a opt-in replay function too. That way I can kind of see what the player does or where they may be getting stuck.

This is going to sound stupid but I just worry you guys won't like it. I mean I know that failure is a part of the process (at some points) but still.

Well

Don't know about other ppl

@Sie totally don't worry about that

:)

but I actually want to tell developers how i think

especially for indie games

If i enjoy them, I want them to be even better, of course

@PearsonArtPhoto It's very similar to codingame.com

But it looks more competitive

Doesn't surprise me there's other like it.

Yeah, it's pretty competitive.

@tkausl Well of course. You need honest feedback and a hug box will solve nothing if anything it could make things worse.

I won a code golf recent:-)

I've never had interest in the Code Golf site, but I've found that it can be fun.

whats a hug box?

@tkausl urbandictionary.com/define.php?term=hugbox

no that

@Almo these are... not great

Persona 5, apparently

where the tweet is from

Well I guess its the same thing as with the crash reports

most people will click "cancel" or whatever

but some who actually care will send the crash-report (or feedback, or whatever)

Well I just broke something major as everything is going crazy. Glad I had the sense to setup a repo and back this crap up prior to this.

To do truly curvy graphics as I would like would take a lot of work...

For my pathfinding, to do something curvy I'd need to have information about the previous, current, and next tiles.

Putting that all together seems complex.

So, I guess it's time to learn how to do Splines in Unity.

@GnomeSlice the dirt menus are some of the best I've seen

you can navigate them while they are animating

very, very smooth user experience

I knew a guy who worked there, he said it was some weirdly large number of programmers and artists working on it for months

@Almo Did you ever get my animation I sent you and Jon?