411 replies to this topic

[lonegraywolf]

Curious: can any of you guys actually see if the google doc is editable by everyone? I may have set a flag wrong, and I haven't seen anyone contribute.

[Cameron]

Seems to work on my end. I added the line "This is a test" to see if it was working. Just check to make sure it showed up on your end and then you can delete it.

Edit: I should probably bookmark that thing before the link gets lost in the many pages of this thread.

Edited by XxGamasterxX, 07 July 2010 - 08:51 PM.

[Joe123]

What's the link to the google docs?

[lonegraywolf]

The Google Docs link is here for those that want to contribute. While anonymous people can contribute, I would recommend signing in first.

Edited by Wolfman2000, 08 July 2010 - 07:56 AM.

[Cameron]

I added a bunch of stuff to the Google Doc. You guys might want to check my work or add more stuff. I was just going through the topic and adding stuff.

[Gleeok]

I took a look at the Doc. Quick question: If tiles aren't aligned to a grid then doesn't that defeat the purpose of a tile-based editor? I assume someone meant 'sprites' there. (Hopefully you can have the ability to place a 'tree' sprite on a tilemap I would hope.) ..Or whatever they get called.

[Cameron]

I took a look at the Doc. Quick question: If tiles aren't aligned to a grid then doesn't that defeat the purpose of a tile-based editor? I assume someone meant 'sprites' there. (Hopefully you can have the ability to place a 'tree' sprite on a tilemap I would hope.) ..Or whatever they get called.

Yeah I was wondering if that would be confusing. Someone (I don't remember who) suggested that it would be an option to align to the grid. Most tiles would, but some would not. Like in Gamemaker where you can just align to the grid normally or hold down Ctrl and then place it off the grid. I hope that makes sense.

EDIT: I think it was Joe123 that said that, but I'm not entirely sure.

Edited by XxGamasterxX, 10 July 2010 - 07:06 AM.

[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.

What I was actually just going to say was something like 'if you select a graphic and just place it it aligns to the grid like a tile, but if you ctrl-click you place it as an 'active object' or something instead and it's more like an ffc'. I wasn't aware that's how it works in GM. It's only a suggestion though.

[Koopa]

SFML development and about 500 '-dev' packages set up. Whose idea was it not to include g++ in Xubuntu by default?

I'm really impressed with the SFML - even on my old laptop, it can spin a cube, play music, listen for input and tidy up my room all at once. (Ok, I made up the last one.)

Concerning tiles and placement, I'd imagine we'd have a coordinate system that's very fine-grained (unit 1 pixel ?) and you could place everything on that - walkability, triggers, damage etc. could be based on the fine grid if that's possible performance-wise (I don't see why not).

I'm wondering whether we even need 'combos' in the player (in the editor, we do for user convenience) - we could just have some graphics layers, a walkability layer, a trigger layer and allow them to be combined arbitrarily.

So you could just place a bush combo in the editor and you'd get the bush sprite and 'no walking' placed together. But you could edit those two properties individually as well if you wanted to.

[lucas92]

Did anyone manage to make a project with SFML 1.6 and VC++ 2010?

So what's going on with this project?

[lonegraywolf]

I'm stuck in summer school, and right now in a study group. I have to get back to that.

[Gleeok]

Did anyone manage to make a project with SFML 1.6 and VC++ 2010?

So what's going on with this project?

I don't have enough RAM to run MSVC10. :poop: ..bleh. Also sfml2 looks better, so I got rid of 1.6(5)?(whatever I had) and upgraded. Haven't had any problems with 2.0 yet. Is there like an add-on MP3 thing for sfml, or do you just have to use .ogg for stuff? ..

Edited by Gleeok, 11 July 2010 - 10:03 PM.

[LinktheMaster]

Gleeok, it's not listed anyone on their page, so, unfortunately, I don't think it allows for MP3s.

Anyway, a couple of ideas based on some things of read.

Integrating Scripting
Actually, I think the original idea about having scripting being the first "layer" of a game is a wonderful idea. How the player moves and attacks should be handled on this layer. To combat the whole problem of newbies having to code everything, we could have "templates" of code for when people create a new "quest." So whenever they start one, it'll ask "Which template do you want to use: Top down adventure; side scrolling platformer" or any other ones that can be thought up. These would include scripts for character movement (as far as restricting sideways and speed), attacks, and other similar things. Everything else would be handled by objects for enemies, items, attacks, etc. which would also be included in those templates.

That way, for the designer who wants to make a radically different layout for a "quest," they don't have to bother with being inefficient with overriding pre-existing built-in code.

The main things not included in templates gameplay-wise would be screen display, combos/solidarity for movement, health monitoring, and things like that.

It's just a thought, but I think it would be a good way of mixing both worlds.

Combo Display
Combos would still be essential for the developer's side for the reasons Koopa said. However, organization should be completely different. Rather than having one large panel where you scroll, they would be divided into user-created groups. In the creator, there would be a dropdown box with a list of those groups. Select a group, then the combos would appear under it. Examples of groups would be Dungeon, Overworld, Sprites, etc.

Koopa's idea for combos merely being a tool to merely combine solidarity and graphics for the creator's end is a good idea, too. However, that allows us to go further. Why not allow people to change solidarity on the fly? That way people don't have to make 2 combos where one is solid, and the other one isn't. Granted, it's not great to do that, but sometimes it is necessary.

For the scripting language, something simple like Python would be great, in my opinion. Though, I haven't had many experiences with most other "scripting" languages, we'd probably want a rather simple format. No semi-colons, no braces.

Edited by LinktheMaster, 11 July 2010 - 11:41 PM.

[Hoten]

No semi colons or braces would be a harder format. The braces provide readability, and the semi colons, uh, well, are a common programming staple? Maybe we can do without the latter, but it wouldn't make things any easier.

[Koopa]

Currently "user stories" are all the rage as a design tool, so ...

User story: A secret path
Koopa is making a quest. For one screen, he wants an invisible path across what looks like a bush in a line of real, solid bushes. First, he opens the 'combo palette' window. At the top, there's a list of categories including "all" and custom ones Koopa has made for his favourite combos or his themed dungeons. This time, he just chooses "vegetation". In the panel that unfolds, he quickly finds a bush and selects it. At the bottom, the bush is displayed with more detail - combo name, solidity, default triggers (none in this case). He places the mouse on the screen and drags it to craete a line of bushes.
Next, he chooses the "solidity" tool from the toolbar. The bushes, rocks and some other objects on the screen get a semitransparent red overlay to indicate they are solid. Using the dropdown arrow to the right of the solidity tool, Koopa selects "solidity eraser" and clicks on one bush in the line, removing the red overlay. He then turns off the solidity tool again.
Now he notices that on the side of the screen, the edge has turned red. This is an indicator that the solidity at the edge does not match the next screen (this is also known as a combo misalign). Dragging the bar at the side of the screen, he makes the editor show him part of two screens at once side-by-side. He can now correct the solidity on the next screen.

How does that sound?

By the way, MP3 support is not built into SFML for licensing reasons, but there is a 'stream audio reader' (callback based) which we could potentially hook up to LAME or something like that.