Making a demo/new game

[Avenger]

Are there any efforts being made to create a new game? Any volunteers enlisted?

There was some token effort as seen on the gemrb wiki.

[matt]

I dabble in 2d art and could possibly do some concepts for a new game. Would be nice to know if there are some decent zbrush and/or other 3d people around to bring them to life in that case.

[matt]

I made a sketch to establish the setting for an idea of a short game.

 

My take on a story:

On his deathbed the night before he perished, the great mage NN babbled in his feverish sleep about a great treasure sealed away in the tomb of King NN, ruler of a long gone people in the north. Your local Lord has put together a team of people to go explore this tomb, and you are hired as part of a group of mercenaries to traverse the treacherous mountains that separates your country from the mostly uninhabited lands in the north.

 

The game begins when you reach the ridge of a mountain and gets the first view of the abandoned city, and also the entrance to the tomb (between the legs of the large statue carved out from the mountain side). The first part of the adventure will be to get yourself down the mountain and gain entrance to the tomb. Part two will be to explore the tomb. Part three will be ending up in the abandoned city and escape it with the treasure. Of course, by then most of the team that originally set out will be dead.

 

[matt]

I also started on some interface graphics. Are we doing exactly the same thing as the old games or should we come up with something new?

[lynx]

Nice start, we have the first loading/chapter graphics.

 

As for the gui, almost anything goes, but it is easiest (time-to-delivery) if you start by replacing the bg2 resources.

[matt]

I started working on an area, what is the max area size (in pixels)? I only have BG2 SoA so I'm using that for walking around, but I understand there are different limits between games. Is there a general limit for the gemrb engine that I should stick to?

[lynx]

I don't know of any limits except the absurd ones defined by the data types used (65k x 65k).

[Avenger]

We don't have most of the limits, though i think you cannot have more than 65k tiles including doors? Isn't the tile index a word?

[lynx]

Eternity shows how 2d touchups can really enhance 3d renders:

http://media.obsidian.net/eternity/media/updates/0025/PE-TempleEntrance-ProcessStack-1340.jpg

[Methuselas]

Okay, you've piqued my interests. Especially since Beamdog didn't release mod tools for BG Enhanced like they said they would. I only came across this, recently, as I saw this posted on an Amiga site I use. Since I love my Amigas and there's a serious lack of games on the platform, I started looking into this and I found you. Now, on to the issues at hand.

 

Since it's obvious you're unable to use any of the "stock" graphics from the original games, we have some major issues:

 

1. First thing, first the UI will need a complete overhaul. This will have to be a priority and it's also the easiest thing to do. Once the UI is completed and approved, we can move on to the other areas that neeed to be completed. It would be faster and more efficent for my pipeline, if someone just either a) points me the graphics that need to be replaced and I can skin over them or b) someone were to provide me with an archive of the graphics that need to be re-skinned. Obviously B is the preferred method, as it doesn't require me to reinstall BGII and search through the graphics to find all the pieces that I would need to re-skin, risking missing any. Also, it will speed up my pipeline.

 

2. Secondly, comes with Area maps. I can, quite simply, create modular rooms, caverns, cottages, etc. in Maya, fully textured and with lights that could be exported as fbx files and "sewn" together by others to create their maps. I have tons of fluff items (trees, boxes, stones, etc.) already modeled, fully textured that could be imported into scenes, provided the person doing this, is using Maya. They *COULD* work in 3D Max as well, but I'm not sure how they will transfer, even with FBX. I'll do everything I can to support Maya users, but Max users would pretty much be on their own.

 

Before I can do all this, though, I need to know what the camera angles for renders are. I don't know them. I'd also need to know what the measurement size is before I do anything. Since I will be building using the grid as a template, I would assume that 1 grid square = 1 foot. So, 10 grid squares would be 10 ft. I would prefer using that, as it's the same format I'm using for BTBuilder. This also ties in with character sprites.

 

The quickest way for me to start making modular dungeon tiles is for people to give me "T-Pose" images of simple rooms they'd like to see. I really don't like the idea of modeling everything from scratch, 'cos if I do this properly, I'd have to draw all the rooms first.

 

3. The spell effects will need to be completely re-done. This is also something that can be done, quickly, using particles and emitters in Maya. However, I'll need someone to talk to me about how the engine uses spell effects and targeting.

 

4. Finally, the last part and the one that's most arduous and difficult is character sprites. I can create a bipedal rig that can be exported for anyone to use that has both fk/ik switching and scaleable (Maya only - Constraints don't work properly between Maya and Max). I could even go so far as to animate the rigs for each of the sprite animations (attack, walk, death, etc.), where by someone could re-bind a model to the skeleton and if they use a simple limit of say 1k polys max, I can easily include a paint weight export that can work 95% of the time for every model.

 

Here's where we run into problems, though. I don't know how the engine uses weapons and from what I've seen, it appears that weapons are actually "overlays" or something. Someone will have to explain this to me, in detail on how it works. I'll also need to know the exact camera angle for rendering sprites, just like with spell effects and AREA maps (They *SHOULD* all be the same.)

 

Items, such as helms, armor, weapons, will have to be modeled separately and someone will have to explain to me how they will "overlay" on the paper dolls in the engine. I'll also need to know how the coloring works, 'cos more than likely, it will have to be materials in Maya. At least, that's what I'm going on, right now.

 

Quadruped rigs as of right now, are out of the question. Not 'cos I can't do them, but they won't be able to interchange between other people's models. For example, say I make a rig for a "mountain lion" model. That rig would work properly for a lion, panther, lynx, etc., but wouldn't work for say a bear, deer or a dog.

 

If anyone *WANTS* a "monster", I can model it, provided I at least have an image to work from, but if you're an artist, but not a modeler, a "T-pose" would be preferred. This isn't an invitation to model everything you want, however. Obviously, I'll have a lot of work to do, for one person, so don't let me get burned out, too quickly.

 

5. Anything I do, needs to be 100% compatible with the Amiga port. I'm doing this for those users, so if it gets to a point where the engine breaks their fork, I'm out.

 

My "Resume":

 

http://www.identical....com/btbuilder/

 

One of the rejected UI screens for BTBuilder (Note the city tiles are also mine, rendered out in Maya on a Grid):

 

 

Main character from my demo reel, sans hair:

 

 

New Catapult model I did for MCO, before I dropped out of the project and lost my model:

 

 

Mekara model I did for RiFE (Civ IV mod). It was never used:

 

 

Cheers!

 

-Methuselas

[lynx]

Some area maps are already available, plus some other content — check the wiki link in the first page. I can't tell you much about angles and the 3d process, but you can contact Valiant on this forum, since he also created some models and prerendered them for ingame use. See here:

http://forums.gibberlings3.net/index.php?showtopic=22118&st=0

 

I started making a demo dataset a few days ago and did some changes to gemrb to ease gemrb-mod installation. The plan was just a simple tech-demo riddler, but if anyone wants to improve over that, they are more than welcome.

Anyway, first you have to decide what exactly you want to achieve, since blindly making resources could be a waste of your precious time and enthusiasm.

[Methuselas]

Some area maps are already available, plus some other content — check the wiki link in the first page. I can't tell you much about angles and the 3d process, but you can contact Valiant on this forum, since he also created some models and prerendered them for ingame use. See here:

http://forums.gibber...opic=22118&st=0

 

Okay. I'll take a look and get into contact with him. I'll need to figure out how the character sprites interact with weapons, equipment, etc.

 

I started making a demo dataset a few days ago and did some changes to gemrb to ease gemrb-mod installation. The plan was just a simple tech-demo riddler, but if anyone wants to improve over that, they are more than welcome.

Anyway, first you have to decide what exactly you want to achieve, since blindly making resources could be a waste of your precious time and enthusiasm.

 

I'll take a look at your demo set, as soon as I get a chance. A link to your archive will be appreciated.

 

The UI takes precedence. It's the most important aspect of the graphics that needs to be done, first. While it can be reused, we'll need to shy away from using the consumer skins. First thing I'm going to have to do is build generic templates for all the screens and buttons. This has a two-fold application: 1) it allows the engine to be released with it's own engine skin and 2) will allow other modders to quickly re-skin the interface with their own skins. Like I said, it would be faster if someone gave me an archive with all the UI graphics, bundled together, so I don't have to reinstall BGII, just to get to all the graphics I need.

 

The biggest problem I've seen so far with the UI is the fact that all of the games that used Infinity, seem to have different UI skins, most notably, Planescape, which I no longer own. If there was a way to "force" the mods to use a generic UI skin, it will make my life easier. Otherwise, I'm just focusing on BGII's UI, since that's the one most people are going to use, it's fairly compatible with BGI and IWD, so if they want to mod Planescape, they'll be on their own.

 

Areas, spell effects and character sprites are going to have to wait a while. I need to figure out how the tools work, not to mention locate all the tools I'll need, to start creating all the sprites. Once I know what tools I need, beyond Maya, I'll create "tools" to use in Maya, for various spell effects, animating, etc. Spell effects will probably be the easiest, since they'll just be using particle effects mostly, and/or small texture files.

[lynx]

You can also find some modelling tips in the linked tutorials here (Area part): http://www.shsforums.net/topic/36781-comprehensive-ie-modding-tutorial-index/

 

As far as the gui is concerned, the ingame one is the only real requirement. As soon as you have a text area, you can use it for dialog and all configurability. I prefer the iwd2/pst model, but they're not too well suited for wide screens.

Btw, as long as all the relevant controls have the same IDs, any new gui could be a drop in replacement. Most of the games already share a lot of this anyway and the positioning of the controls doesn't really matter.

GUI files are stored in a binary format called CHU and you need DLTCEP to view them. Pretty painful, but the graphics are in a separate custom format. I'm not sure it makes sense to start with reskinning the whole bg2 though — the scope of the to-be game is yet unknown, so it is probably better to create things as-needed.

[lynx]

The demo stubs have been committed. They are currently not installed, so you either have to run gemrb from the build dir or do it manually. It just sets up a game and dumps a clown into an area. Almost no GUI yet, I've only added a window with a textarea and scrollbar for the messagewindow. Currently it looks horrible, since there is a bug in the date somewhere and the result looks all stripe-y. No interactivity either, just wanted to get the basics out.

 

As for concrete needs at this point, all the cursors are missing (original has 47, but we don't need that many) and fog of war is just a solid block of black. There is some good stuff over at OpenGameArt that could be reused, but nothing covers the whole range.

[Chilvence]

The UI takes precedence. It's the most important aspect of the graphics that needs to be done, first. While it can be reused, we'll need to shy away from using the consumer skins.

 

If you are making a UI, bear in mind that you can also change the layout however you like. You also don't necessarily have to fight with the ancient CHU format if is gemrb only, since you can create/move controls using the python interface. I am in the middle of hacking it up, because I much more enjoy playing these sorts of games without any interface, such is the atmosphere created by the art, it deserves to be full screen - but the original games make it difficult to play this way.

 

Actually to make my point better, this is how trivially easy it is to improve the interface layout, it is more or less the spec I am aiming at: http://picpaste.de/pics/test-v8rYKJmZ.1355392790.png . I always play with the options pane off, but it is a nuisance turning it on and off to look at stuff occasionally. But in my work in progress, I have since thought of several ways to save even more space, and still be able to do everything the game allows from the game screen.