No.91
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.
~ABOUT~
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.
~FEATURES~
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.
~LINKS~
Website:
http://tileengine.org/Official IRC:
http://webirc.datnode.net/?channels=tsunagariSource Repository:
https://github.com/omegasdg/TsunagariAlphaP4-R4 Source GIT Tag:
https://github.com/omegasdg/Tsunagari/tree/AlphaP4-Rev4AlphaP4-R4 Windows Binary:
http://omegasdg.com/files/Tsunagari-AlphaP4-Rev4-Bin.zip No.147
Any chance it will be Android or PSP compadable?
No.279
>>147I doubt it would support PSP, but I think we could modify it to work on the Android. Not gonna happen with the first release though.
No.1692
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.
~LINKS~
Alpha Preview Release 3 Source:
https://github.com/omegasdg/Tsunagari/tree/AlphaP3-Rev1Alpha Preview Release 3 Windows Binary:
http://omegasdg.com/files/Tsunagari-AlphaP3-Rev1-Bin.zip No.1693
>>1692I TESTED IT IM SO COOL GUYS LOOK AT MEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
im glad to see progress on this. so super glad. so excite.
No.1694
This thing looks better and better with every release, nice work.
I wanted to write my own tile engine for my fangame, but now I started to consider using Tsunagari instead.
Keep up the good work, and don't be disappointed by the lack of responses, there are only a few programmers around this board.
No.1695
Oh, and a little feedback: it would be nice to disable diagonal player movement by default.
No.1753
>>1695That's actually in the TODO; we only want it enabled in roguelike mode.
No.1782
We have switched to a faster release schedule, with multiple "revision" releases per Alpha. Updates should come faster now.
No.1784
>>1782Awesome. (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?
No.1801
>>1784We use Boost for shared pointers and the client.ini parser, as well as a few convenient functionalities.
No.1818
Can we post requests here?
Some stuff that I'd really like to see that RPG Maker doesn't have:
-8-directional sprites
-separate "walking" sprites and "running" sprites applicable to a character
-more than 5 speed settings
-more than 2 (or 3 in XP) tileset 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)
-optional pixel-based movement (I mean where you can make it so the player can walk without being bound to a grid.)
-multiple parallaxes with transparency support
-foreground parallaxes (for fog and shadows and stuff)
No.1962
>>1818> 8-directional spritesIf 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 characterLater you'll be able to use any number of additional custom sprite frames.
>more than 5 speed settingsYou 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 layersWe 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 supportI'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.
No.1980
>>1962A 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.)
No.1981
Checked the roadmap, and noticed that you'll change the scripting engine from LUA to Python.
But why Python?
If you absolutely must change, will you consider using Ruby instead of Python?
(The scripting system of RPG Maker XP (and VX) is based on Ruby. And, by the way, why are you not satisfied with LUA?)
No.1988
>>1981I 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.
No.1989
>>1980I like this idea. We'll probably do something like that.
No.1990
>>1981Lua 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.
No.2000
>>1988>>1990Alright 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.
No.2002
uh, I don't mean to push you guys or anything, but do you have a temporary date at least of when you will have the beta release?
I'm currently working on a fangame, and I want to know if I should continue to work in rpgmaker, or wait for tsunagari….
Just wondering…
No.2004
>>2002Sorry, unfortunately, it's too early for a Beta time estimate. Even once we hit beta, it may be a little while before we get Tsunagari to a state where it's friendly enough for use by anyone except us.
No.2005
>>2004If I had to give an extremely rough estimate, I'd say less than a year.
No.2006
>>2000Squirrel and AngelScript look interesting and we're going to investigate them. However, most likely we'll still use Python.
No.2013
>>2008We jumped into Lua solely because it was the most popular. Then we discovered that it secretly sucked in a lot of places. We're most comfortable with Python, but we're going to seriously consider multiple alternatives so we don't make the same mistake again. It's very hard to switch scripting languages once you've started integrating them.
No.2087
After considering some alternatives, my partner and I have decided to use Python 2.X as Tsunagari's scripting language, citing, among others, the following reasons:
* We have a personal preference for python.
* There's a boost library which should make Python embedding easy.
* AngelScript was attractive, but it didn't have dynamic typing, something which we absolutely want.
* Squirrel's Java-like syntax was a turn-off for us.
* Like Lua, Squirrel is a stack-based language, something which caused many of the problems that turned us away from Lua.
* I believe that Python will be easier for beginners to learn than purer C-type languages such as AngelScript and Squirrel.
We'll begin redesigning the scripting interface for Python after the release of Alpha 4 Revision 1.
No.2097
>>2087How big is Python when compiled in release mode?
No.2111
>>2097The only thing we didn't like about Python is that the 2.6/2.7 dynamic libraries are about 1mb in size.
No.2406
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).
~LINKS~
Alpha Preview Release 4 Rev-1 Source:
https://github.com/omegasdg/Tsunagari/tree/AlphaP4-Rev1Alpha Preview Release 4 Rev-1 Windows Binary:
http://omegasdg.com/files/Tsunagari-AlphaP4-Rev1-Bin.zip No.2422
Works great, I see you've fixed the subpixel rendering glitch.
And now, a little off, but can you tell us a bit more about your team? Where are you from? And do you have any programming background?
Sorry about this, I'm just curious about the people behind this project. (Back in the times when I started to write my own tile engine, it took me forever to figure out some of the stuff you've implemented in a few weeks, so you either very talented, or have some coding background.)
No.2428
>>2422We'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.
No.2524
>simple
>powerful
>FOSS
>low level stuff is C++, scripting uses Python
>portable to Windows, Mac and Linux, potential iOS support (GOSU supports this)
>developed with YN-like games in mind
This is just what I wrote down as my requirements for a game engine for my project. I'm keeping a REAL keen eye on this one!
No.2528
>>2524Wow, I thought I'm the only one here who doesn't use RPG Maker.
No.3571
We aren't dead yet.
No.3588
Too bad.
No.4145
Just thought I'd give this thread a baumpu and ask how the engine is coming along.
No.4168
can't wait 'til this engine is ready to be finally used for real /fg/s.
No.4224
>>4145Development 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.
No.4228
>>4224If 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).
No.4229
>>4228MinGW 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.
No.4230
>>4229Then 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.
No.4954
Finished more of the Event Scripting API, and vastly improved the ways in which you can move between areas. We've also refactored and rewritten some stuff. Meeting with Paul again tomorrow to continue.
No.4985
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 No.5228
Hey everyone,
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 No.5948
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.93The 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.
~LINKS~
AlphaP4-R2 Source GIT Tag:
https://github.com/omegasdg/Tsunagari/tree/AlphaP4-Rev2AlphaP4-R2 Windows Binary:
http://omegasdg.com/files/Tsunagari-AlphaP4-Rev2-Bin.zipP.S. Try hitting the use button (space) on a few things around the testing world, including and especially inside the house.
No.5953
>>5948The timing could not be better, at least for me. I just finished my game and haven't started on a new one. I shall give this engine a try!
No.5954
Just read the roadmap. Guess it's gonna be a while until there's any sort of user interface.
Anyway, a feature I would like to see implemented is the option to turn on or off pixel based movement.
Also, is there some kind of screen effects planned? Like.. blur, distortion, light effects. That kinda stuff. Probably not the first priorities, but y'know, I'd like it.
No.5955
Pixel movement would be the tits.
No.5957
>>5953I'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>>5955That'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.
No.5959
I do have one pressing question—why multiplayer?
The Gmod toybox-esque third-party content downloader seems like a sweet idea, though; makers can release new worlds as free and optional DLC for the sillier/more fun-oriented games, and more serious games can update over the Tsunagari engine.
No.5969
>>5959Why 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".
No.5977
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.
~LINKS~
AlphaP4-R3 Source GIT Tag:
https://github.com/omegasdg/Tsunagari/tree/AlphaP4-Rev3AlphaP4-R3 Windows Binary:
http://omegasdg.com/files/Tsunagari-AlphaP4-Rev3-Bin.zip No.6248
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/~LINKS~
AlphaP4-R4 Source GIT Tag:
https://github.com/omegasdg/Tsunagari/tree/AlphaP4-Rev4AlphaP4-R4 Windows Binary:
http://omegasdg.com/files/Tsunagari-AlphaP4-Rev4-Bin.zip No.6251
Would anyone here make something with Tsunagari at this stage if I finished the documentation?
No.6252
>>6251I'd love to try to make something.
No.6282
>>6251Yes, definitely, please do.
No.6296
>>6274Entities 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.
No.6312
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:
*
http://tileengine.org/docs/sphinx/index.html No.6313
>>6312I 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!
No.6318
Building on OS XRequirements:
- git
- 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 [4] directories:
Application.template
Frameworks
Headers
Libraries
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 ->
Build. 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.
No.6434
http://tiny.cc/5vaolwI'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.
No.6483
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.
No.6530
>>6483I 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.
No.6675
Not dead yet.
You may not see a whole lot of activity on this until around winter break. The afforementioned Python scripting subsystem bug will require some major refactoring. We need to implement Python namespaces, and a bunch of other changes.
I imagine it will take several days of man-hours to get Python working correctly. We won't have that kind of time until the break.
No.7102
More to come this April.
No.7749
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).
~LINKS~
AlphaP4-R4 Source GIT Tag:
https://github.com/pariahsoft/Tsunagari/tree/AlphaP4-Rev4AlphaP4-R4 Windows Binary:
http://pariahsoft.com/files/Tsunagari-AlphaP4-Rev4-Bin.zip No.7753
>>7749wow, 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.
coughkickstartercoughsteamgreenlightcough
No.7754
>>7749>llc>real companyo k you have fun there sei
No.7756
>>7754Wow rude. Even Amazon is an LLC.
No.9129
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.
No.12158
Necrobump because I made good on
>>9129.
See
>>>/ig/638
