Syntensity: Razanak

by kripken on 01/09/2010 12:43, 48 messages, last message: 01/19/2010 03:31, 5904 views, last view: 05/18/2024 02:43

We just launched a new game on Syntensity, called Razanak.

Features:
* Co-op gameplay, players vs. the enemies
* Robotic spiders that crawl on the walls
* Doors and keycards, with a semi-nonlinear plot
* 1 huge map
* Boss at the end of the level that is (hopefully) not too easy to kill
* Special areas with unique effects
* New textures, HUD images, cutscenes, etc.

YouTube Video: http://www.youtube.com/watch?v=1M80DN-5Xgk

Screenshot: http://www.syntensity.com/static/screenshot_226138.jpg (more screenshots here: http://www.syntensity.com/toplevel/screenshots/ )

You can get to Razanak from the Syntensity lobby. (Note that you need a recent build, which you can get here: http://www.syntensity.com/toplevel/download/ - btw, better installers are coming soon).

Like all games on Syntensity, you can mod Razanak - make other versions of the existing map, with small or big changes, or make entirely new maps. (If you want to do some modding and need help, I am on IRC, #sauerbraten on QuakeNet, or #syntensity on FreeNode.)

- kripken

   Board Index   

#9: ..

by Nixot on 01/13/2010 18:40

I hate people bitching about Mac releases too and I'm glad you have said that Quin as I thought I was a minority. For the last version of Newcube, the only reply was "Is there a Mac version?" Can you understand how pissed orff I felt? Thank you for bringing this subject to light.

reply to this message

#10: ..

by Nixot on 01/13/2010 18:54

The game was awesome. The graphic quality was superb and truly shows what you can do with Sauerbraten. However, it ran to slow on my 4-year-old computer so I had to stop.

reply to this message

#11: Re: ..

by kripken on 01/13/2010 19:09, refers to #10

@Nixot:

Yeah, I'm not surprised it runs slowly on older machines - this game (unlike the other games we made in syntensity) was really mainly meant for higher-end systems.

- kripken

reply to this message

#12: Message censored by administrator

by Megagun_ on 01/13/2010 23:00, refers to #1

#13: Re: ..

by Megagun_ on 01/14/2010 20:13, refers to #1

Hmm. I guess that previous message was a bit too harsh. Let's try that again. :)

Wakefield, would you mind showing me where you got that data from that more than half of the Cube 2 players are using macs? Because if what you claim is true (which I doubt, severely) it might warrant a change of strategy in some of my own projects.

reply to this message

#14: ..

by abs1nth on 01/15/2010 00:46

i doubt it, look at the official download numbers:

linux 50,053
windows 169,349
mac 67,893

reply to this message

#15: Mac Users

by LeftClicker on 01/15/2010 02:42

While I hate not being able to use these projects -- I am a Mac user -- what really can I do beyond show desire for a Mac version? Suppose I am an end user, and not a smart end user, one who can barely launch Sauer, who knows close to nothing about programming and technical support. What can I do? Right, I think that talking to the developer will make him think supporting my platform will make it more likely for me to see a Mac release.
As for WakeField: while it is likely that there are more Mac users playing Sauer than other FPSes, There are nowhere NEAR half. I just think Mac users like to say "I'm using a Mac" more than PC users like to say "I'm on a PC" =P
== LeftClicker ==

reply to this message

#16: Re: ..

by SheeEttin on 01/15/2010 05:13, refers to #13

No, I censored it in an attempt to head off more off-topic posts (which was partially successful).

SPEAKING OF WHICH.
LeftClicker: You could learn how to compile projects, and then do it.
I don't know about using Xcode, but there is a Mac version of Code::Blocks (http://codeblocks.org) which I use in Windows when building Cube 2. (There are both Code::Blocks and Xcode project files in Cube 2, which could probably be adapted reasonably well for Syntensity.)
And then there's cmake, which I have zero experience with (and is actually supported by Syntensity). But it'd probably be easier to get working.

reply to this message

#17: Re: ..

by abs1nth on 01/15/2010 13:15, refers to #16

learning how to compile using xcode (there really is not much to learn here) or any other environment is of no use until the project has been successfully ported to the mac by a programmer.

reply to this message

#18: Re: ..

by kripken on 01/15/2010 13:59, refers to #17

@abs1nth:

I would appreciate it if you could explain further what 'porting to the mac' entails here.

All the C++ code should already compile AFAIK. (Maybe with a few lines being changed from #if LINUX to also include OS X - those lines handle different slashes on Linux vs. Windows, so OS X would go the Linux way I presume.) And the majority of new code is already cross-platform, as it is written in Python and JavaScript.

This project is basically sauerbraten, + some new C++ files which should work without problems, + build and link with V8 (which is known to build and work correctly on OS X), + Python (already installed on OS X, I believe), + linking against Boost (which is known to work on OS X, and pretty much everywhere). And it has an Xcode project file (from CMake).

I just don't fully understand the difficulty yet I guess - probably my lack of knowledge about OS X. But perhaps you can explain it further? I think if I do actually understand what the issue is, I might be able to focus better on making progress here.

- kripken

reply to this message

#19: ..

by abs1nth on 01/15/2010 16:10

yeah i guess it is mainly getting the build system to work, plus a few ifdefs and incompatibilities in the source.

last time i heard generating xcode project files with CMake was pretty useless - it only worked for very simple projects. also if the CMake system works there is no need to generate (suboptimal) xcode files, when you can just build with CMake anyway.

as i explained in an private email getting it just to compile and work would not be that hard, probably an hour for someone with cmake + mac experience, or an day for someone (a programmer) without. the harder part would be generating proper deployable binaries.

for any project i have ported to the mac (nearly 10) i have always ignored the native build system that was already in place and just built an xcode project. however due to the dependencies and the addition of source code in 2 interpreted languages i guess this would be more work that just getting the cmake system to work.

reply to this message

#20: Re: ..

by kripken on 01/15/2010 18:59, refers to #19

@abs1nth:

Hmm, an hour to a day makes sense for getting it to build. So that part is clear to me I think.

I don't really know anything about deployable binaries on OS X. You mention 2 interpreted languages, but that should be the easy part, I think? There is nothing to do with Python files except copy them over as-is, in plaintext. The Python runtime will already be installed on the target system. For JavaScript, again all that is necessary is to copy them over as-is, + to link the binary with V8 (a standard C++ library). Is doing this sort of thing very hard with Xcode?

- kripken

P.S. I'm not sure, but I thought CMake can only generate 'native' build files (Makefiles on Linux, Xcode on OS X, etc.), that is it can't build by itself?

reply to this message

#21: ..

by abs1nth on 01/15/2010 23:42

>but that should be the easy part, I think

well i don't know ;-) i've never ported project that wasn't only composed of C/C++ files...

> I'm not sure, but I thought CMake can only generate 'native' build files

what i wanted to say is letting it generate makefiles and using those probably works as fine as the generated xcode projects.

reply to this message

#22: Re: ..

by kripken on 01/16/2010 11:50, refers to #21

@abs1nth:

>>but that should be the easy part, I think

>well i don't know ;-) i've never ported project that wasn't only composed of C/C++ files...

Oh, ok, I guess it might seem harder because it's less familiar. But actually one of the main reasons to use languages like Python and JavaScript is that they are inherently cross-platform, and porting them to various operating systems is extremely simple. Usually it is just to copy over the plaintext files, they will 'just work'.

>> I'm not sure, but I thought CMake can only generate 'native' build files

>what i wanted to say is letting it generate makefiles and using those probably works as fine as the generated xcode projects.

Ok, I understand now.

--

Well, to summarize the main topic about OS X, I think that getting this to work there would be quite simple, for someone that knows C++ and OS X development in general. I would of course help with any questions about the codebase. And my offer still stands, I am willing to pay for someone to do this, out of my own pocket.

- kripken

reply to this message

#23: Re: ..

by Quin on 01/16/2010 16:08, refers to #22

Okay, buy me a Mac then ;)

reply to this message

#24: *.xcodeproj

by LeftClicker on 01/16/2010 18:04

*.xcodeproj is Xcode's native file ending; I'm somewhat sure that while it can compile C++ it needs an *.xcodeproj file. Want me to try it? I use a Mac and dabble in C and C++... and think it would be better to just copy/paste the code instead of rely on CMake. I can't really edit the code, except for minor things like variable names or the if LINUX stuff you mentioned. Oh, do you know any good resources for C++ development?

reply to this message

#25: Re: ..

by kripken on 01/16/2010 19:16, refers to #23

@LeftClicker:

Feel free to try if you want. I'm on IRC if you need help. But, if you aren't an experienced C++ and OS X developer then it might be hard (and I can't help with the OS X part).

About resources for C++ development, there are some online tutorials that are good like this one, http://www.cplusplus.com/doc/tutorial/ , but C++ is in general a hard language - don't expect to learn it overnight. But it's worth the effort :)

- kripken

P.S. I just removed the external dependency on Boost, by bundling the small part of Boost that the engine actually needs and setting it up with CMake. So building the engine is now even easier. The only external dependency over what Sauerbraten has is Python, and as already mentioned that isn't a problem at all (it's already present in OS X).

reply to this message

#26: Re: Kripken

by LeftClicker on 01/16/2010 19:43

Right now I'm learning XHTML and C, as a starting point for C++ and Objective-C -- Apple's official programming language for Mac and iPhone -- Java, C#, etc. While as you said Python is preinstalled for the Mac (see here: http://www.python.org/download/mac/ ) it is often one or even two years behind the current release. Thanks for removing the Boost thing, that should make this stuff easier. I'll read that tutorial stuff, I also have read up on some of the stuff lifehacker is talking about here <http://lifehacker.com/5401954/programmer-101-teach-yourself-how-to-code>.
== LeftClicker ==
P.S. Thanks for helping me get involved in this project, is there a wiki I could help at? (I'm a lot better with words than code =P)

reply to this message

#27: ..

by Matt Bierner on 01/16/2010 20:41

In the meantime, if you do not know how to build or just do not want to put the effort in, you can try running the windows game through wine / crossover on a mac. It worked great for me.

Individual experiences with this approach may vary.

reply to this message

#28: Re: Kripken

by kripken on 01/16/2010 20:53, refers to #26

@LeftClicker:

Hmm, OS X 10.5 comes with Python 2.5.1, according to the website, and that is a recent enough version (2.6.x would be nicer, but not crucial).

There is a wiki at http://wiki.syntensity.com, but I am considering moving to the wiki on github, http://wiki.github.com/kripken/intensityengine/

- kripken

reply to this message

   Board Index