Game Development Community

Minions of Mirth

by Prairie Games · in General Discussion · 07/21/2004 (3:13 pm) · 38 replies

Ah, some nice person cleaned up my mess. Thanks!

Announcing Minions of Mirth Compatibility Test #1.

This is mostly a test, but it does show some of the game and engine too. The work has primarily been on the engine and tools, and it shows ;)

Have fun and if you have any feedback/problems running it... please let us know in our forums. Thanks!

-Josh Ritter
Prairie Games

PS: I am "holding back" the OSX build to see if this was a "good idea"... I know this is a bit lame, but if people are really negative about this, I would rather cut and run on this version without the effort of building an OSX packaging... Of course, someone with XCode could just build it for themselves :)
Page «Previous 1 2
#1
07/21/2004 (3:17 pm)
Nice. Just downloading it now (100mb heh) so will hop on and give 'er.

Read the 'manual' you guys setup. Sounds like some great features. Will keep you informed in your forums on how things are working.
#2
07/21/2004 (3:47 pm)
Oh, geez, and a HUGE thanks to everyone on, what I hope is only the start of, our credits page!!! We wouldn't have even gotten this far without you!!! If we missed you please let us know!!!

I am really emotional right now, a public binary of this game is a huge personal milestone for me... the tears are going to be rolling by the time this is done!

-Josh
#3
07/21/2004 (3:55 pm)
Wow, this rocks Josh. I can see I am going to need to invest more time into exploring what you have done than I originaly planned.

Started exploring the city, keeped wondering where are all the other players. Had to kick myself to remember that it's not networked yet.
#4
07/21/2004 (3:57 pm)
My lowly PC is too lowly. :(
#5
07/21/2004 (4:07 pm)
:)

The city is THE MOST unoptimized part :) Lara is currently working on it... It's now fairly larger than in the test... and we have a realtime visgroup system I did, so we can apply this. The buildings there are thanks to Matt Benya, Tony "Bubba the Master" Pottier, and Christophe Canon

@Mike: Yeah, if I enable the texture cache the video ram usage goes down, but I need to look into some compression schemes... I sacrifice load time and texture ram right now for smoothness... and the system ram usage is just me being sloppy :(

-Josh
#6
07/21/2004 (4:39 pm)
*SIGH* The days of the 256mb Ram minimum are coming to an end. Time to start collecting pennies again :((
#7
07/21/2004 (4:41 pm)
Josh... I gotta tell ya... Do the OSX version. You'll get manical fans (if you don't have already) just because you are doing a 3D RPG on a Mac.

Sounds like a formula for instant love.
#8
07/21/2004 (5:11 pm)
Hah... well I am getting the OSX version together right now... I wanted to save this as "sacred ground" in case I was screwing up with this release... I guess we'll see what happens, it'll be awhile...

I wasn't going to do a binary on Sourceforge... but, then I saw Planeshift has multiple 100 meg released...so, I am going to... they don't do OSX either, the sillies.

-Josh
#9
07/22/2004 (7:24 am)
After some sleep, I feel good about releasing the test... I have wanted a binary that people can run, well, since we began...

An Open Source 3D RPG Engine + Toolkit, network capable, with the decent beginnings of a ruleset and gameplay has been no small order. We are also proving to people who want to make something like this, that you can, with as few as 2 people... though, we do need to look at expanding out team... I am juggling way, way too much... I am game design, art director, tool maker, engine and game code, artist, marketing and biz guy and it's taking it's toll...

One thing is for sure, I have no idea how to make an OSX package :) I wanted to make something like the windows build with some aliases that fed command line args to the app for what level to load... bzzzt. I then hacked in a level_hack.txt which people will have to edit and change to a level of their choice... I don't like this, but I don't see another way... which is weak. Now, I have to get the app's absolute path at runtime and chdir to it, or so it would seem. My Windows(tm) sensibilities are wrong in almost every case.

I also have to package up the SDL framework and dynamic libraries, probably changine the XCode project... At any rate, it's experience... maybe I'll gain some OSX skill points today. :)

Level Up!,
-Josh
#10
07/22/2004 (8:16 am)
Josh, you might want to change the default resolution settings, they're really high :)
Also, the windows taskbar doesn't go away in fullscreen on my workstation.
Didn't have time to really take a deeper look, but it's looking good
Keep on Mirthin', Rebel Warrior !! ;)
#11
07/22/2004 (8:31 am)
Yeah... We sorely need a menuing system for basic settings and choosing level. You can do a:

modelist command in the console and get your supported resolutions
r_mode followed by the mode # will change it

I didn't think 1024x768 was really high... 800x600 would probably have been a better default though...

EDIT: I've started a FAQ on the test.

-Josh
#12
07/22/2004 (8:53 am)
Oh, then PrairieEngine changed it because of my dual monitor setup to 1600, my bad (well, windows + nvidia drivers' bad ;))
I've set it back to 1024. Again, sorry about that :)
1024 is indeed fine for a lot of current gamers, although 800 is playing it on the safe side, certainly
#13
07/22/2004 (9:12 am)
Hm... would you mind dumping your modelist to me? 1024x768 should be mode 6, which is the default, and it shouldn't have changed on the fly...

-Josh
#14
07/22/2004 (9:32 am)
Okay, modelist looks normal...
the 1600 value was in the custom fields in the cfg file (Listed as mode -1, but now it lists 1024 since i changed it)
the first time I started it up, it was 1024, it's just that running in dual mons at 1024 in the default window mode, means i can't see the whole window because of the taskbar.
So, I opened the config file, changed the custom res thingy (didn't have to, I now realize), switched to single display, didn't realize it was still in windowed modes, and made that post about the taskbar still showing up
So the 1600 custom res was most likely in the .cfg file, as again, the game never started at that res, I just thought that the combo of dual mons + that high res, was giving me the windowed problems

oh, when switching to fullscreen, you have to restart completely : vid_restart doesn't do the trick, and loses the UI
#15
07/22/2004 (9:44 am)
Alright, great, thanks.

Yes, there is a message in the console that the change will take place next time you restart the game...

The video system does support restarting, but it's currently borked due to some external things... It'll work again once we are "zoning" between levels again... and thus, restarting the client.

-Josh
#16
07/22/2004 (10:17 am)
Alright, I am going to add/fix a thing or two, based on some reports, and put this up again a little later... I want it to be a little slicker for when the RPG sites start picking it up... please bear with me :)

-Josh
#17
07/22/2004 (10:38 am)
Josh, you might want to post a link to the test build in your dexterity thread, as there is still activity in it :)
I didn't do it, 'cause I didn't want to steal your thunder, you know ;)
#18
07/22/2004 (3:25 pm)
Alright, the new version is up, you can read about it HERE

I trimmed it down to 80 megs, added a "menu" (goodbye lame .bat files), and made 800x600 the default resolution.

I am "in the zone" to make the OSX version now... I no longer have to feed commandline args :)

-Josh
#19
07/23/2004 (6:51 am)
This is a good thing and we definitely want to get the OSX test out there. I am stretched far too thin though... and could really use some help.

If you know XCode and how to package OSX applications for distribution, I would really appreciate your help. Please shoot me an email (available in my profile)... and I'll help you get MoM compiling so you can help us package it... and hopefully teach me something :)

Otherwise, here's the problem I am running into specifically: I use dlopen() to dynamically load the gameplay module. When launched from XCode, this works and it runs... If I launch from Finder it doesn't. I chdir() so the working directory is correct in terms of the application finding files... but for some reason, dlopen() still doesn't work.

Thanks!,
-Josh Ritter
Prairie Games
#20
07/24/2004 (4:16 pm)
Ok.

I uploaded the OSX version of the test: http://www.prairiegames.com/mom_test1_osx.dmg.sit

Please note that the same disclaimers apply to this version... It's currently a pig... If you don't have at least a G5 + 512 megs o' ram + ATI9600, it'll probably be disappointing...

Please let me know if it worked/didn't work for you!!!!

Have fun,
-Josh Ritter
Prairie Games

PS: There is a manual in the manual folder... don't miss it! :)
Page «Previous 1 2