File: 1317004017266.png (2.71 KB, 128x128, 1310067574591.png)
This is the new thread for my Tsunagari Game Engine. As development continues, I'll post updates and new downloads in this thread. You can also see progress on the official website, linked below.
Tsunagari is a tiling game engine inspired by the cult classic game Yume Nikki. It is intended as an open source alternative to the popular proprietary RPGMaker game development suite that the original and most fangames were/are written on. The initial focus is support for all of the features of Yume Nikki, and beyond that it strives to become a fully-featured 2D game development suite. Tsunagari is written in C++, using the Gosu framework.
Tsunagari will be a comprehensive game design suite for singleplayer 2D games. The engine will support several styles, such as roguelikes, and old console-style RPGs. Multiplayer support is planned for the second stable release. Tsunagari allows Python scripting for the event system, and for additional custom functionality. As a suite, Tsunagari aims to allow as much game variation as possible without direct modifications to the engine source code. Game design will require manual file editing during the Alpha and Beta phases, but a game editor suite will be shipped with the first major release.
Official IRC: http://webirc.datnode.net/?channels=tsunagari
Source Repository: https://github.com/omegasdg/Tsunagari
AlphaP4-R4 Source GIT Tag: https://github.com/omegasdg/Tsunagari/tree/AlphaP4-Rev4
AlphaP4-R4 Windows Binary: http://omegasdg.com/files/Tsunagari-AlphaP4-Rev4-Bin.zip
File: 1321777683808.png (14.25 KB, 320x320, 2011-11-11--1321055713_640x480…)
The wait is over! All known bugs and issues have been fixed, and Tsunagari Tile Engine Alpha Preview Release 3 "Kurotsuki" has been released. This release adds several new features, such as tile layers and looping areas, as well as some general engine improvements and a sexy new testing world.
The new release can be downloaded below.
Alpha Preview Release 3 Source: https://github.com/omegasdg/Tsunagari/tree/AlphaP3-Rev1
Alpha Preview Release 3 Windows Binary: http://omegasdg.com/files/Tsunagari-AlphaP3-Rev1-Bin.zip
I TESTED IT IM SO COOL GUYS LOOK AT MEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
im glad to see progress on this. so super glad. so excite.
Awesome. (And I see you already done disabling diagonal movement in RPG mode.)
By the way, what are you exactly using the Boost libraries for in this project?
>>1818> 8-directional sprites
If you mean diagonal movement sprites, we have that. It's just disabled in the current testing world.>separate "walking" sprites and "running" sprites applicable to a character
Later you'll be able to use any number of additional custom sprite frames.>more than 5 speed settings
You can set the player's default speed to anything in their descriptor file. The speeds for players and entities will be dynamically modifiable with event scripting.>more than 2 (or 3 in XP) tileset layers
We support infinite tilesets and graphical layers.>priority swapping (so you can make someone walk under a bridge, AND walk over it without changing maps or using an event trick or something)
We will support movement on multiple layers of the same area in the next release, though an event bound to a tile (for example, an event bound to the stairs tile) will be required to move between layers. Very simple to do, and you can have an event automatically bind to every instance of a certain kind of tile.>optional pixel-based movement (I mean where you can make it so the player can walk without being bound to a grid.)
"Zelda-like" movement is planned for Beta.>multiple parallaxes with transparency support
I'm not sure exactly what you mean, but all tile layers will support transparency.>foreground parallaxes (for fog and shadows and stuff)
We're going to add "overlays" (transparency-supporting layers that can float and move over or under the map) which can do this. We'll also be adding support for GLSL shaders.
Looks like we have all your concerns covered. I didn't realize exactly how shitty RPGMaker is.
A lot of the stuff mentioned you CAN do in RPG Maker, but it's stupidly complicated to implement.
Will the engine also have more camera control than RPG Maker? (Like being able to lock the camera or adjust how close to the edge of the screen the player must be for the camera to scroll.)
I don't want to use Ruby because its structure is too different from most C-like languages, and that could make it difficult for people with previous coding experience to learn quickly. Basically, I have nothing against the language itself, but I don't think it will be friendly enough to the end user.
I'm going to let my partner explain why we aren't using Lua anymore.
Lua has a number of problems that make it hard to develop with. It isn't inherently object oriented, and although you can make it mimic this behavior, it exposes warts in the language. Its stack-based nature makes it hard to debug. Additionally, you can't directly reference your own userdata objects, which is rather painful and leads to messy workarounds.
I don't mean to dismiss the language entirely: it's fast and quite small, but we're looking for something that takes less wrestling to work with.
Alright then, but I still don't get it why did you choose Python.
I used to work with it, and it wasn't that easy, not to mention the size of the library itself (at least back in those days).
In our last project, we used Squirrel, before that, we used AngelScript, I prefer any of them over Python…
But it's just my opinion. Your game, your rules, after all.
File: 1324542093654.jpg (19.06 KB, 219x320, image_3.jpg)
We just released Tsunagari Alpha Preview Release 4 "Akatsuki" Revision 1, under our new and faster release schedule.
This release adds noticeably better input and movement handling, better scaling and tracking for the game window, and layered movement (not reflected in the testing world yet).
Alpha Preview Release 4 Rev-1 Source: https://github.com/omegasdg/Tsunagari/tree/AlphaP4-Rev1
Alpha Preview Release 4 Rev-1 Windows Binary: http://omegasdg.com/files/Tsunagari-AlphaP4-Rev1-Bin.zip
We're a team of two, myself and my partner Paul who on occasion visits #uboachan as Jamer. We're both just hobbyist programmers, though Paul is far more experienced and ends up doing the majority of coding and implementation.
We're both from California, and apart from some college classes we have no formal training in software development.
Our project is stable because we planned out a good deal of it before we started, using structure diagrams. We also have debates on how to design and implement each part of the engine, and this allows us to find design issues and oversights better than a single person could.
File: 1325513833112.png (406.81 KB, 1280x720, vlcsnap-2011-10-16-08h51m23s48…)
Working on a problem with the current code that prevents compiling on Windows. When that's done I'm going to make an Uboachan exclusive early release to show what we're working on.
File: 1326034485580.jpg (148.3 KB, 787x1011, 2f94529f14d564066ca6fddd2d7d7a…)
Unfortunately with our latest changes we're having immense trouble compiling on Windows. There may be a delay of several weeks.
Development is continuing, though a bit slowly. My partner has been busy with school so we haven't been able to work on much lately. However, we're still inching towards the next release. We have added the beginnings of NPC functionality, and basic NPC scripting will be available in the next release, as well as long awaited event scripting capabilities, which are basically finished and just need some touch-ups. Hopefully we can power through it during the next school break.
The biggest hurdle for the next release will be getting the software to work on Windows again. We always have a lot of problems getting Visual C++ to eat our code. We've made some progress in that respect but the code still won't compile, and we need to do more research to figure out why.
If you're running Linux, you can go to the GIT repo and compile the latest code; it always works on Linux. Mac OSX support is planned, but untested so far since we don't have access right now to a Mac OSX computer. Android support will require modifications to our game framework, and probably won't be added until some time after the first stable release.
If it builds with GCC, then why don't use MinGW on windows?
MSVC is just a typical overrated MS software, the so-called "preferred development environment", but in reality, it's a bother most of the time (and neither it's optimization is better than MinGW's).
MinGW isn't really used for production software. Ever. Neither Boost nor our game framework support it. We tried for a long time to get it to work but eventually we had to give up.
GCC is the dominant compiler on Linux. VisualC++ is the dominant compiler on Windows. Most stuff on Windows is built with VisualC++. Even if we could get Tsunagari to work with MinGW, which is very doubtful, we'd still want to support VisualC++ anyway.
Then again, you having a hard time getting MSVC to compile your code…
Back then, we used MinGW (with Eclipse as the IDE), and never had any problems with it, I don't know what gone wrong for you. On the other hand, we were struggling with MSVC. Back then, it was incompatible with basically any libraries we wanted to use, plus you had to distribute a 40-something megabytes of runtime stuff, even if your app was just a "Hello, World!" console application.
MinGW just worked out of the box for us, and all the dependencies were two extra libraries we had to link statically to make it work on Win7, they were about 1 megabyte in size.
File: 1333442123395.jpg (120.47 KB, 567x849, CT-Sailing.jpg)
We're not dead yet!
I met up with my partner yesterday since he's on school break, and we knocked out several bugs, semi-finalized the event scripting API, and started rewriting some problematic code. We're very, very close to the next release.
I should have more updates after our next meeting on Wednesday.
During our final meeting this week, we finished more event scripting, refactored some code, and made layers much easier to use.
I also added stuff to the testing world, and recorded a video of current gameplay.http://www.dailymotion.com/video/xpzd24_tsunagari-alpha-p4-development_videogames
If you've ever made a fangame or used game building software, please help us make Tsunagari better by filling out this short-ish survey.http://bit.ly/JSLs9O
File: 1342060958993.jpg (185.15 KB, 683x688, graduation-hats1.jpg)
Forgive me, it's been seven months, far too long to wait.
We're finally done. We crammed so many features into this release that we took way more than a reasonable time. By the time we realized that, the reasonable time was long forgotten and we were almost done anyway.
This release adds nearly-complete Python event scripting, tons of map building features, simple NPCs, a use button for world interaction, sexy updates to the testing world, a bunch of fixes and improvements, and a whole lot more. For details, see http://tileengine.org/index.php?title=Tsunagari_Tile_Engine#Revision_2_.E2.9C.93
The official documentation isn't finished yet, so it'll be hard to build with. I'm working on it. We'll try to make releases faster this time. As in, every few weeks, if everything works out.
AlphaP4-R2 Source GIT Tag: https://github.com/omegasdg/Tsunagari/tree/AlphaP4-Rev2
AlphaP4-R2 Windows Binary: http://omegasdg.com/files/Tsunagari-AlphaP4-Rev2-Bin.zip
P.S. Try hitting the use button (space) on a few things around the testing world, including and especially inside the house.
I'll try to finish the documentation soon for you guys. Hang in there. Keep in mind that currently your game won't have any text, UI, items, or saves, since we haven't implemented these things yet. Also the interface is very volatile so some things might change that require you to update your game source for a new version of the engine. Even so, we welcome more alpha testers and will try to help you out with your project if you decide to use Tsunagari.>>5954>>5955
That's all in the roadmap. AlphaP5-R3 introduces "Graphical transitions, effects, and GLSL shaders." This should handle all those screen effects. Pixel movement is in beta, once yn-type movement is completely done and polished.
Also, we're already working on the next revision. I'm trying to split up our revisions even further based on the stuff we're currently working on. Next one should fix command line output on Windows, make alert dialogs on Windows when errors happen (for people who don't use the command line), make the escape key do something more sensible, and finish up the rest of the event scripting API.
Why not multiplayer?
Tsunagari was originally planned to be a multiplayer Yume Nikki fangame engine. As the concept evolved, we realized we didn't quite have the experience to make something so complex. That's why it's planned for the redesign.
The word "Tsunagari" actually means "Connection", owing to that original plan. That's why the second release which adds multiplayer is called "True Ending Edition".
File: 1342185077217.png (59.26 KB, 642x503, tsu4R3.png)
It's not a double post! We're on a new and improved, and hopefully lasting release schedule, and just two days after our last revision, here comes another. \o/
Revision 3 adds a pause screen for the escape key, better input tracking, some world development features, and code cleanup. There are also some Windows-specific features for ease of use, and the engine now uses built-in defaults if it can't find an option in client.ini or the command line. See the roadmap for more details.
AlphaP4-R3 Source GIT Tag: https://github.com/omegasdg/Tsunagari/tree/AlphaP4-Rev3
AlphaP4-R3 Windows Binary: http://omegasdg.com/files/Tsunagari-AlphaP4-Rev3-Bin.zip
File: 1343552795331.jpg (37.09 KB, 600x404, happy_people.jpg)
And here's another one. It's been about 2 weeks, pretty good.
Revision 4 adds:
* A new command line handler. (http://wiki.omegasdg.com/index.php?title=NBCL
* Options to halt the engine on certain kinds of errors.
* Improved entity obscuration handling so the player no longer steps on the poor wizard's hat.
* Several improvements that make map/world design a bit easier and more intuitive.
* Code cleanup and various improvements and bugfixes.
* Fixes for some potential licensing issues.
Most of the next revision will be directed towards finishing the rest of event scripting. After that, we may not make any more revisions for a while, as we'll be doing a moderately sized overhaul of the engine. The details are in the roadmap — "Alpha Preview Release 4-5 Interim".
I'm still working on the documentation; the chapter on map editing is about 1/3 done. I'll try to finish that soon so people can play around with making simple worlds. I won't put too much or any effort into documenting event scripting until after it's been semi-finalized in the next release.
The documentation is here: http://tileengine.org/docs/sphinx/
AlphaP4-R4 Source GIT Tag: https://github.com/omegasdg/Tsunagari/tree/AlphaP4-Rev4
AlphaP4-R4 Windows Binary: http://omegasdg.com/files/Tsunagari-AlphaP4-Rev4-Bin.zip
File: 1343709198568.jpg (21.84 KB, 500x400, Well....Shit+_2b0601869e651dc8…)
We'll make a hotfix release within the next couple days to fix the following bugs we missed:
* Entities are drawn one pixel too high.
* The engine doesn't correctly parse for the player_nowalk and npc_nowalk tile flags.
Entities being drawn too high was a false alarm, that's just our sprite sheet.
Documentation for map editing is like 90% done. I'll try to upload the patch today.
File: 1344488479089.jpg (170.34 KB, 500x357, stack-of-books.jpg)
The Tsunagari Official User's Manual now documents the entire process of world authoring, excluding event scripting. This means that there is sufficient information for people to start building game worlds for Tsunagari's Alpha engine.
Event scripting hasn't been documented yet because the next release will make significant changes to the event scripting interface.
The Tsunagari Official User's Manual is available here:
I hope to see a few people make some simple game worlds and play around with the engine. Alpha testers are more important than beta testers.
Our engine is still alpha, which implies instability. It's sure to have bugs, and we want you to help us find them!
File: 1344646533421.png (15.5 KB, 512x512, icon.png)
Building on OS XRequirements
- Xcode + Command Line Tools, which can be downloaded for free from http://developer.apple.com
- Boost libraries* [python and program_options + all the headers]
- A working Gosu.framework — either build your own, or get a precompiled one from http://libgosu.org
- PhysicsFS source from http://icculus.org/physfs/
- The Xcode project -> http://www.mediafire.com/?w6d6vfqsb180ck6* This guide doesn't cover building the Boost libraries. Check the Boost documentation for that.Setup
First, get the source code…
% git clone git://github.com/omegasdg/Tsunagari
% cd Tsunagari
% git submodule init
% git submodule update
Alright, now you have the latest source. Unzip the Xcode files [Tsunagari.xcodeproj, Support/] into your repo.
In the Support directory, you will find 3  directories:
Put your Gosu.framework into the Frameworks directory, the "boost" folder from the Boost download into the Headers directory, and your compiled Boost .a files into the Libraries directory (you did compile them static, right?).Optional: If you want to change your application's icon, you should replace Application.template/Contents/Resources/application.icns here.
Finally, rename the directory you unpacked from the PhysicsFS download to "PhysFS" and place that in the Support directory.The PhysFS directory should contain a bunch of source files and not a single directory. If it does, you've done it wrong.Building
This is the last, and easiest step.
Open Tsunagari.xcodeproj in Xcode, make sure there are no missing files in the sidebar, and hit Product
. If all goes well, you will end up with a Tsunagari.app in your build product directory. This has all the dependencies packaged in, and [I think] should work on all [64-bit] Macs.
File: 1346137658958.gif (332.14 KB, 200x200, animation.gif)
I've developed a random map generator based on a cellular automata algorithm. This algorithm will be used in our technology preview game, "Cave Explorer", now in development. An early alpha of Cave Explorer will be packaged with the next release of Tsunagari.
The game will be an exploration-type, and will allow you to explore massive, randomly generated cavernous structures. Cave explorer is a research project, which will help us to develop the cellular automata technology for eventual use in OmegaSDG's first planned fully-featured indie game, "Broken Places - A Story of Crawling Forward", a roguelike.
This may eventually segue into "Dungeon Explorer", using more sophisticated room/corridor map generators.
The attached image is an animation showing the algorithm at work.
We're about 1/3 to 1/2 finished with the next Tsunagari release. It may take more time because we're beginning a restructuring of the engine code. The details are in the development roadmap.
Well, sorry for bumping this, but I've found a bug in the latest revision. On the test world, when you go to the looping area, there will be horizontal black lines between tile rows when the map is scrolling up or down.
Although I'm using a completely different graphics API for my game, I used to have this same issue, and I fixed it by rounding up the timing stuff (float time_since_last_frame * float scroll_speed) to an integer, and move the camera with that.
Also, this project became over-engineered (I know you're from California, but are you sure you're not German?), by browsing through the code for about a half an hour, it's still not clear what does what. Guys, just don't try to cram in features that probably will be never used by anyone, if I would be you, I'd just try to implement the feature set of RPG Maker 2000/2003.
I think we actually fixed that floating point bug, though we only saw it happen with overlays and not with tiles. Might be your graphics card or the resolution you're using or something. I'd be interested to hear from you if the bug is still there after the next release.
As for the code being too complicated, we know. We started this project by writing out a structure diagram, but it became obsolete pretty quickly after we realized that the engine needed to do more things than what we wrote down, or needed to do them differently. It's this team's first time making a project bigger than a couple hundred lines of code (now around 6000), so naturally it got kind of messy. We're inexperienced.
We've found it's healthier for us to think of Tsunagari 1.0 as a test run for Tsunagari 2.0, which is slated to be a complete restructuring of our code base. (Plus networking code.) Hopefully 2.0 will come out looking prettier.
As far as I know though, everything in the engine has a concrete purpose. If you tell me what things you were confused about, I can point out how they're used.
File: 1348719285259.jpg (88.93 KB, 600x825, 1346644156506.jpg)
It looks like we may have finally figured out the elusive bug that's been holding back progress for a whole month.
We've been going deep trying to figure out why our event scripting system explodes when the same module is imported twice. It turns out that apparently Python is never supposed to import anything twice; subsequent imports are supposed to bind the already loaded module to the current scope without reloading it.
Now that we feel sufficiently like a couple of jackasses, we should hopefully be able to start restructuring our event handling code to do things the right way. Hope for updates soon.
Picture related: it's my fucking face right now.
Status update about last month.
So first off we were able to repair the Python scripting interface, but there's one feature which was lost in repair which needs to be re-implemented before we can mark the fix "done".
Second, we formed a company. OmegaSDG is now PariahSoft LLC. Here are some updated links to the last posted version of the engine. (The main project site is still tileengine.org).
AlphaP4-R4 Source GIT Tag: https://github.com/pariahsoft/Tsunagari/tree/AlphaP4-Rev4
AlphaP4-R4 Windows Binary: http://pariahsoft.com/files/Tsunagari-AlphaP4-Rev4-Bin.zip
wow, congrats for the company, I really, really hope this gets a lot of development since it's kind of an empty niche in the gaming community.
It's been a long time, so I feel I should make one more post here about where Tsunagari has gone.
It's gone. To make a long story short, I feel that perhaps a two-man team like us were out of our league trying to make a do-everything engine by ourselves, as our first project, in C++. Our constantly changing design quickly turned into a spaghetti clusterfuck, to the point that the engine could no longer be modified without a monumental effort.
On the up-side, I think we've both learned an awful lot about designing software. Keeping in mind the mistakes of Tsunagari, a couple months ago I started on a new tile engine, "Driftwood 2D", written in Python with a cleaner and more common-sense design. This new project is quickly approaching the capability that Tsunagari had, growing as much in months as the old engine did in years.
If Driftwood 2D surpasses Tsunagari, I will make a thread about it here.