♦ framework/engine to make quests a.k.a. point & click adventures with 3D panoramic freelook. In Go, uses SDL2 ♦
If we were you, what would we write here to persuade us to use this thing?..
Make games, not engines.
And this is neither «game», nor «engine» actually, — it's a framework, a foundation to build your own game/simulation/whatever on. Regardless of how sophisticated a «real», production-level engine may be, it cannot satisfy all your needs if you are not able to change it: add required/remove useless features... or rewrite it completely. Of course, greater control brings greater responsibility, blah-blah-blah.
In the Past Hall they wait for us to recall: Atlantis II, Crystal Key II, Myst III Exile, Post Mortem, Return to Mysterious Island, Scratches, Sublustrum, ... add your own, and not from the past, but from the future.
• 3D panoramic & 2D rectangular locations
• Music, SFX, voices
• Inventory management, item usage
• Dialogues with branches
• Reading descriptions and books
• Different fonts for different elements, e.g. Menu, Hover, Dialog, Book
• Different cursors as well
• Easy access to resources in text and JSON files, modifiable by any text editor
• Main menu with Resume, Quit, New, Save, Load, and Help entries
• Actual saving and loading
• Built-in localization support for texts and voices; demo has English, Russian, Ukrainian
• Parallelized software rendering uses all available (logical) CPUs
• Configurator with GUI (separate Lazarus app)
• It's built on top of cross-platform base, hence... it's cross-platform too, wow
• Beautiful... Unrivalled... Groundbreaking... well, what was it... oh yeah, BUGs!
• ...nothing new, in fact.
«Features» NOT included
• Lots — add what you need. E.g. scripting to avoid recompilation at every logic change, or audio/visual effects, or mobile devices support, ...
Later versions may include additional features, but they tend to make engine «heavier» and harder to modify, which is something you'll have to do sooner or later.
Even the presence of some «features» listed above, like Credits or Dialogues, is unfavourable because they are implemented in the way that is probably not the most efficient (for your needs) one.
Watch the video at the top of this page; there is the same video and larger screenshots at Visuals.
Go to Download page, get Quesfera — source or precompiled binaries — and Quesfera-Data used in demo «game». Optionally, get Quesfera-Config if you prefer to change settings through GUI rather than by editing JSON file. Either you compile the source (see instructions on Download page) or get the binaries in the first place, put the executable (and libraries if necessary) to the same dir with Quesfera-Data.
Launch the executable and play the demo. The demo is far, far from what you want, so imagine how the former turns into the latter. Perhaps you need something entirely different?
Inspect the source. See how in-game things are implemented, where they are controlled from, particularly /play/state, /play/master, /play/locs/dummy. Learn about Animages, Pieces, Zones; understand the purpose of state.Control fields. The source is documented... at some places.
Change anything: a single sound, image of an item, dialog tree entry. Add new location, connect it with existing ones. Populate it with interactive zones and pickable objects, and the character to talk with. Make this character ask the player for the item from other location.
Compilation errors, runtime crashes, invisible bugs start to occur? Yes.
Notice how many things in this framework are implemented poorly, and rewrite them. Maybe some groups of actions are repeated again and again, thus they can be wrapped into a single func? And the interface, the controls; they're so clumsy...
Change more, rewrite more.
Now it's yours. Use it to attain what you want.
can be rendered in Blender (with Cycles renderer and panoramic equirectangular camera), in (older?) versions of 3DS Max (Wrap effect for Mental Ray renderer), in Mandelbulber fractal renderer, to name a few...
Quesfera expects 4096x2048 images (see core/video/pan.go)... not-so-small and not-so-fast to render, thus if the game «logic» is independent of rendering quality (that's how it should be), then you can defer the rendering with finest quality till the time when the logic is «finalized». Also, use cropping to render only the pieces of panorama that contain the animated objects (sorry for trivialities).
Permissions & Credits & Licenses
You do not need any permissions from us to use the framework.
We ask, but do not insist, to mention somewhere its origin (kind of 1st intro screen of the demo), to a degree inversely proportional to the amount of modifications it went through, and directly proportional to that itching thing called conscience :)
As for licenses, Quesfera is under GPLv3, but be careful with the assets that you use, especially if you are going to make profit with it. Also, notice that the licenses for Go, SDL2, Go-SDL2, Quesfera itself etc. are different... they may be even incompatible :(
This framework uses SDL2 (Simple DirectMedia Layer) binding for Go — go-sdl2 by veandco. It's included into source with import paths modified to use this local version rather than the one at GOPATH/src. Check new versions from time to time and replace the local copy.
More, more engines
And, obviously, much more engines in other languages, see wikipedia.org/wiki/List_of_game_engines if you haven't already...
Copyright © 2014–2018 Sunkware
This site gathers statistics with StatCounter