SFML community forums
General => SFML projects => Topic started by: Ungod on November 26, 2015, 09:59:30 pm
-
(http://s11.postimg.org/o9047w76b/lota_banner.jpg)
Youtube https://www.youtube.com/channel/UCzzf_JgcMKhhMCQbp4Y960A (https://www.youtube.com/channel/UCzzf_JgcMKhhMCQbp4Y960A)
Facebook https://www.facebook.com/theLastOfTheAmbaras/?ref=aymt_homepage_panel (https://www.facebook.com/theLastOfTheAmbaras/?ref=aymt_homepage_panel)
Hi Guys :)
This project swallowed countless hours now and i felt its time to present it and get some feedback. There is much to say, so i will structure this post into some subtitles so you can scrolls through and read the passages you are interested in. If you want a more in depth explanation of some aspect, I will extend the text later.
But a picture is worth a thousand words so you may start on my YouTube channel. I recently released a first DevLog. This thread will lack screenshots because anything visible I want to present at the moment can be seen there.
DevLog: https://www.youtube.com/watch?v=ekcwa97kAB4 (https://www.youtube.com/watch?v=ekcwa97kAB4)
- FIRST OF ALL: WHAT IS LAST OF THE AMBARAS?
It's a 2D RPG game in a completely new fantasy world, based on my own lore and my own rules. I dont want to leave many words about story now,
because there is still no story implemented in the game (its all in my head and written on paper), but let me give you a short introduction.
The empires Vaugaloth and Nagrond are ruled by two of the oldest families of the known world. The Ambaras reign in Venthal, in the Crystalline Citadel and in the present, the lost most of the power they had in old times. There are just a few of them left and thats what gives the game its title. On the other side of the Grey Sea reside the Cravacus, a proud house which emphazies honor and traditions. There is an old hatred between these families and it needs just a small stumbling block to newly inflame the war between them. When you enter this world, it seems that this little rock suddenly has fallen...
- HISTORY
Spring 2014, I just started to devolop a game, quite planless, since I just wanted to do some cool stuff with the things I learned in university.
Up to Fall 2014, I build a prototype of my game in Java, starting with a simple console-text-RPG up to some cheap mouse-drawn assets and a little guy i could controle with my keys. I noticed my pleasure creating video games during this time, so I decided to create some serious concepts based on my own game-expirience up to this point. I painted many assets with a graphics-tablet for a game that was just in my head, but I never put by this hobby, so it evolved over time.
Finally since january this year I code in C++ using SFML. I did a complete redesign of my Java code, starting with a tough core-engine, wrote a main-loop with clean timestep, set up asset-managers and I racked my brain about efficient resource handling and XML-parsing. The first time of coding was quiet hard, because I came from Java my C++ expierience was outdated and additionally writing the raw base of an engine is not very exciting at all. But practice makes perfect, thats for sure.
- ENGINE
Lovely called Ungod-Engine after my name. I tried to build my code as generic as possible, though I dont think I will use the engine for stuff other than this game in the next years. But genererally I think its useful to stay as generic as possible, so you may can use the same code for multible purposes.
In its core, my engine works as almost every other engine too, so I dont want to leave many words about that here. Its based on a entity system and mainly uses a quad-tree to store world-content.
The quad tree is one of my favorite data-structures when handling 2D content, and its due to him, that my open world-concept works as intended. During update (especially collision-detection) and rendering process, the engine just retrieves the entities that are around (or directly on) the screen in an efficient way, instead of iterating over vectors of millions of pointers.
- WORLD
The Game takes place in a huge open world. My goal is to realize this without loading times at all to ensure REAL open world feeling. So how is this done? Currently my worldmap is just a single quad tree, which can indeed store a huge open world map, but 500k trees loaded independent from the distance to the player, can easyly fill the RAM. To solve this problem I came up with this: The world will be seperated in chunks. You can see them as squares in the 2D space. All entities in a chunk can be stored in a xml-file on the hard drive and the engine just loads the chunk containing the player and the 8 chunks surrounding this chunk. Every chunk will has its own quad-tree with entities. By storing a pointer to the currently visited chunks, its possible to efficiently retrieve the only world data relevant at this point: Those which is near the player. When entering a new chunk, the engine will automatically deallocate the memory from old chunks and will load new chunks in a seperate thread. This way I get a huge open world with dynamic chunk management and no loading screens at all. At least thats the future plan.
What about world design? Well the plan is, to procedurally generate a huge open world map (based on the chunk system explained before) and fill it with random content. The editor is now a tool to handcraft the content of a chunk and i will use it for example to create fixed cities in the random world.
(some points comming soon)
5. Inventory/Items/Skills
6. Enemy-AI (finite state mashines)
7. Art (not about coding at all)
8. Editor
9. GUI
10. Sound
I think thats enough for an initial post. I will extend the text with code if you want, but at this time its hard to say what could be an interesting while at the same time short and pregnant code passage to present.
So long ~Ungod
-
The title/cover image artwork is beautiful.
-
This looks great! :)
-
That looks pretty!
-
Thx very much for your kind words! ::)
-
It look very good but maybe you should go towards graphics of izometric projection? You know like 2.5D maybe the result would be even better. Look to game Warcraft 3 or 2 i know its in 3D engine but for such an outcome I mean. Anyway the game promises to be very well. Good luck ;)
-
Thx for your feedback! :)
I tried isometric projection in the beginning, but I found it too 'rigid' for my purposes. I currently use some kind of oblique projection and I like it more, because of its depths and imo it hasnt this hard "viewer from above" effect of isometric view. Thats because in oblique perspective, you actually see objects in their "full-size" from a kind of front view. Isometric perspective is great and good to drawn, because of its fixed angles, I just think it doesnt match my purposes.
But this is much about personal preferences. I already have some castle and town assets ready (but not implemented). I can do a fake screenshots when I have some time and you can check how the perspective looks if some architecture comes in.
-
Very impressive.
Looks nice.
Good work.
I'd probably play a Linux version of this.
-
Hey Guys.
Devlog number 2 is out now:
https://www.youtube.com/watch?v=YoHdlmTRP5k&feature=youtu.be
I'm very busy at the moment and there is not much time for game programming. But I plan some very exiting things in 2016 from programming side and I will definitely share them here.
I'll do some audiodesign over christmas and other creative things, but probably no brain-labor at all. I've found a critical engine bug in the last days, but I will definitely need a few full-time days to fix it and there will be no time and motivation in the last 2 weeks of this year. :'(
So long, relaxing holidays for all of you!
-
Cool.
Ambitious! But it's amazing what someone can do when they're working on a game they love. Thanks for sharing.
-
Thx!
What you mention is definitely a fundamental of indie-game-development.
-
So hey again. Some time has passed and I'm a upset that I managed to make to less visual progress.
I had some pressure with exams in january and someone destroyed my netbook in february which bounced me back for about ~10hours of work. Not that much at all, but actually a huge demotivation for me at that moment.
In fact I currently redoing most of my engine before making any gameplay progress. I reworked my whole memory management so that the engine now uses c++11 smart pointers and I redesigned hundreds of code lines which were simple crap before. Right now I implement a new design for metadata which is more generic and less code-intensive. Also my xml is now much more structured then before:
<meta fileID="0">
<stats count="18">1 10 28 20 8 8 2 4 8 70 45 3 1 2 75 100 95 18</stats>
<souls count="31">1 5 7 11 16 17 20 21 24 25 26 27 29 31 32 36 41 42 44 46 49 54 56 58 60 61 62 72 73 76 87</souls>
<skills count="15">0 2 0 0 2 1 0 2 2 0 3 0 0 1 1</skills>
<drops count="12">0 8 11 12 13 14 15 16 19 20 21 22</drops>
<!-- health_tresh | en_tresh | skill_delay | arrival_radius | roam_dist | roam_timer_lower | roam_timer_upper | max_vel | evade_dist -->
<AI count="10">25 35 2000 50 200 8000 15000 1 350 330</AI>
</meta>
What the hell was this?
It changed to:
<stroller base_soul_slots="1"
experience="10"
drop_rarity="28"
drop_rate="20"
soul_rate="8"
base_ardor="8"
base_spirit="2"
base_cabal="4"
base_bravery="8"
health="70"
damage="45"
ardor_resistance="3"
spirit_resistance="1"
bravery_resistance="2"
attack_spread="75"
attack_range="100"
attack_angle="95"
body_weight="18"
can_hold_soul_effects="1 5 7 11 16 17 20 21 24 25 26 27 29 31 32 36 41 42 44 46 49 54 56 58 60 61 62 72 73 76 87"
attack_sound_1="assets/sfx/foes/attack1.wav"
attack_sound_2="assets/sfx/foes/attack1.wav"
idle_sound="assets/sfx/foes/stroller_idle.wav"
defensive_state_sound="assets/sfx/foes/attack1.wav"
death_sound="assets/sfx/foes/stroller_death.wav">
I now use 2 classes for meta-data:
One is vector based and xml nodes (like the one above) can be directly accessed with indices. I use this for ordered stuff like enemy-types (which have natural numbers as IDs).
The other one is hash based and uses a unordered_map to access xml-nodes through string keys.
I use this type for things like config-files in which the entries are bare any order.
-
Cool, keep it up! Any progress is progress! :)
-
Mini-Update:
I recently finished the improvements on my skill-system so that skills (useable by both player and NPCs)
can be defined with cleaner xml-code.
What do you guys think of it? The question is: Is it easy to understand (for modders) and easy to use to create own skills or would you recommend me to spend time in making a GUI-tool for skill-creation? There are many skills ingame (currently 100) and they shall be easily extendable.
<skill skill_type="Magic_missile" cost="10" cooldown="1" activation_time="900" recharge_at_switch="0" AI_rating="5">
<mechanic mechanic_type="projectile">
<parameter speed="6" flight_range="1200" size="10"
sheet_id="assets/combat/Combat.png"
sheet_meta="assets/combat/Combat_Meta.xml"
sheet_key="SmallFireball" />
</mechanic>
<effects>
<effect type="Inflict_debuff">
<parameter debuff_type="Burning" duration_base="2" duration_multiplier="0" level_base="1" level_multiplier="0.15"/>
<condition>
<condition type="Target_is_foe">
<parameter/>
</condition>
</condition>
</effect>
</effects>
<audio activation="assets/sfx/skills/skillcast_ardor.wav"
mechanic="assets/sfx/skills/fireball_trigger.wav"
mechanic="assets/sfx/skills/fireball_impact.wav"/>
</skill>
(Example for a fire-projectile that inflicts burning-debuff on a single target foe)
Cool, keep it up! Any progress is progress! :)
Thank you :)
-
What do you guys think of it? The question is: Is it easy to understand (for modders) and easy to use to create own skills or would you recommend me to spend time in making a GUI-tool for skill-creation? There are many skills ingame (currently 100) and they shall be easily extendable.
Keep properties consistent (like using type for every tag instead of skill_type for <skill> and mechanic_type for <mechanic>
Also: Audio has 2 "mechanic" properties?
I think most modders can deal with well-documented, consistent XML code. A GUI seems more like a nice-to-have further down the road.
-
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)
-
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?
-
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.
-
I think someone who is willing to mod any game can grasp XML as easily as JSON, am I wrong?
-
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 (http://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.)
-
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.
-
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.
-
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?
-
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:
(http://fs5.directupload.net/images/170121/3p3gpq9j.png)
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)
-
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
-
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
-
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.
-
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.
-
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.
-
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:
(http://fs5.directupload.net/images/170124/mqg6uuud.png)
The shadow is drawn flat on the ground and thus drawn always behind objects that walk on it. Looks okay.
(http://fs5.directupload.net/images/170124/iqa36l9m.png)
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.
(http://fs5.directupload.net/images/170124/vhbrzcrq.png)
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.
-
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.
Heh, that's exactly what I'm doing in my game. I guess if we both came up with the same idea, we may be on to something. :)
It would be better if the shadow would affect the dude walking on it somehow, but not as awkward as in the second pic.
Yep, this is exactly what eXpl0it3r and I were talking about above. If you come up with a solution to achieve what you have in pic 3, I'd be interested to hear about it.