================================
All the contained source code is released under the GPLv3! Feel free to modify
it, fork it, fix it, or whatever. Let me know if you do any of these things. :)
You can reach me at kts@exoss.net or via http://kettek.exoss.net .
================================
,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
System Requirements
````````````````````````````````
At least 128 megabytes of vram.
At least 1 gigabyte of RAM (need to optimize)
Basically, most any system made in the last 8 years or so.
,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
General Notes
````````````````````````````````
Thanks for downloading this game, I hope you like it! Included is the full source
and binaries for 32-bit Windows 7 and 64-bit Linux.
This engine was written entirely from scratch starting at the very beginning
of June for Indie Game Maker 2014, as hosted by the great folks from RPGMaker
and Humble Bundle.
It uses SDL2, SDL2_mixer, SDL2_image, and OpenGL for handling all the stuff I
didn't want to handle.
,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
Technically Interesting Stuff
````````````````````````````````
The animation system works by attaching a tag (char*) to each frame. When this
frame is called, the tag can be referenced to do actions such as switching
animation sets(i.e., "walk" set -> "idle" set on "pass" tag). This lends for
smoother animation switching. Movement relies on this feature, as each time
the "walk" tag is encountered on a player or an entity, a certain amount of
force is applied to the player/entity. Attacks also work similarly, in that
when an entity collides with the player _and_ the "damage" tag comes up, the
player will take damage from the entity.
The engine uses nanosecond precision (at least on Linux and OS X(I think)).
However, the actual in-game processing uses milliseconds because I didn't want
to type in big numbers or do needless division and/or multiplication while
checking delta/elapsed time for various things. :)
,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
Credits
````````````````````````````````
Music
''''''''
MR4 - http://www.mrandy.net/music
Thanks to MR4 for allowing me to use his music! His benevolence really took a
lot of pressure off me - thanks so much!
I really recommend you give his music a listen - it's great stuff.
Thanks
''''''''
To my brother who helped mock up some map designs which I referenced during
actual map creation.
Also, rock on Dieselboy, my wpm seems to have a positive relationship with your DnB :)
To all the developers of the open-source and free software tools and libraries
I made to use this. Some of these are, in no order of importance:
* Blender - I used this for the majority of the gfx
* Gimp - Although not heavily used in this game, thank you
* SDL - To all those involved, thanks for all your hard work on making such an amazing library
* Xiph - For pushing forward open codecs :)
* OpenGL - I can do a heck of a lot more thanks to you all!
* mingw - For making porting to win32/64 a liveable experience ;)
* Most of all, thank GNU, the FSF, Linux(Slackware), and many more!
Also thanks to the makers of the fonts I used in this program!
,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
Final Notes
````````````````````````````````
This entire engine was developed on a low-powered workstation running
Slackware Linux. The system specs for those interested are at
https://kya.exoss.net
There may be bugs in Windows, especially with the Editor features. Let me know
if you find any - and how they happened - and I'll try my best to fix them.
Much of the engine needs to be fixed up, as perfect design was scrapped at
points due to time constraints. In particular, the fact that there are three
distinct Entity data forms - one for the map editor, one for the file format,
and one for live. This is true for some of the other heavily used data types
as well. Furthermore, the physics model is all sorts of hacked, relying on
magic numbers rather than substantial numbers (friction, inverse mass
relationships, etc.).
Also, every image frame is loaded as an SDL surface. This takes up an enourmous
amount of room and should be optimized away (it accounts for majority of the
RAM usage). Sprites should be stored in spritesheets either premade or on the
fly. Only the current set facing is stored on the graphics card - the textures
are loaded and unloaded as the facing changes. This works fairly well, however
it could also be optimized (surfaces could be freed for the most heavily used
frames - ones that would be stored on the card until map unload or similar).
be6a4ba35f