Last of the Ambaras

[Ungod]

Keep properties consistent (like using type for every tag instead of skill_type for <skill> and mechanic_type for <mechanic>

Seems rational. Done.

Also: Audio has 2 "mechanic" properties?

Yeah thats intended, since a mechanic (like projectile) sometimes needs multiple audio files (like trigger and impact) or even none. Whats done here currently is collecting all audio tagged with 'mechanic' and attach that files in the given order to the mechanic. The mechanic will access its sound files automatically by index so the user has to now how many sound-files the mechanic requires.

(Current but probably not final solution)

[Nexus]

Since you asked about easy/clean modding code: Why do you go with XML which has a rather user- (and parse-)unfriendly syntax and requires duplication of every single tag, whereas you could choose something much simpler and cleaner like JSON, which directly maps to data structures in various programming languages?

[Ungod]

The simple reason is that I started up with less experience and no knowledge about JSON. It would make sense to use it in a new project, but not in my current 20k code-line engine.

Anyway while XML is indeed somewhat (human-) write-unfriendly, its a pretty solution for intern data exchange between editors and game.

I never heard that XML is parse-unfriendly, could you explain that? My meta-files are anyway not that big, that parsing time matters.

[Tukimitzu]

I think someone who is willing to mod any game can grasp XML as easily as JSON, am I wrong?

[Nexus]

Anyway while XML is indeed somewhat (human-) write-unfriendly, its a pretty solution for intern data exchange between editors and game.

Since this scenario doesn't involve humans, wouldn't a binary format be more suited for this purpose? If text formats are still efficient and memory-acceptable enough, there's of course no need to make things complicated.

I never heard that XML is parse-unfriendly, could you explain that?

The Extensible Markup Language is more complex than most people believe, see here for a documentation of the standard. XML parsers either have to be very sophisticated (and thus giving up performance) or functionally limited. The syntax itself typically uses more space than a JSON equivalent and as such lower network throughput.

The additional complexity in XML is not just bloat, of course. It provides more features (like namespacing), but in my opinion, many applications just use the plain-old-XML style which could be replaced with JSON 1:1.

Further reading: http://stackoverflow.com/q/1743532

I think someone who is willing to mod any game can grasp XML as easily as JSON, am I wrong?

Yes, the basic things to know are really easy in both markup languages. The difference is, at JSON you know already everything once you know the basic things. The question is which language you rather want to read and write -- I would personally tend to JSON. Good IDEs can make XML less of a pain though (tag auto-completion and closing, etc.)

[Ungod]

Since this scenario doesn't involve humans, wouldn't a binary format be more suited for this purpose? If text formats are still efficient and memory-acceptable enough, there's of course no need to make things complicated.

Its always nice to have something human readable between editor and game to find bugs and to change things by hand.

JSON is indeed less space intensive as XML (while XML gives more flexibility), but take in mind I want to use it for game development. Do you ever saw/wrote a game that REQUIRED the minimal space/speed difference between JSON and XML?

From my point of view there is definitely no benefit in switching from XML to JSON, since this simply would be too much work.

[Hyden]

Include some pictures in your post and embed the YouTube video. . After following the YouTube link, the game looks pretty fun. The ground could do with some more work though because it doesn't really blend in with the trees and the player.

[Ungod]

Hey guys!

no, the project isnt dead! I just have literally no time to make a showcase and even if...
Well there was definitely huge progress in the last half year, but just a little part of it is the "visual" kind of progress like the stuff shown in the new video:

https://www.youtube.com/watch?v=ChQVWp4Wd5g&feature=youtu.be

Believe me, there is no much time to write some things down . Instead take a 1min-long "tip of the iceberg".

I currently think about publishing some parts of my code (things that could be used as mini-frameworks and are not dependent on the bigger scope of the project like my quad-tree-implementation, my serialization framework and other things). Is there something I have to know about licensing that stuff?

[Ungod]

I just posted an example of the state of the games art-design somewhere else and got the feedback, that there is not enough distinction between object and background. So I quickly edited in a shadow and it looked quiet better.

Here is what I'm talking about:



Did anyone implement a shadow system like this in the past and can share some experiences? How did it work? Color the sprite down to black, make it transparent, rotate it a bit and draw it behind its object? Or would you actually handpaint the shadows a load them in as a predefined resource? I would really like to hear some ideas. (Nice visuals > efficiency at the moment)

[eXpl0it3r]

Looks neat! You can check out Re:creation and ping Elias, he's not so long ago implemented his own shadow system.

http://en.sfml-dev.org/forums/index.php?topic=18062.0

[fallahn]

The key here I think is the contrast between the object and foreground which makes it stand out more. Perhaps you should also check out rim lighting to emulate a backlight, an effect I know valve uses in dota2. This can be painted on the sprites or applied as a realtime effect with shaders

[Jabberwocky]

Did anyone implement a shadow system like this in the past and can share some experiences? How did it work? Color the sprite down to black, make it transparent, rotate it a bit and draw it behind its object? Or would you actually handpaint the shadows a load them in as a predefined resource? I would really like to hear some ideas. (Nice visuals > efficiency at the moment)

A lot depends on whether you need dynamic lighting that your shadows must respond to.  Or if you want a day-night cycle.

If these things aren't important, I would definitely just go with hand-painting the shadow.  It's way less complex to code, and you can get your shadows to look perfect by drawing them exactly how you want.  It will almost always look better.

If you do want a day-night cycle, and your shadows need to change position, then you've pretty much gotta go with a progammatic solution.  Drawing a black/transparent version of the sprite for the shadow works pretty good.  You can stretch the sprite too, depending on the time of day, and height of the sun.

[eXpl0it3r]

If you do want a day-night cycle, and your shadows need to change position, then you've pretty much gotta go with a progammatic solution.  Drawing a black/transparent version of the sprite for the shadow works pretty good.  You can stretch the sprite too, depending on the time of day, and height of the sun.

This works well until a shadow hits another object, then things will "visually" break.

[Jabberwocky]

This works well until a shadow hits another object, then things will "visually" break.

True.  But whenever you're trying to create shadows (a 3D phenomenon) in a 2D game using sprites, there's going to be some things you can't get perfect.  You're basically faking it, with insufficient data to actually calculate the proper shadows, as you would have in a 3D environment with 3D models.

[Ungod]

Looks neat! You can check out Re:creation and ping Elias, he's not so long ago implemented his own shadow system.

Thanks! As it looks like, Elias' system works with vertex arrays to stretch the shadow instead of rotations, which is better. However, the system just works well for small sized shadows. At least in my engine the z-ordering would give strange results if I render the shadows of big objects (as regular entities) and than have some smaller entities walking "on" that shadow.

Here is how it could look:



The shadow is drawn flat on the ground and thus drawn always behind objects that walk on it. Looks okay.



The shadow is rendered as an regular entity with z-ordering. This looks weird in some situations.

It would be better if the shadow would affect the dude walking on it somehow, but not as awkward as in the second pic.



Best! But I'll have to think about how to implement it.

A lot depends on whether you need dynamic lighting that your shadows must respond to.  Or if you want a day-night cycle.

Thats true. Hand drawn shadows seem not to be an option at all. I fact, i'm currently using an altered version of Let There Be Light 2 to have dynamic shadows during nighttime. My plan is to disable this lightning during daytime and draw dropshadows according to the above approach. Those dropshadows may move from left to right, that shouldnt be the problem at all. Dropshadows are not drawn during nighttime.