411 replies to this topic

[lonegraywolf]

The only thing I will request if we have scroll-bar-able screens is that there is some indication on the GUI where a "screen" ends.

[Cameron]

Yeah I agree with Wolfman. Actually, I'm kind wondering how LTTP scrolling would work. I don't quite understand how we could navigate through maps/screens and whatnot. I'm probably thinking about it wrong. Could someone explain?

[Beefster]

It would be useless if there were no scrollbars. Maybe a double-thick line could mark screen room edges?

...I've basically taken charge of GUI design.

Edited by Beefster, 03 July 2010 - 10:41 PM.

[Hoten]

I would like the option to toggle making adjacent rooms in the editor dimmed out. That way you could focus on screen design along the borders.

I don't know about any of you, but I'm anxious to get this thing started! I doubt I could contribute much on the actual writing the C++ code (at least, not at first. Learning it is on my todo list), but I'd enjoy helping out in any other way, mainly ideas or optimization.

Honestly I believe that making the perfect (or any) GUI can wait. The first thing on the agenda should be deciding on the fine line between "hardcoded" and "scripted". Meaning, just how much do we leave to scripting?

Then getting the core & scripting engine...that should be finalized as much as possible first. THEN the noob-friendly/don't-make-me-do-any-scripting GUI could come.

[Joe123]

I'm joining a little late here so I apologise if I end up going back over things that people have already said. I'm pretty sure there are some points which other people haven't already made though.

Quite a lot of people seem to be talking about using things like 'Combos', 'Flags', 'Maps' and 'Screens'. My opinion would be that most of the systems which we used in ZC before is pretty much outdated and can be replaced (or at least very much augmented) with something more powerful/user-friendly.

Think about 'screens' for example: things like having a line to mark room edges as Beefster says; most of the time you wouldn't need to have discrete rooms or screens at all. Why not have a map which would be a user defined size (in pixels or 8 pixel squares or something)? You're free to scroll around it in the editor as you would be able to in the player. You could have an option to add a grid like in ZC (and then a double thick line would probably be the best idea), but for maps with scrolling which would probably be the majority of them you wouldn't need screens at all like in ZC.

And then combos, why should all of our placeable graphics need to be restricted to one 16x16 pixel tile which is placed down on a rigid grid?
Something more like the combo aliases we have now but no-one uses I think would be a better idea. You can make a graphic with an arbitrary size, and you have the option to place any part of it on any layer. All you have to do to place a tree is click on it and place it where you want it. Then all of the graphics would become something more like freeform combos; when you place them they have no inherent properties (apart from walkability), but then if you edit them once they're placed you could give them speed/acceleration settings like our FFCs have at current, or the choice to place one or more of the pre-loaded scripts which gives graphics their properites (so that'd be like giving it a combotype or a flag, except there's no need to stay restricted to that system). Obviously there would need to be options to keep things snapped to a 16x16 or 8x8 grid, but you don't need to stay restriced to that system.
You could make 'combos' (or aliases or whatever they're to be called) with no graphic which are then set up to be placed for events (maybe that you can drag to increase the size of),

Those are the first two things that come to mind, but I think the argument applies to quite a lot of different areas of the program which may have similar functionality to what we're used to; just because it works like this in ZC doesn't mean it has to in our new program.


The other thing is the editor, why would we need to have a fixed GUI? If we're using Wx and it's got a proper window system rather than Allegro's horrible windows, we could have a 'graphic panel' and a 'layers panel' and a 'main editor box', which the user can then drag around where they want them. We'd make a default set-up (or maybe a few default set-ups!) which had all the main options in it and was quite accessable, but if the user wanted to drag in a link to a dialog or a box which they used more often than other people or something then they'd be able to do it.

[Koopa]

@Nathaniel et al.: I think it's worth a subforum of its own, especially as it costs about $0.00 to set up (and to remove again, should it not work out). Then we could have seperate threads for things like graphics, file formats, scripting etc.

@Wolfman (file format): The good thing about this approach is there are bound to be libraries that do 90% of the work for us. Reading or writing a file in such an archive could be as simple as (to make up some syntax)

CODE

Archive quest = Archive.open("first.zm");
Bitmap startingScreen = new Bitmap(quest.getFile("start.bmp"));

i.e. all the file/zip stuff is done by itself so you can work as if you had individual files for each resource you need. That'll cut out pages of file format handling code copmared to the current ZC.

@Hoten: Before both the player and the editor comes an integral and important part of professional development, namely the planning and design phase. At the company I work for at the moment, we plan, design, specify and review a great amount before any line of code is written - in the end, we're not only faster but also end up with more stable code than if we made it up all as we go along.
The planning phase has already started, we're in the middle of it. Soon, probably in a forum of its own, we can plan out the main classes and functions.


@All:
As I said to Hoten above, I work as a professional software developer (Java/Groovy) and in projects there, there's a long and detailed planning and specification phase before we actually write code. This is every bit as much a part of our job as the actual coding and can easily take up 1/3 of the total project time. If you compare it to a project like writing an essay for which you have a month's time, you'll first do research and reading up, collect materials, draw up a list of contents so on before you actually sit down and write the final version.

So for the question "When will we start this?", here's my answer: We already have!

[Snarwin]

Surely 16:9 ratios should be supported as well in the player. Perhaps the standard for those could be 1280 x 720 or something. People could then run HDMI out on thier computers to thier HD TV's and play it like that. ^_^ This amounts to like 3600 16x16 tiles on a single layer alone shown on screen so software rendering is out as it would choke on itself and die a horrible death trying to maintain 12 FPS. Also resizable screens should be standard unless otherwise specified, and simply scale the res accordingly.

Maybe I'm the only one, but I always kinda liked that I could run ZC on my five-year-old laptop with crappy integrated graphics and a 1024x768 display, and while I have nothing against supporting higher resolutions, I'd rather it didn't come at the cost of "choking and death" for anyone without a fancy video card.

I realize that this is the 21st century and all, but ultimately, we're talking about 2D tile-based games here, and I really don't see why something like that should have anything more than very basic system requirements.

[lonegraywolf]

I realize that this is the 21st century and all, but ultimately, we're talking about 2D tile-based games here, and I really don't see why something like that should have anything more than very basic system requirements.

Tell that to Sega when they released Sonic the Hedgehog for the GBA. A hacker managed to do a much better job.

Anyway, I know Google Wave didn't work out too well, so I'll try another companion thing here: Google Docs. We need organized documentation, so we may as well have a common place again. It's already set for people to edit, though signing in beforehand would be preferable.

Edited by Wolfman2000, 04 July 2010 - 09:04 AM.

[Nathaniel]

Google Docs is a nice way to go with the documentation. I wouldn't use it to write up my teaching notes (spacing issues, looks different when printing, symbols, etc.) or anything I need to print for that matter, but it is great for generally sharing typed information that anybody can edit without the need of constantly downloading and then uploading updates. Prevents a mess of files and possible confusion from it, when you can stick to just one that anybody you wish can edit and save.

As for the forum creation, I don't know when the time will be right for it, but when you guys feel you are ready, just let me know.

[Beefster]

As Koopa said, the more we plan and communicate before actually coding, the cleaner the codebase will be, and ultimately, the faster the development will be and the easier bugfixes will be. With a development manpower of ~100 man-hours/week, the project should take 3-5 years to reach version 1.0. (5-6 devs working on the project 2-3 hours every day, on average)

Anyway, I need to put this on the table right now: I am a Mormon and I will be leaving on a mission in a little over a year from now, and I will not be able to participate in the development during that time- I can't promise a whole lot of coding other than laying down the foundations; however, I should last the whole planning phase and will still be able to make reference mock-ups of the GUI in that time. When I leave, I WILL need someone to replace me for my 2-year haitus, after which, I will likely take a spot back anywhere in the development.

[Cameron]

As Koopa said, the more we plan and communicate before actually coding, the cleaner the codebase will be, and ultimately, the faster the development will be and the easier bugfixes will be. With a development manpower of ~100 man-hours/week, the project should take 3-5 years to reach version 1.0. (5-6 devs working on the project 2-3 hours every day, on average)

Anyway, I need to put this on the table right now: I am a Mormon and I will be leaving on a mission in a little over a year from now, and I will not be able to participate in the development during that time- I can't promise a whole lot of coding other than laying down the foundations; however, I should last the whole planning phase and will still be able to make reference mock-ups of the GUI in that time. When I leave, I WILL need someone to replace me for my 2-year haitus, after which, I will likely take a spot back anywhere in the development.

I'm starting to learn C++ now and it doesn't seem too hard. Though it will still be a long time before I can do anything.

Edited by XxGamasterxX, 04 July 2010 - 05:58 PM.

[Beefster]

I'm starting to learn C++ now and it doesn't seem too hard. Though it will still be a long time before I can do anything.

Wait until you get into pointers! Those will give you massive headaches- especially when tracking down memory leaks and junk pointers. Despite that, dynamic memory allocation is very rewarding.

[Cameron]

Wait until you get into pointers! Those will give you massive headaches- especially when tracking down memory leaks and junk pointers. Despite that, dynamic memory allocation is very rewarding.

Sounds like fun . The book I'm reading is currently going through data types. Are things like long double or wchar_t used a lot? They don't seem like something that needs an entire chapter given to.

More on topic, what libraries have we decided to use? I'll probably need to look into those eventually (not even remotely soon) too.

[lucas92]

long double yes, wchar_t no.

We've decided to use SFML.
http://www.sfml-dev.org/index.php

wxWidgets
http://www.wxwidgets.org/

[Cameron]

long double yes, wchar_t no.

We've decided to use SFML.
http://www.sfml-dev.org/index.php

wxWidgets
http://www.wxwidgets.org/

Thanks, I'll keep those in mind. Well, I've got a lot of work to do.

EDIT: Woo. 200 posts.

Edited by XxGamasterxX, 04 July 2010 - 08:19 PM.