Suggestion for Improvement: New default walkable area ID

Started by Milhouse, Fri 28/12/2012 02:27:59

Previous topic - Next topic

Milhouse

Hello guys,

For the last two days I've been playing with AGS and especially one issue has cost me a lot of time: I wasn't able to draw walkable areas.
Ok, now after hours it's clear to me how to use that feature...

1. My experience
I was told by a tooltip that "You are currently using the eraser. To draw new areas, change the selection in the list above the Properties Pane." Well, in all other tools I know you have to click an eraser icon or select that command from a menu in order to enter such an mode. I hadn't done that. Also I wasn't able to locate the walkable area ID selection list ???. This was probably due to the huge width of that control. I just wasn't able to identify it as a list control. Ok, maybe I'm stupid... :-[ But let me tell you that I've been a software engineer for seven years. And developing .NET user dialogs has been one of my tasks. The help or FAQ don't mention that problem. Finally, I was able to solve that issue by using the search feature of this forum: A post with a screenshot how to change the walkable area ID to something else than 0.

2. Why you have that problem following a tutorial
I was watching the youtube tutorial by densming. So I started a new project with the default game and switched the background. I was notified that the new background had a different size and everything including the walkable areas would be deleted. Ok, the first time I didn't read that message box, but that wasn't the problem. The problem is: After deleting the background image of the only existing room and deleting the walkable areas due to the new background size, the walkable area ID is set to 0 and remains zero unless set to something else manually.

3. Two suggestions to remedy that problem.

  • After assigning a background image with a different size and deleting the walkable areas make sure to set the walkable area ID to non edit mode. Note: That buggy behavior does only appear in case there is only one room! (repoduction is quite easy with a new project and the default game) Also it might be of help for beginners to change the selection text from "walkable area ID 0" to "walkable area ID 0 (eraser mode)"
  • Walkable areas and other regions are not object oriented. Instead, they are internally implemented by using image files and color codes to code the different regions. From that (developer) point of view it makes totally sense to have an eraser mode assigning color code 0 to pixels. However, there are users not familiar with that part of AGS history, instead, they are familiar with object oriented tools. So, they first try to treat walkable areas as objects. The editor supports that thinking as every walkable area has properties assigned to it. So it seems naturally to have walkable areas overlap each other. But that's not possible as each walkable are pixel is only able to keep one color code. Also from an object oriented point of view it doesn't make sense to draw into one walkable area in order to delete other walkable areas. My suggestion is to change the selection list to a color pallet to make it more obvious that it's a actually a drawing tool for a 2D image. The colors could be arranged in two rows each of them keeping 8 colors. This way each color would be big enough to keep the ID of its walkable area as text. Also the Properties Pane could still be used as it would show the properties of the color currently selected.

I'm looking forward to getting feedback for suggestion #2. However, suggestion #1 describes a bugfix and should be implemented ;)

Regards
Marcus

Milhouse

In suggestion #1 I've claimed there is a bug that sets the walkable area ID to 0. This statement is incorrect! :-[ It seems that I've set the walkable area ID to 0 by myself. This has happend because I was "exploring" the walkable area feature by left clicking with my mouse. As the "Select area" tool is the default, the walkable area ID was set to 0 without me (unfamiliar with the feature) recognizing that.

Ok, it seems like it's a feature, but to be honest, I still think it's a usability bug. It could be solved by selecting  a different tool than "Select area" as the default one.

Milhouse

Regarding suggestion #2 - Here's a mock example of how this could be implemented:

I didn't place the pallet close to the properties area, but instead to the toolbar where you normally expect such a feature. Of course, the current selection and the walkable area selection list had to be synchronized in both ways. And if you moved the "Select area" tool from the left closer to the pallet it would be even better grouped in regards to functionality.

Crimson Wizard

I support this suggestion, for I too found selecting regions in combo box not convenient.

BTW, there's something else I suggested a while ago regarding project tree and room editing mode:
http://www.adventuregamestudio.co.uk/forums/index.php?topic=46483.0

Monsieur OUXX

+1

I hate that darn combo box.
Not to mention very often I even forget about it and spend way too long remembering how to switch between areas.
 

tzachs

I definitely agree with #1, this is definitely not user friendly.

Regarding #2, from looking at your mockup the only issue I see that you are limiting the number of walkable areas to 15, which can pose a problem for ambitious games.. If you come up with a way around that I'm on board (and feel free to code it since you've confessed to have experience in dot net ;) ).

And a bit unrelated, but I believe overlapping walkable areas is a useful feature that should be supported in the future.

Crimson Wizard

Quote from: tzachs on Sat 29/12/2012 22:24:39
Regarding #2, from looking at your mockup the only issue I see that you are limiting the number of walkable areas to 15, which can pose a problem for ambitious games.
AGS currently supports only 15 areas per room.

Milhouse

Quote from: Crimson Wizard on Sat 29/12/2012 22:57:49
AGS currently supports only 15 areas per room.
However, AGS supports 50 hotspots. And the implementation of hotspots derives directly from walkable areas. So if you e.g. switch from walkable areas to hotspots the palette control has to deal with that. Of course, in such a case the palette control could be switched to being invisible. But due to the inheritance dependencies I found in the code, I think, the patch would be smaler, if the feature was implemented for hotspots, walkable areas, walk-behinds, and regions.

Milhouse

Quote from: tzachs on Sat 29/12/2012 22:24:39
and feel free to code it since you've confessed to have experience in dot net ;)
I've already had a look at it ;)

What I found was a nicely designed architecture with quite a learning curve. It would be a lot of effort to change the toolbar so that it could keep other controls than icons. From this point of view the palette control would be in better company close to the other non toolbar icon controls like the zoom and trans sliders. Any suggestions?

Btw. is there somewhere information about how to submit a patch and allowed namespaces? E.g. is it allowed to implement drawing routines for custom controls and mess with windows messages? I'm asking because future compatibility to mono seems to be important (in other threads).

Milhouse

Quote from: tzachs on Sat 29/12/2012 22:24:39
Regarding #2, from looking at your mockup the only issue I see that you are limiting the number of walkable areas to 15, which can pose a problem for ambitious games.. If you come up with a way around that I'm on board
I could imagine to start with e.g. one of the controls at http://www.codeproject.com/Articles/12327/Office-2003-Color-Picker and modify it for walkable areas etc. Suggestions?


Milhouse

Quote from: BigMc on Sun 30/12/2012 04:04:28
How to submit a patch.
You seem to have many many repositories... And good that I asked because I've used used https://svn.adventuregamestudio.co.uk:7743/svn/ags/trunk/ instead of https://github.com/adventuregamestudio/ags. What's the reason for so many repositories and branches? I haven't found any sticky note explaining that "mess" (sorry for that) for someone new to the topic. Or is this intended to be some kind of adventure everyone has to complete before contributing similar to the forum registration quiz? (laugh) Just wondering ;)

BigMc

I guess you mean the different branches. The master branch is what you want.

EDIT: And that everybodies personal ags repository is visible is just because github is awesome.

Calin Leafshade

The svn repo is CJ's repo which matches the current 3.2.1 release but it's not the current repo in development.

All development should be done against the github version.

Crimson Wizard

I think it's the time when we should define how we organize versions?
The github.com/adventuregamestudio/ags is constantly under development (mainly refactoring and fixes to the engine atm). It would be not wise to just get everything in the pile, because while editor may be fully working with these new features, engine may still have some issues.

I think what they did in original SVN was creating a separate branch for the new version when it was ready, while the "main" (or "master") branch could be changed further?

What about we do this:
- define goal for the next versions of both engine and editor;
- when those two approach their goals we create separate branch for it, like ags_3_3. All changes related to the version goals are made in the branch and copied (merged) to master afterwards.
- meanwhile the master branch could be changed further on its own without affecting planned version.

BigMc

Also: Delete 64bit and refactory and rename main to legacy to avoid confusion.

EDIT: Here is a good example how to use branches: http://nvie.com/posts/a-successful-git-branching-model/

Monsieur OUXX

#16
Quote from: Milhouse on Sun 30/12/2012 11:18:53
is this intended to be some kind of adventure everyone has to complete before contributing?

For the record: that's because the community brutally took over Chris Jones' code and 2 years later you can still feel the aftermath of this. While there is a lot of very good contribution, the whole process is not fully centralized yet (at least in appearance). But if you ask questions on the forum, as you can see people are glad to help, and overall the result is very good!

 

Crimson Wizard

Quote from: BigMc on Sun 30/12/2012 14:51:00
EDIT: Here is a good example how to use branches: http://nvie.com/posts/a-successful-git-branching-model/
Ah, so it's opposite: use master as a stable branch, and make development in a separate.

BigMc

Quote from: Monsieur OUXX on Sun 30/12/2012 15:11:33
Quote from: Milhouse on Sun 30/12/2012 11:18:53
is this intended to be some kind of adventure everyone has to complete before contributing?

For the record: that's because the community brutally took over Chris Jones' code and 2 years later you can still feel the aftermath of this. While there is a lot of very good contribution, the whole process is not fully centralized yet (at least in appearance). But if you ask questions on the forum, as you can see people are glad to help, and overall the result is very good!



In my perception he was fine with the community taking over, the thing just never happened in an organized way. One problem that persists is that the homepage still does not reflect the new situation (github repo, available ports, news regarding development, etc) properly.

Quote from: Crimson Wizard on Sun 30/12/2012 15:16:29
Quote from: BigMc on Sun 30/12/2012 14:51:00
EDIT: Here is a good example how to use branches: http://nvie.com/posts/a-successful-git-branching-model/
Ah, so it's opposite: use master as a stable branch, and make development in a separate.

You could replace master and develop in that text with stable and master. Depends on whether you expect develpers or users to clone more often.

EDIT: But I would make master the stable branch too once there is a stable version.

Milhouse

I just know SVN well and have always used the folder structure suggested by the SVN makers. That way it's also easier for a new member of the development team to be productive right from the beginning. GIT uses a more modern approach and if I had a new project I would go for it. Also I would stick to the suggested workflow of the git makers. There is an open source git book available at the git web site that also suggests branching work flows. I would be glad if I just had to learn from that source. No adventures ;)

If I had to decide, I would close the SVN repository as it's already hard enough to manage and have the overview of one repository. Just my two cents and own experience.

And I agree with Crimson Wizard that you should know how to organize versions. That's the task of a project manager or project manager team. Who has done that task so far?

SMF spam blocked by CleanTalk