Chrono Compendium
Zenan Plains - Site Discussion => Chrono / Gameplay Casual Discussion => Topic started by: neo-fusion on February 06, 2010, 10:42:10 pm
-
Ok ... I have an idea...
My idea? Make Crimson Echoes a reality.
You guys surely still have the script and I know there is more than enough people on here willing to put down the talent and hard work. So why not break away from everything that relates it to Chrono Trigger and make a game? You could possibly get it released on a console if it was to turn out good enough.
Hell, I am just throwing it out there and it doesn't seem like a bad proposition to me.
-
Making a decent game engine takes a good deal of work. Making all of the art resources needed for a complete game is several times more work.
Even with the talent here, it'd take years to make your proposition a reality. If you're willing, then by all means, start building the game engine and editing tools and making the art. Once that's done, we'll plug in the script and pull together some good music.
That's the realistic answer. Anyway, by all means, give it a shot.
-
I'm looking into Ruby 1.9 to mash together with C into a game toolkit. I heard RPGMaker XP and VX are notorious because of Ruby scripting, but I read 1.9 is an adoption of a more efficient processor made by third-party and runs faster. Version 1.9 came out just recently, RPGMXP/VX likely uses the older engine.
I'm doing some research about Ruby 1.9 being the logical choice. Ruby has a very simple C embed API, whereas Lua is already robust but has what Neo called "evil ass code." If Ruby 1.9 is faster a good deal, that will be my choice. I really don't want to bust my brain trying to tame Lua's beast of an embedding process when there's a simpler but just as good alternative.
See, with Ruby's embed process, it's simply initializing the engine, defining the stuff you need, and... that's it. After that, you fiddle around and then close the engine when your program exits.
Lua is a much tougher ordeal. You have to define stacks, metatables, tables, and push and pop data from the stacks by an integer index. It's a nightmare! Don't believe me? Read chapters 24-29 of http://lua.org/pil/ and pick a corner of the room to curl up an sob in.
-
Making a decent game engine takes a good deal of work. Making all of the art resources needed for a complete game is several times more work.
Even with the talent here, it'd take years to make your proposition a reality. If you're willing, then by all means, start building the game engine and editing tools and making the art. Once that's done, we'll plug in the script and pull together some good music.
That's the realistic answer. Anyway, by all means, give it a shot.
Ugh... game engines... graphics engines....
I'm currently extremely pissed at Microsoft for their failure to make directx even logical, if not just understandable. The directX functions in c++ are the dumbest pieces of code I think I've ever seen. So many damn unneccesary complexities.
-
Ugh... game engines... graphics engines....
I'm currently extremely pissed at Microsoft for their failure to make directx even logical, if not just understandable. The directX functions in c++ are the dumbest pieces of code I think I've ever seen. So many damn unneccesary complexities.
Do what I do then, and use a library that acts as a layer. Allegro ( alleg.sf.net ) is good for 2D and 3D to some extent, Version 5 is a rewrite that finally eliminates the Atari-ness of it. There's also OGRE ( ogre3d.org ) for 3D games/programs. They act as a simplified layer over DirectX and OpenGL.
-
Ugh... game engines... graphics engines....
I'm currently extremely pissed at Microsoft for their failure to make directx even logical, if not just understandable. The directX functions in c++ are the dumbest pieces of code I think I've ever seen. So many damn unneccesary complexities.
Do what I do then, and use a library that acts as a layer. Allegro ( alleg.sf.net ) is good for 2D and 3D to some extent, Version 5 is a rewrite that finally eliminates the Atari-ness of it. There's also OGRE ( ogre3d.org ) for 3D games/programs. They act as a simplified layer over DirectX and OpenGL.
Whats the difference in performance? Minor? none?
hrmmm... wonder what Pixel used when he made Cave Story...
Well.... hmm. Maybe. Thanks for the info.
I'm going to be working on a platformer in the near-to-far future. The only reason I haven't started now is because of DircetBitch and the fact I do not know any Winsock functions yet (yes, its going to be an online-capable platformer. Got a problem? 2F***N bad)
Edit: I really do want to learn some graphical form of directX though..
...not because I like directX, but because I want to write my own graphics library and engine, rather than using someone else's. I mean, I could go as far as to disassemble directX and figure out how it works, and rewrite it to my own specifications... but thats just a little too far for me...
-
How the heck can you disassemble DirectX? It was written in C, which means it's pretty difficult to disassemble.
-
How the heck can you disassemble DirectX? It was written in C, which means it's pretty difficult to disassemble.
Considering everything compiles into Binary, you can disassemble anything. Assembly IS binary, in words.
If I were to disassemble (or more appropriately, decompile) anything from DirectX it would be to figure out how it reads and writes to the graphics card. Or sound driver.
-
I've never really been into Game Development seeing as scripting has never been my forte. However, what I CAN do is give Crimson Echoes an outstanding finale where it left off: The reign of Cedric Guardia, a fearsome Arbiter of the Flame. And what I CAN do is still in development; an unofficial OVA of Crimson Echoes as an animated movie. :lol:
-
lol tushantin you are the man! What program are you using?
Oh and this was a proposition for the guys here.
Go contact EA with a script and the people you have here willing to do it. Hell, I can't do shit except animate lol.
-
I'm going to try C# and XNA to see if this simplifies gaming. I carefully looked into XNA, and there's open source ports of it for Linux and Mac provided by Mono.Xna. The .NET 3.5 SP1 framework is needed for Windows, which people should have by default if they keep up-to-date. For the others, Mono is a good choice since it's pretty much the only .NET variant for non-Windows.
-
C++ all the way
-
C++ all the way
It's just too burdenous for me... I'm liking C# more
-
C++ all the way
It's just too burdenous for me... I'm liking C# more
I would honestly go Python if I didn't fear that it was slower.
Which is an unbased fear, at minimum, because I really don't know.
-
The question isn't whether Python is slower than C (it is, if I correctly recall the numbers in the last batch of benchmarks I looked at), but whether the slowdown involved is significant enough to matter and whether you're willing to embed a bit of C into the Python if you're faced with something time-critical that can't be handled any other way.
(I am allergic to C#, because I have yet to encounter a C# application that will actually run under Mono--Windows devs generally don't care about people running other systems, and no one else seems to be interested in using C#. Screw that. There are dozens of other languages out there that don't have that problem.)
-
The question isn't whether Python is slower than C (it is, if I correctly recall the numbers in the last batch of benchmarks I looked at), but whether the slowdown involved is significant enough to matter and whether you're willing to embed a bit of C into the Python if you're faced with something time-critical that can't be handled any other way.
(I am allergic to C#, because I have yet to encounter a C# application that will actually run under Mono--Windows devs generally don't care about people running other systems, and no one else seems to be interested in using C#. Screw that. There are dozens of other languages out there that don't have that problem.)
Sorry, mate. I develop for windows, but thats only because:
A: I've just started
B: I don't really know how to handle developing for other OS's
I don't really like how the windows development is set up, but its the only thing i know. I wish there was a simple "All encompassing" format that could be used.
Or perhaps a program who's installer determined which sets of code to compile and use, dependent on the OS currently installing.. =/
I assume C++ works on (almost) all OS's?
-
The simplest way to develop for multiple platforms if you're running Windows is to use an interpreted language--Python, Perl, Java, what-have-you. It is possible to write platform-locked code in languages like this, but it's more difficult. Of course, there's a tradeoff in terms of efficiency--interpreted languages are a bit slower for most operations, on average.
C++ can be compiled for multiple platforms, provided that appropriate precautions are taken (in particular, you need to make sure any libraries you use are available for all the relevant platforms). I believe the switches for platform-specific code normally take the form of preprocessor directives. However, I never liked C or C++ very much, and haven't coded in either in years, so others here could probably give you more precise information about the appropriate syntax (it's very likely the same for both languages--C++ is a syntactic superset of C anyway).
One thing you want to do, if you're developing on Windows and want your code to run on other platforms, is be very cautious of any tool or library that's provided by Microsoft itself, because they have a vested interest in not letting your code run elsewhere. Seek out open-source or at least third-party alternatives where you can. This means using OpenGL or a wrapper library like Allegro rather than DirectX, and similarly, if you really want to develop in C#, use Mono (yes, you can get it for Windows, too) rather than Microsoft's .Net framework.
-
(In all fairness, I should probably add that I am both a Linux user and something of a grouch. ;P )
-
Yeah, preprocessor directives... never really knew what all of them did, just know a few of em, like #include, or #pragma once (which I only kindof understand, anyways).
Honestly, I hate Java with all of my soul.
But just as much as I hate Java, I hate Microsoft Visual Studio. It is NOT a good compiler, HOWEVER it IS the one I know.
and, I am going to be using Allegro. Or at least, I'll try to.
So I will also figure out how to code for multiple platforms later on =D
And I will!
EventiallY!
-
Visual Studio is a fantastic IDE.
-
I did my homework. XNA has a Mono counterpart, so I went ahead and installed the SDK.
-
Honestly, I hate Java with all of my soul.
Hmmm... So was it the rigid syntax, the interpreter startup time, the horribly inefficient IO package, the lack of genuine native GUI support on most platforms without installing a third-party package, the uncontrollable garbage collector that sometimes lets you run out of memory for no reason, Sun's abstruse licensing terms, the multimedia support that's several times harder to use than it needs to be, the CORBA and other junk that only a minority of programmers will ever need folded unremovably in with the main distribution, or some other quirk that I've forgotten that drove you 'round the bend? (Yeah, Java programmer here--I've forgotten more of the bad and ugly things about the language than you ever want to know.)
I hate Microsoft Visual Studio. It is NOT a good compiler, HOWEVER it IS the one I know.
Visual Studio is an IDE, not a compiler (well, okay, you'd find a compiler of some sort if you dug deep enough into its guts, but it's only a very small part of the package). I can't speak to its quality or lack thereof--when I was on Windows, I either favoured Borland IDE software or lightweight syntax highlighter + compiler packages, depending.
and, I am going to be using Allegro. Or at least, I'll try to.
A reasonable choice--I know Allegro is available for Linux, anyway. Don't know about OSX.
-
great idea neo-fusion.
i know nothing about programming or graphics but i compose hell alto of music and my favorite kind of composing is game music.
i have some examples so if u r really in to it tell me and ill upload them.
again, great idea :)
-
I KNOW I'm going to regret this in the near future, but...
We all seem to be quite knowledgable in the programming industry. Perhaps we should collaborate and work on something...
Not chrono related, of course, but...I mean, this community has EVERYTHING: The designers, the coders, the graphical artists, the conceptual artists, the musically talented...
And then we have Allegro, which can pretty much remove the need for us to write an engine.
But seriously, look at what we have. And look at the progress that this community has already made (CE was 98% or more complete!), a sound example of how strong our wills combined can be.
But... who's going to take part, and where will we start?
Hmm... I am currently working on a storyline of my own, for my own project, but YOURE NOT USING it. its mine. alone.
And so, we would be starting at almost scratch (allegro was already done for us, so not a complete from scratch start).
Who's with me?
-
Allegro is available for OS X, even iPhone. CMake ( http://cmake.org ) will help you generate the necessary files. I advise anyone who uses Allegro to use version 4.9 instead of 4.4 as it's a complete rewrite and not backwards compatible, and to get these first though (OS X users can use MacPorts ( http://macports.org ) to install these):
CMake - see above
DirectX SDK (Windows only, links to Feb 2010 release) - http://services.social.microsoft.com/feeds/FeedItem?feedId=76dc8ff9-e34c-4be6-9414-d47e3dd34317&itemId=9baee178-7a6e-4752-b7c6-ca3ee5ec1f77&title=February+2010+DirectX+SDK&uri=http%3a%2f%2fwww.microsoft.com%2fdownloads%2fdetails.aspx%3fdisplaylang%3den%26FamilyID%3d2c7da5fb-ffbb-4af6-8c66-651cbd28ca15&k=Jg8IObKD5Pdqf4Ru3infZkXLetdjn19PLVx7tOuD%2fF4%3d
ZLib - http://zlib.net (VC++ users extract the source .zip as zlib, not zlib-1.2.3), LibPNG needs this
LibPNG - http://www.libpng.org/pub/png/libpng.html (VC++ users, extract this to the same folder as zlib is in, so that the SLN file will detect zlib), This is needed to use PNG images, a really good format I think
LibJPEG - http://ijg.org (rename jconfig.xxx to the appropriate extension, VC++ users need to rename makejvcp.vc9 and makejsln.vc9 to jpeg.vcproj and jpeg.sln), Needed for JPEG image use
FreeType - http://freetype.sf.net - needed for truetype font addon
LibOGG - http://www.xiph.org/downloads/ Dependency for the Allegro Vorbis addon
LibVorbis - http://www.xiph.org/downloads/ Needed to use .ogg audio files
LibFLAC - http://www.xiph.org/downloads/ Needed to use FLAC audio files
OpenAL (OSX has this by default, won't work with Windows) - http://kcat.strangesoft.net/openal.html
PhysicsFS - http://icculus.org/physfs - Needed for PhysicsFS addon, let's you read data from ZIP/HOG/7Z/etc... archives
To install:
Windows users: In your environment variables (System control panel) make the following entries:
Name: LIB
Value: %DXSDK_DIR%\Lib\x86;%LIB%
Name: INCLUDE
Value: %DXSDK_DIR%\Include;%INCLUDE%
Visual Studio 2008 Solution - In command prompt, type: cmake -G "Visual Studio 9 2008"
Xcode Project - In Terminal, type: cmake -G "Xcode"
Unix Makefiles - cmake -G "Unix Makefiles"
MinGW Makefiles - cmake -G "MinGW Makefiles"
Be sure to check the generated CMakeCache.txt file after running this, to make sure it was configured correctly. Rerun the above corresponding CMake command to update it if you make any changes.
-
Honestly, no, I'm not installing all of that to use Allegro. Im just going to be using their base drawing and sound functions.
That is, if I can even get the f***ing thing installed.
The install guide is too damn complicated to understand.
****! I forgot to turn in my comp sci homework, which I DID!
****in figures
-
Use straight C or a subset of C++ (no templates, no STL, no boost, maybe just a little rtti) with SDL for input, windowing, and audio, OpenGL for rendering (even if it's "2D", but 3D backgrounds with 2D sprites might be an interesting thing to try with a fangame), then create scripting hooks for all the functionality in Javascript using Spidermonkey or Lua using their standard implementation.
If you're an experienced programmer, you can learn C very quickly. This means everyone can contribute. I can even make an installable package for Windows users who want to contribute, where they just install our development tools and start coding and testing. Subversion for version control would be easiest in our case.
Considering we're coding the engine to be just like Chrono Trigger's (albeit, with a few possible improvements here and there), we don't care about flexibility and the complexity of it isn't really that great. Portability and a lightweight code base with few dependencies is more important in our case.
That's because we know pretty much what we want the engine to do.
What we really need to focus on is making powerful, integrated tools for building maps and scripting events and battles. Writing such tools in something like Python would be best, where we can quickly adapt and improve them to suit our needs.
That's my two cents. I bet this continues on as a debate over what languages and tools everyone should use though.
-
I would be very, very surprised if even a significant subset of the programmers on the Compendium ever agreed on a preferred language and toolset--programmers elsewhere hardly ever do! :lol:
Seriously, I dislike C (and, by extension, C++, which inherited most of its problems) because I find it's much more work than any of the other programming languages I've worked with. If you work in C, the final code will take less machine time to run, but in my experience it takes more time--sometimes a lot more--to write and debug it unless you're already a fairly good C programmer, because the language does so little of the obvious, purely-mechanical error checking on its own that you might as well be working in assembler. I'd rather waste the computer's time by using a less-efficient language than waste my own on doing my own garbage collection and array-bounds checking (unless I'm trying to write something where good execution time is absolutely vital, like a device driver). Others' mileage may vary. ::shrug::
(I discovered last night that the last version of Allegro for which Gentoo has an ebuild is 4.2.2--there's a version-bump bug filed against 4.4, but no one seems to have done anything about it. Hmmm.)
-
I highly advise against learning 4.4 or older if you're a beginner. 4.9 is a non-backwards-compatible rewrite that will become 5.0 and is preferred that all beginners learn that instead. 4.4 has a lot of old code that isn't used today -- support for FLI sprite format, and the Atari graphics engine specifically.
-
I would be very, very surprised if even a significant subset of the programmers on the Compendium ever agreed on a preferred language and toolset--programmers elsewhere hardly ever do! :lol:
Seriously, I dislike C (and, by extension, C++, which inherited most of its problems) because I find it's much more work than any of the other programming languages I've worked with. If you work in C, the final code will take less machine time to run, but in my experience it takes more time--sometimes a lot more--to write and debug it unless you're already a fairly good C programmer, because the language does so little of the obvious, purely-mechanical error checking on its own that you might as well be working in assembler. I'd rather waste the computer's time by using a less-efficient language than waste my own on doing my own garbage collection and array-bounds checking (unless I'm trying to write something where good execution time is absolutely vital, like a device driver). Others' mileage may vary. ::shrug::
(I discovered last night that the last version of Allegro for which Gentoo has an ebuild is 4.2.2--there's a version-bump bug filed against 4.4, but no one seems to have done anything about it. Hmmm.)
It's not about what you prefer -- it's about what gets the job done. A simple engine written in straight C would be easy to make completely scriptable in Javascript or Lua and would be easy to port to all sorts of platforms, and we can still use a garbage collection and abstract vector/array type library to make up for the language deficiencies. Besides, runtime debugging tools have gotten so good that finding problems in your C code isn't very painful at all in my opinion, unless you're working on large, complex projects. The key is to test and debug your code as you write it.
Considering once the engine has all of the kinks worked out, most of the real coding will be done in the scripting language used by the game, the language used for implementing the actual engine doesn't have to be anything fancy and the game engine itself should not be very large or complicated at all.
Anyway, I'm going to take this as meaning nobody here is a real C programmer or all that interested in becoming one for a single project. It doesn't matter either -- I really don't expect to see anything real come out of this discussion.
EDIT: And just so you know, if we were all talking personal preference, I'd say to code the game engine and all of its tools in Common Lisp. That'd be my preferred way of doing it.
-
It doesn't matter either -- I really don't expect to see anything real come out of this discussion.
Nor do I, unless one of the other posters in this thread goes ahead with a solo project first--in which case anyone else who decides to contribute later on will be stuck with his/her/its choice of languages, even if that choice is Forth or MIPS assembler or Ook! .Net or something equally demented.
(Censoring the rest of the reply I considered because there's no point in starting a language war here--I've seen them before, and no one ever wins them.)
-
I heard Lua 5.1 implements an incremental garbage collector. Before WoW Burning Crusade, WoW used Lua 5.0 and a lot of players were complaining of slow UI addons.
-
hmm. I will be writing anything I am doing in C++.
Which is why I don't expect anything to start from this either.
-
Tomorrow I'll put up a link to prebuilts for Allegro that I'll upload to 4shared, for use with VC 2008
-
It doesn't matter either -- I really don't expect to see anything real come out of this discussion.
Nor do I, unless one of the other posters in this thread goes ahead with a solo project first--in which case anyone else who decides to contribute later on will be stuck with his/her/its choice of languages, even if that choice is Forth or MIPS assembler or Ook! .Net or something equally demented.
(Censoring the rest of the reply I considered because there's no point in starting a language war here--I've seen them before, and no one ever wins them.)
*cough*
-
@Lance VII: Since you started work on your game long before this thread came into being, I don't think we need fear influencing you in any way whatsoever. 8)
-
Alright, here's my compiled Allegro SDK, built with Visual C++ 9 (2008). All libraries have compiled statically with no debug info -- because who likes a bunch of DLLs anyway? Please be sure to use the most recent DirectX SDK, otherwise you cannot compile anything.
Comes with:
- LibPNG 1.4
- LibJPEG 8
- PhysicsFS 2
- LibFLAC 1.2.1
- ZLib 1.2.3
- LibOgg 1.1.4 (SSE2)
- LibVorbis 1.2.3 (SSE2)
- FreeType 2.3.12 (Multithreaded)
- Allegro 4.9.17 (includes all addon libraries)
Download (2.8 MB, took out Lua, see below): http://www.4shared.com/file/223064636/4f3f7dc5/allegro_4917_vc9.html
EDIT: Here's a useful package for scripting, again for VC9, static libraries, contains:
- Lua 5.1.4 (interpreter and bytecode compiler executables included)
- LuaBind 0.9 (multithreaded, this makes Lua embedding a ton easier!)
- Boost 1.42 (multithreaded, headers only, libraries unneeded, Luabind needs it)
Download (10.3 MB): http://www.4shared.com/file/221713239/7de40db0/luabind_09_vc9.html
-
Well, for my own purposes, I just finished writing the majority of an engine. I am still lacking the Room Handler and Generator (stores / creates all the objects in a room), sound, and networking. I am still contemplating how to do room handling. the other 2 I just havent gotten into yet.
So I used what I had to write a "pong" style game. Its very simple, no menus and such, nor a Win or Lose screen.
Currently, it is hardcoded for 30 frames per second and a 320 x 240 screen resolution, but that can be changed.
Anyways, written with Allegro, many thanks to the people there, but also means it *should* be compilable on other systems. Compiled on Win 7. Don't really intend on compiling on other systems (cmon, its a pong game. Its not worth it) but for later, final project, I will probably ask for others to help me compile on their systems.
simplepong.zip (http://host-a.net/cheatscanner/simplepong.zip)