Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411279 Posts in 69323 Topics- by 58380 Members - Latest Member: bob1029

March 28, 2024, 03:44:14 PM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsDeveloperTechnical (Moderator: ThemsAllTook)The grumpy old programmer room
Pages: 1 ... 233 234 [235] 236 237 ... 295
Print
Author Topic: The grumpy old programmer room  (Read 733314 times)
Boreal
Level 6
*


Reinventing the wheel


View Profile
« Reply #4680 on: December 08, 2014, 06:08:08 PM »

Considering Dijkstra is just A* with a heuristic of zero, I wouldn't say it's any easier to implement.

I'd only consider using Dijkstra for something like a TBS where you need to show the tiles a unit is able to move to.
Logged

"In software, the only numbers of significance are 0, 1, and N." - Josh Barczak

magma - Reconstructed Mantle API
indie11
Level 2
**


View Profile
« Reply #4681 on: December 08, 2014, 08:51:23 PM »

Pretty simple eh!? So which Algorithm should I go with? A* or Dijkstra, keeping in mind that the Node isWalkable state is changeable at Runtime.

It doesn't really matter. They will both give you exactly the same result (i.e. the optimal path). The only difference is:
  • Dijkstra's is easier to understand and implement
  • A* runs much faster (requires less computing power)

If you don't need the optimal path, you can make A* run faster by modifying a constant in the heuristic.

     
Dijkstra's
     
A*
   
A* (suboptimal path)

For grids you can also use jps, which is even faster:
http://forums.tigsource.com/index.php?topic=34071.msg901817#msg901817

The game is 3Disometric grid based and it will have on average 100 nodes and at max 250 nodes that too in larger levels.
It will also have stairs and ladders but I think that doesn't matters for a path finding algorithm?
Thanks for the link, i'll read it in a bit.

Considering Dijkstra is just A* with a heuristic of zero, I wouldn't say it's any easier to implement.

I'd only consider using Dijkstra for something like a TBS where you need to show the tiles a unit is able to move to.

as I said above, the game is grid/tile based so Dijkstra will work well too?

I just don't want expensive runtime computations that's all
Logged

Sik
Level 10
*****


View Profile WWW
« Reply #4682 on: December 08, 2014, 09:25:40 PM »

Considering Dijkstra is just A* with a heuristic of zero, I wouldn't say it's any easier to implement.

I'd only consider using Dijkstra for something like a TBS where you need to show the tiles a unit is able to move to.

Or if you're computing for many entities.
Logged
Dacke
Level 10
*****



View Profile
« Reply #4683 on: December 09, 2014, 08:09:50 AM »

Dijkstra's can be treated as a special case of A*, sure. But it's definitely easier to just implement Dijkstra's, rather than implement A* and set the heuristic to 0. Just like it's generally easier to understand and implement special cases, rather than general cases.

But if you're using it for a proper game, you might as well do A* right away since it's so much better.

indie11, I get the feeling that you're not familiar with how pathfinding works. I'd recommend that you start a new thread where you describe what you are trying to do and what you need help with. But it really doesn't matter what your grid looks like, Dijkstra's and A* work for pretty much any grid or graph.
Logged

programming • free software
animal liberation • veganism
anarcho-communism • intersectionality • feminism
Geti
Level 10
*****



View Profile WWW
« Reply #4684 on: December 10, 2014, 10:22:29 PM »

Debugging some engine<->box2d issues with moving stuff out of the map if it gets jammed through walls and the like. Every time I touch this part of crimson I dislike box2d more and wish we'd gone with simple home-rolled physics that were more tolerant to things changing on-the fly, with fewer things to update and copy around. The fact that the implementation sucks doesn't help either.
Logged

ThemsAllTook
Administrator
Level 10
******



View Profile WWW
« Reply #4685 on: December 12, 2014, 09:39:29 AM »

At my job, we've switched from svn to git for version control. Every moment attempting to do something in git is pure pain. All of the documentation and culture surrounding it is either preachy and condescending or impenetrably complex. This must be what it feels like to be an old person trying to use new technology.
Logged

InfiniteStateMachine
Level 10
*****



View Profile
« Reply #4686 on: December 12, 2014, 10:32:41 AM »

heh, yeah I think it's the weird fanboyism that makes git unattractive to me. I tend to use Mercurial personally and it's pretty much exactly the same thing as git, only it's not as cool.

Perforce is still my favorite versioning system by a country mile though.
Logged

Sik
Level 10
*****


View Profile WWW
« Reply #4687 on: December 12, 2014, 10:45:31 AM »

For the record, I know somebody who once told me that they stick to SVN because they find both Git and Mercurial to be nearly unusable in comparison as soon as the project scales up in size (in terms of developers involved). Not sure how true is this given I only used Git and only basic stuff, but leaving this here.
Logged
InfiniteStateMachine
Level 10
*****



View Profile
« Reply #4688 on: December 12, 2014, 01:29:47 PM »

I can imagine as a project scales with developers it could become a bit of nightmare. That's the point where you need a dedicated guy to comb through all the pull requests.

That's kind of an issue with all open source projects that allow public pulls though.
Logged

Geti
Level 10
*****



View Profile WWW
« Reply #4689 on: December 13, 2014, 02:15:22 AM »

Honestly moving from SVN to mercurial was one of the nicest things we've done, but that was probably partly due to the fact that the move was spurred by a head crash on the machine holding all the svn history eating all of our version history and the idea of a distributed system quickly becoming very attractive. We chose hg because its verb naming is closer to svn's.
I kinda like the staging stuff git has got going on but like hg more overall.
Logged

Boreal
Level 6
*


Reinventing the wheel


View Profile
« Reply #4690 on: December 13, 2014, 08:16:25 PM »

The nice thing about Git is that it's lightweight and (in my opinion) very efficient in terms of workflow.  Of course, I've only ever used it by myself so I can't comment on how it might work with multiple developers.

I suppose the drawback of being distributed is that you really need a dedicated maintainer on larger teams.
Logged

"In software, the only numbers of significance are 0, 1, and N." - Josh Barczak

magma - Reconstructed Mantle API
Sik
Level 10
*****


View Profile WWW
« Reply #4691 on: December 13, 2014, 10:01:48 PM »

You're going to need a dedicated person for large teams anyway just to organize everything, regardless of what system you use.

The only time I used it with multiple people we had the trouble that we couldn't make our changes not clash for some reason (even if we didn't touch the same times) so huh, it looks like we didn't figure out how to use Git properly there (luckily most of the time there was only a single person touching the code anyway). Does anybody know how Git expects to be used when there are multiple people working on the code at the same time?
Logged
Eigen
Level 10
*****


Brobdingnagian ding dong


View Profile WWW
« Reply #4692 on: December 14, 2014, 02:38:37 AM »

Mercurial handles merges and conflicts far better, you should try that.
Logged

BorisTheBrave
Level 10
*****


View Profile WWW
« Reply #4693 on: December 14, 2014, 02:39:41 AM »

Does anybody know how Git expects to be used when there are multiple people working on the code at the same time?
It's perfectly fine with this? Are you coming from svn? In git, you must commit your local changes before attempting to merge them into trunk. Assuming all your changes are commited locally, "git pull" or "git pull --rebase" will do what you want.
Logged
Geti
Level 10
*****



View Profile WWW
« Reply #4694 on: December 14, 2014, 02:48:21 AM »

Speaking from mainly-hg experience (still distributed but might not map 1->1)

Touching the same part of the same code at the same time will (almost) always lead to merge conflicts, and you're either going to need to meticulously merge things each time, or communicate better to avoid that happening. Working on different parts of the same file (or different files) will work (unless git freaks out more than hg about that sort of thing), as long as you aren't making mutually incompatible changes.

Developers have to form habits: pull, merge and push often (in that order) to avoid code getting too out of sync. Our revision tree generally looks more like a chain than a tree or path when two or more people are working concurrently.


On the left you can see "nice" collaboration between two people. Each commit is generally much less than an hour apart.
On the right you can see as-yet-unresolved collaboration on a few branches. I've cheated and included the release head to make it wider, but when 3 devs are working and pushing test builds at the same time this isn't an uncommon situation Smiley

How to deal with a merge conflict - communicate! Every time someone tries to deal with a merge conflict on their own, something bad has happened. It's hard to take into account all the little things someone else may have done with their code, especially when the conflict it only on a handful of lines. Talking with the team about the best way to reconcile changes is the only way we've found to reliably get around conflicts happily.

The communication also helps avoid merge conflicts happening in the first place: if developers are aware of what else is being worked on, they can avoid creating conflicts by working on other parts of the software.

Hope this helps, let me know if anything isn't clear.
Logged

Sik
Level 10
*****


View Profile WWW
« Reply #4695 on: December 14, 2014, 02:49:47 AM »

Never used SVN before (not directly, at least).

And yes, we knew about pulling, commiting, etc., but basically if two of us worked simultaneously (even if on different files) and tried to merge their changes, the second one to do it would get an error and be forced to stash (requiring to back-up all changed files, stash, put back the backed-up files then commit everything again). So obviously something we had missed something. Also the fact that the issue happened even when working on different files shows it wasn't an issue of incompatible merges either (like, shouldn't that be the safest?).

The problem is that looking information about git requires you to know what you're looking for beforehand (which is not exactly easy if you're learning it!). Sadly this problem isn't specific to git, it seems that the majority of things made for programmers are like this. Ugh.
Logged
BorisTheBrave
Level 10
*****


View Profile WWW
« Reply #4696 on: December 14, 2014, 04:04:16 AM »

forced to stash
Yep, here's your problem. stashing is a way of temporarily saving uncommitted changes. It's handy, and I do use quite a bit. But it's not the the workflow git was designed for. The idea is that before merging in what the other developers do, you commit what you have locally. That way, if the merge (or rebase) goes bad for whatever reason, you'll have something to rollback to. Git won't let you merge without having that safe recourse. Yes, even if the merge won't have any conflicts. This is because (I think), even if there are no merge conflicts, you may discover that the merge was bad for some other reason, and need to rollback; git aims to have very few commands that cannot be undone.

IOW Git encourages you to commit frequently - no one else can see your commits until you push them anyway, and there are feature for cleaning them for public consumption. That said, I do use stash/pull/stash pop quite a bit.

Edit: Also, I found after using git for a while, I becaume a lot less compulsive about pulling frequently, (the direct opposite of Geti's experience). I can work from a stable base for some time, knowing that despite getting out of sync with trunk, git's merge tools won't make it too much of a hassle to deal with. I save time by only doing a single merge when I'm ready to push something. Sure, sometimes I'm so far out of sync the merge is too much of a monster to deal with - but then I can always do it as a series of merges exactly as if I had been following along as I go, but without my own code varying.

Double Edit: I should mention I tend to use fairly heavy use of rebase to neaten up commits. My actual pushed history doesn't contain any merges or broken revisions.
« Last Edit: December 14, 2014, 04:15:57 AM by BorisTheBrave » Logged
Sik
Level 10
*****


View Profile WWW
« Reply #4697 on: December 14, 2014, 05:18:18 AM »

Except because we would commit. It'd go like this:
Code:
git add «files»
git commit -m "«message»"
git push
«error message»

Sadly I don't remember the error message anymore, otherwise I'd say it, but it sounds more like a configuration issue (I guess it expected us to split something before working on the code?).
Logged
BorisTheBrave
Level 10
*****


View Profile WWW
« Reply #4698 on: December 14, 2014, 06:34:32 AM »

Merges are resolved locally. Hence you need to pull before you push. Doing what you are doing, it is rightly complaining that you are asserting you are fully up to date when you are not.

Here's the error message you would have seen:

Code:
! [rejected]        master -> master (non-fast-forward)
error: failed to push some refs to '<your repo>'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')
hint: before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

Now even if don't follow the jargon, it is pretty clear that a merge is necessary because you are not up to date, and gives you the command for doing so. I'm starting to think you are simply not reading things, rather than the quality of available documentation.
Logged
Geti
Level 10
*****



View Profile WWW
« Reply #4699 on: December 14, 2014, 06:36:43 AM »

@BorisTheBrave Re: sitting on changes - to each their own, but at THD we've found that keeping more in-sync means we get fewer headaches, haha. Often we're working on reasonably closely related code though, so that's probably a factor.

@Sik Re: cli interfacing with these tools - honestly I gave up on that pretty quickly and grabbed any of the working gui tools (currently using sourcetree, previously used tortoisehg/git) as then I get reasonable feedback if/when I do something wrong. I can appreciate wanting to understand how they work and being cli-proficient and whatnot but it's easier to make technical mistakes and unless you're requesting status output often it's easy to lose sight of the current state of the repository.

Re: your specific issue - DVCS are usually very robust in the face of merging because it's such a common operation.

The error message you might have been getting was that you'd be pushing a new head to the repo (I see no merge there in your example workflow), which is problematic as it means you're creating a branch in the repository rather than contributing development - if one of you had pushed before, the other would need to merge before pushing (or force the push and push a branch into trunk/default/whatever).

Edit: ninja'd by boris
Logged

Pages: 1 ... 233 234 [235] 236 237 ... 295
Print
Jump to:  

Theme orange-lt created by panic