Session Start (sendak.openprojects.net:#egoboo): Thu Aug 01 19:54:16 2002 *** Now talking in #egoboo. *** Users on #egoboo: booger @BenSw *** End of /NAMES list. *** Mode for channel #egoboo is "+n" *** Channel #egoboo was created at Fri Jul 26 19:20:14 2002 *** Join to #egoboo completed in 0 seconds. *** bitnapper (bitnapper@dialin-client-62-2-131-88.hispeed.ch) has joined channel #egoboo Hi Booger hey, glad you made it. hope I didn't leave you waiting too long for an answer, I was busy on another page. No just half a minute or so. I took the time to make an update on the CVS. cool, you're awake kind of early. or is it up kind of late? Yes, it's about 5:30 AM here. I "burned some midnight oil" as Arakon used to say. ouch, I hope you can manage to stay awake for another few hours. The meeting isn't scheduled to start for another hour and a half. Though, we may get lucky and have people get here early. Heck, we're already here. I'm shure I can manage that. What's up for this chat? I think that Elmin wanted to hear some of your ideas. Just get your input really. Ideas flow more freely in an open forum rather than a messageboard. Personally, I would like to get an idea of what's going on with the frontend code. Did you need any graphics done for that? I agreee with that, but I'm afraid my explanations might be not that good if I write them online. Not yet. I have still your sketches from half a year ago. The forum isn't really meant for full explanations, just exchange of ideas. It's more of a dynamic brainstorming session. Also, if someone has a question regarding something you're doing, they can always just ask and get immediate feedback. Let me know if you need any new artwork, I'm sure I can scare something up. I hope we can get today the point where we are exactly heading for. For this purpose, an online discussion is better then on on the forum. Beside this: The answer time of IRC is a little bit slow... exactly why we are having them. It helps keep everyone working as a team on a singular focus, rather than multiple groups all working on seperate projects. slow? it's as fast as a person can type. Maybe I have to accustom to it... :) It does take some getting used to, agreed. Did I get it right, that we are heading towards a "storyline" RPG and away from the "module" stuff? I don't think we're heading toward a real storyline, just connecting the modules. There will be a basic storyline to tie things together, nothing too severe I think. But at east to have Character Classes you can choose from something like But, yeah. We are moving away from the modules. Though you should still be able to load a module and play it if you want. Yeah, there will still be the story that is currently in place about the sporks and different character classes. Perhaps just a little more detail than that. When I say there won't be a story, I mean that it won't be on an epic scale like in the Final Fantasy series. I'm still eager to get a character generator in place. You wished to have that "Character Generation Screen". Do you have any idea what character data is needed? At the actual state, for every character a start module is given and so is the basic character. Off the top of my head, no. I'm sure we can figure it out though. There will be the basic stats that are listed in the character description, of course. Perhaps more. *** Arakon (vircuser@24-196-92-77.jvl.wi.charter.com) has joined channel #egoboo greetings There will be need for rules. AD&D for example are very precise rules. I had envisioned creating a character, rolling attributes and then selecting a class. Then you start the module for the class you had selected. Hi Arakon greetings Arakon. I think you should be able to play every module with every class. even the start modules? Yes. It might be interesting to achieve the same goal with different characters, using different approaches. hmmmm........ okay. But how about this: You start in the module specific to your class, then, if you want to play another module at a future point you import your character into it (via the world map, presumably). Arakon, I thought you weren't gonna be able to show up tonight? I can't stay very late. midnight's my limit (that's when I thought it was starting) We got here early. is good :) I've made soo much progress w/things. Mostly w/auto object importing. I can't wait for everyone to see. I'll step into my corner and let the programmers talk:) Did you guys have anything you wanted to discuss? I'm OK - finding the topic interesting, just kind of lurking, unless there's any Q's for me? You souded pretty amped about your recent work on the forums, yeah. Can't wait to see it. We were just discussing the frontend and character generation screen. yes, amped, good word Arakon - could you post me the code you use for reading / generating the text files needed? btw, bitnapper, I couldn't seem to get that 3d mazeman demo working. Something about being unable to find a sdl library. like the spawn.txt files and such? The SDL.DLL? booger - did you try copying it from teh egoboo directory ? don't remember offhand. I'll play with it this weekend and post in the forums. It's not really that important of an issue. It should find it, if its in the WINDOWS/SYSTEM directory, I keep it there. I played around t odisplay EGOBOO models with a standard code for display of quake models. It shows artifacts from the GRIP-Vertices. anyway, about that read / generate text file code (back to more serious stuff).... ah, yes- which files particularly? Almost all my code is in C++ ... I'm interested about your solution for reading the egoboo text files. Ahh Most of it is pretty much code from Egoboo warpped in C++. Almost all of it. A few are a bit simplified: Booger- about serious: It's serious in a later stage how we display the MD2-Models. For the recent import code I did, it basically copies the file (line by line) exactly unless it finds the "slot" definition line, in which case it simply changes it The only files I really need to read from Egoboo are the Spawn.txt, the data.txt files (for importing only), and the module's "menu.txt" file It's still a pain that the slot _number_ is used for spawning of characters. I personally would prefer to spawn them by names. Yeah .. I've grown to dislike the slot system in the last two weeks myself .. I think for a solid solution though, we need namespaces of some sort to avoid clashes I think the data how the character is _defined_ and how the character is _displayed_ on screen should be keeped separate completely. I think I agree w/that, but how do you mean? You define a character e.g. adventurer in a text file. The text then holds a line with the name of the model to use e.g "knight". Thus, the graphic models exist only once, for use with different characters. ohh, yes, I agree completely I'd like to see some form of hierarchial search too - so you can specify a custom model, otherwise it looks in some global model collection could you have customizable skins for individual characters? it could use the default models classes, but allow individualism for the characters. Yes, that's right, the 3D-Models take the most work. It's easier to create new skins for them. definitly It'd also cut down module sizes a LOT, which would be very nice You could define your characters hair and skin color, then choose from the skins which match the given attributes. sex and character class would be an issue of the actual models, rather than the skins. also for some items - like armor What would be really neat is to use a procedural texture for character skins, to allow for a lot more customization. It should probably wait though until another version Ih the head is to be guaranteed a the same place on every skin, the head can be replaced in runtime by a user created one. sounds like a great plan. agreed that it should wait for a future version though. I think my biggest concern for features in the near-term is a way of linking the maps together We could achieve that with a hack by extending the "menu.txt" file, as ioquan did. I'm getting the impression that that will be handled by the Lua script. I don't like the idea of it dropping back to the menu every time you change levels. It will, but I think bitnapper's release will be done sooner then Elmin's... I'm looking at it this way: We get a good many of 'new' users' to the board every few weeks, but I don't think Egoboo is holding interest due to slow development, and limited modules.. if we can start retaining more ppl with a good map editor (EgoMap! :) ) and some module linking, we can start holding some more creative talent.. I agree Agreed, but is there any way to make the module linking a little more seamless? Perhaps make the jump to the menu invisible to the player, and automatically start the new level. No problem. there should be I think our main goals right now should be short-term, and visible. That's how I've been going at EgoMap and the map generator Also, at least as far as I see it, the random map generation being integrated into the main exe will be the lynchpin that brings in the user base. which, is getting really close to usable .. Though, it'lll take a while for it to do "fun" maps I see two possibilities: Since Egoboo in itself can support a wide range of games (Zelda-like, Diablo-like, etc), we're kind of collecting people from different areas.. some want a story-like game (Ioquan for one) of hand crafted levels, to make a "journey" to play through.. other's want the nethack type feel. What do we heading for? The engine can really do both .. and I think it will be fairly easy to support both.. Personally, I want both too :) (hence EgoMap, and RandMap :) ) Have either of you played GoldenAxe for the sega? (Old game) God, I used to love that game. I have it on my computer using MAME. I wasted so many quarters in the arcade version. hehehe *** Signoff: BenSw (sendak.openprojects.net irc.openprojects.net) No. I played "Baldurs Gate" and before "Eye of the Beholder". I could see a game very similar in Egoboo with that kind of theme. Just a level-run-through w/story. It'd be cool *** BenSw (~yoda@12-249-96-16.client.attbi.com) has joined channel #egoboo *** Mode change "+o BenSw" for channel #egoboo by sendak.openprojects.net of course though, the random maps would be awesome too. I'll prolly need some help balancing that, and adding features to it .. there's a lot to do yet Yeah, it could be cool. I'd much rather see the game follow the feel of a Roguelike though. Open exploration, random levels, etc. me also. I'd be curious to play the more plot-based ones ppl come up with though too. There's an engine out there called "verge-rpg" that's been around for along time. Originally it was to make final-fantasy style games, but it's really general.. ppl have made some neat stuff with it. anyways .. back to topic? (or is this on?) Arakon, there's an article in one of my game design books concerning puzzles and how they work. When I was reading it I was thinking that you could incoporate some of the principles into your random maze algorithm to create simple chalenges. That'd be cool. I was thinking similar. Like door-opening things, key type things, etc? Maybe it could be worth to take a look into the nethack code for level generation. not too much help.. I've scoured the rogue-like resources.. I just thought of it, if you're interested I can find it and send it to you (via my digital camera). but yeah, door/ key, monster/ chest, multiple passageway choices... stuff like that. they're quite a bit more "simple" then egoboo. The graphic's makes things a lot more demanding to be visually pleasing I'll let you know when I'm closer. That's a good idea I think we'll need a goal list soon of what we want randmap to beable to make. Personally, I'd like it to do levels like: Advent, Healer, and the Palaces .. and some outdoor stuff Maybe we can find for the start some simple solutions for display and make it more sophisticated in a later stage. I did some scratch sheet ideas on the random level generation stuff back in January, I'll compile that and send it to ya with the puzzle stuff. ok, sounds good. Or post it somewhere (or I can). the more ppl we get feedback from the better .. At moment RandMap can make a twisty set of "rooms" and "caves" .. but they're pretty plane as far as visuals go. Simple tiles, some fancy patterns, all the same floor height It'd be OK for now though You wrote on the board something about the usage of the "FANS". yes, that's all thankfully internallized and I havn't had to touch the code since finishing the WallMaker stuff randmap (internally) works by just using grids (floor, or wall?), and texture-sets. hm, on the topic of map linking. If we do a menu.txt adjustment, I see a few things we need: some way of linking passages to a specific exit (script? That's all pretty messy .. and all the vars seem used?) and also a way to auto-load And a sort of SAVE-Game oh yes .. uh .. ... which will be something like a auto generated "spawn.txt" using the actual positions. unless we allow saves only at teh begining of modules (I'm for that) we'll still need to save teh actual data - a new structure and new file set too and, a format for specifying the randmap parameters when linking modules I have to go, but I'll be back in a little while before hading off to bed. I'll stay on though, so I can review the log later an auto generated spawn.txt doesn't sound that hard to do. It would be much easier on the player if they could save the game at any point. especially for saving the state of the world map as you go between it and the dungeons. Elmin should be online any time now. If you talk of "World-Map" - do you mean the one in 3D - the module like? yeah, that's what I mean. I guess we could still do a 2-d world map, but I kind of like the idea of a 3-d one now that I've been playing with it a little. I prefer the 3D-one, too. Maybe I can write a test program four you to check the functions. But the intro menu comes first. Yeah, I think the menu is really important. It's as much for show as anything else, but it's also the first impression that people get of the game when they start it up. First impressions stick with people. In the first stage it'll be text only and pure functionality. There go my dreams of fire effects and morphing graphics:( lol Just for the moment... :) First it has to work, then lets see.. I understand that you have to build functionality before you start adding pretty effects. The pretty effects are the things that make the big first impressions though. Otherwise we'd just still be playing Nethack. But in 3D! - Just joking. Is the menu going to be mouse driven? Well, actually that was a stupid question, of course it is. Of course, either arrow keys or mouse, with highlighted text. The current menu at least has that much functionality. I don't know where my brain was when I asked that..... I need to get some more coffee. I didn't see highlighted text. *** elmin (~elmin@208.186.188.86) has joined channel #egoboo I meant that it was already mouse driven. Hello welcome elmin, we've been expecting you. we decided to get an early start, we've been going for about two hours now. oh Hi elmin. Me old man managed it to install an IRC-Software. great everyone pat bitnapper on the back, good job old boy. so, what's on the table? :D You've gonna have to read a lot... yeah, I guess I'll have to catch up in the logs we've been talking about the frontend and character creation and a bit about random level generation. any questions for me? ... and where we want to head. arakon's afk, he should be back shortly, but won't be online much longer (needs sleep.... wimp!) yeah, there was some discussion about whether Egoboo should focus more on story driven, linear gameplay or open, random generated roguelike gameplay. Or a balance of the two. We talked about the simplest way to link modules. Personally, I prefer the rougelike plus story driven -- anything but linear module linking hack until the Lua interface is ready, then redesign the module linking to use Lua. Well, there are some design issues independent of Lua for example, how does one go down a staircase? and how do staircases integrate with the terrain Personally, I'd be ecstatic if we just had a continuous random dungeon that I could crawl down into a la Rogue. with a town at the top for buying/selling goods. ? Yeah, we should start there E. g. old stile: You step on it an enter a new level OK, now here's an idea: Gauntlet staircases. what if staircases were a tile? and the scripting was handled by a passage A staircase lacks in the "fans" sortiment That's true, but we can always fudge it with textures The staircase would look better as a model, I think. It would be just as easy to place a model as a specific tile. Then you have to "spawn" the staircase, too. You could even have the model handle the 'step on it and teleport' functionality in a script. There's still a problem of how the down staircases will rest on the terrain ? Unless you can have unconnected vertices in a map file So, you have to spawn a staircase. Big deal. Down staircase models could be trap doors. it has to be exactly placed so that the staircase is continuous with the floor or it could be a trap door It's all the same, it's the place, where you automatically change to another level If it wasn't a model, you'd have to put something special there anyway for the game to recognize the floor tile as a staircase. No, you can write scripts that are activated when the character enters an area of the map That's in the passage code. It doesn't matter, how it looks. If it's a matter of the staircase not looking right because it wasn't flush with the floor, the staircase being a floor tile would look just as amateurish (IMHO). Yes, I was thinking there might be a way to make it flush with the floor right, area script, staircase script, you still have to handle it some way. You can make it flush with the floor via randmap. I'm sure it can check the floor level and make it match up with the staircase without too much trouble. I took the worong word: It does matter, how it looks, but not how it's displayed. Yeah, it's not really a big problem. randmap is more arakon's area though, you back yet arakon? Maybe he fell asleep... nah, we'd see the sleep keyboard marks from him: hguihbusihf,r b,,mft rrhrfgfrfrlllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllll But a model staircase needs, beside of the level height a direction. You can specify a model's direction in the spawn.txt Right, I forgot Yes, and that's a good reason to have Egomap and randmap be able to write spawn points BTW, in zippy it's spawn.lua same thing, though arakon was really excited earlier. he had made a lot of progress with the spawn points in egomap. afk... getting coffee back... didn't miss a thing nope Elmin- could you spare some time the next few days to make the conversion from array to struct in 2xx? Are you still having trouble with that? Sure. I might want to finish the initial Namespace code, first, but that'll be pretty quick Not _that_ much. But I think you get it faster done with software help then me by hand. Did you figure out the regexp stuff? I can tell you which patterns I use, if that would help... regexp?? Is that available on windows? With some software... I thought you had mentioned something about Borland having grep support grep == regexp or rather, grep processes regexps It has grep support. Can you use grep for search _AND_ replace? I don't know... I haven't used it for that, anyway It might help if you post me some regexps you used. OK, just a sec s/chr(.?)(\[.?\])/\2->\1/gc That's from VI, converted to standard form, I think Replace chr with prt for particles or with cap for character types not all of the names are the same, though, so you still have to go through and look at each one to make sure it's valid that's what the 'c' is for; in VI it stands for "confirm" Have you evert thought to split the character types in the data and the display part? Each character is spawned with a Profile, which has the model and skin information, as well as statistical stuff Everything that's engine-specific goes in Profile, just about It's more of a separation between AI and physical properties Are model and skin information needed for the AI-part? No, but if they are, the information should be accessible to AI scripts I haven't made all of the bindings yet, but it's on my TODO list I have to make Profile a full-fledged Lua data type, then scripts can just access it as self.profile How about to keep them apart and read functions for accessing them by AI-Scripts? Well, with the namespace stuff, you should be able to direct the engine to other files to look for them. bitnapper's talking about having a global model directory instead of saving the model in the character folder. That's already doable When you specify the model, you pass a filename It can be anywhere you want It's a little bit hard for me to make myself clear, because I'm not through yet with my thoughts about that. Have you had a chance to look at some of the example scripts in CVS? it was talked about earlier, elmin can read back in the log after it's posted and catch up on what was discussed. I thinks, it's needed that I'll take a closer look to the example scripts. Take a look especially at the Knight script -- it's fairly simple Have you guys discussed the inventory interface yet? I had some thoughts about that... How about the movement by Ai. Do you want to feed it directly to the character? I thought about to feed AI-Output to a PLAYER and these to the characters. I think feeding it to the character is best... We didn't talk about inventory yet. That way you don't have to worry about who's controlled by what in the player code Also, the PCs have to have scripts too, and they might need to take control of the character for some special scenarios back, for a time (read through log too) Hi, arakon on the staircase part - We can work that out later. There's also several fan-types that are not used yet, we could always hijack a few of those But, how about to choose in the start screen of a module which character is fed by device input and which by AI? also, I may try a test integration w/Egoboo this weekend, just to make sure a basic interface will work that sounds like a good idea, for the AI/input Well, that's a bit of a puzzle anyway -- how do you separate AI from the identity of a character? ohh,, and more importantly - Rounding up data to send over a network connection ... In other words, if you have a PC, what parts stay and what parts go when you switch to AI control? configure input on a settings screen off the main menu. don't do it at the beginning of the module. My tought were these: Input us fed to a character by a player, and it doesn't matter if the player is fed by human, network or AI input. oh, wait..... I got confused again. I'll go crawl back in my corner:D That would make it somewhat easier for network play... bitnapper has the solution most games use OK, I guess this is the problem: Well, nevermind... I figured it out I've tried that solution on a game I've been developing (before being distracted by Egoboo :) ), and it works well, it just makes things a bit more complex .. The main thing is swapping out scripts at the character level yes, and keeping events separate separate from? which events, also? AI, vs Object based messages. Example: Object is hit by something. The actual Object the AI controls should get the hit, but the AI may not get alerted to it for some reason Why wouldn't it? I have some more situational-based examples, but I can't think of them at moment. It was a problem I've encountered before though For instance: Maybe the object masks it due to an effect of some sort Deafness? I dunno .. I'm trying to keep all of those types of effects in script... I still have to decide on an interface for getting feedback to the engine so it can figure out what to do Example: the object is hit by an arrow, and the engine calls a Lua function that tells it whether or not it was deflected Interactive fiction handles that by using two events for each occurance: before and after another method would be to pass the event and allow it to be modified Well, let's take the arrow scenario: The arrow hits, so the engine has to do something with it. It can deflect it, or it can make it stick and cause damage To decide, it has to consult the script Collsion events need to be sent to both objects Arrows are particles, not objects The arrow when getting a collision event, could issue a Damage event to the offensive object particles, objects, scripts .. all pretty much the same in this sense the particle uses the same event model stuff, ? not really -- in this case the message would go to the bow hmm.. the idea with particles is that they have intial conditions, and the rest of their life is controlled by the environment hm, Well, that may work OK .. The collision event sent to the Hit Object could contain the Particle information, which it could examine and accept or reject otherwise, you have too many events floating around -- think about a fountain, or a flame; you don't want to send events to every bit of fire This would work well for an effects-filter system too - so something could override or convert the damage in some way that's true That's the model I was thinking of with the before/after thing before is to verify, after is to register the effect yeah, good idea heh, I stole it from Inform :) hehe, it's a common solution I have teh docs somewhere for a rather developed magic system, and I think it used a similar setup, Except in some situations it required copies to be made of the Event to allow divergant results (area effects that overlapped got very messy) copies of the event? not sure what you mean I'm not sure if it will be an issue with egoboo. Basically if one particular event can cause multiple effects, in some situations the event would need to have a separate copy sent to the multiple items to get thigns to turn out right. I can find an example if you need Oh, I see now such as a firebomb that splits into multiple other bombs when it hits the ground? hmm.. More like a Protection spell that would intercept all fireball damage done within a radius Well, if the other bombs happen to hit more than one person at a time... ahhh... I see now. Aha, that's a bit of a challenge... Combine that with someone who has a "Silence" spell around him, and then someone trying to cast a fireball ... How did you handle that? the protection spell, I mean by memory (I can't find the doc at moment .. burried or lost :-/ ) I'm thinking of a solution with passages... similar, yes The fireball spell when it hit would cause a check for nearby Area Efffects attached to Objects of sorts The Protection area would respond, and altar the event the same type of thing that you were thinking: Permission request, and then Apply Permission would be denied, so the fireball would run it's Failure response somehow Yeah... I do have a system in place that could support that eventually, with Actions Currently, everything has the "after" part, and nothing has the "before" yet Event propogation has to be done right though, because if teh reciever of the fireball had an item or something that responded to fireballs, it must not go off It depends on if you only want to catch direct damage or not... I think having the fireball detonate something else would be a neat thing to allow that's rather evil somewhat .. but in the Protection senerio, the Protection spell is area, it would have stopped the fireball magically from actually causing any damage I think so too - like red barrels and such :) gunn powder Doors So, does it stop the fireball, or just its effects? the latter is harder to do yes, quite. Area effects in general are I think we can saftly shelf that issue. It builds off of other things anyways As for damage and effects: As long as objects are passed some form of collision event, they can be customized to respond any way the want. OK, fun puzzles though... Yes, I have some more sitting around too.. Some get really complicated. I ended up drawing out things :) We just need to standardize the damage types. Categorize them for the events IDZ's already do this w/the current version IDSZ ara a little bit ugly. Better give them usable names. There's a lot of room for that sort of thing to be added script-side in Lua with intelligible names yeah We have to make sure that a doc is written up with all the names, and make sure everyone sticks to the standard tho. preferably a dynamic online doc, so that new names can be added. If the damage types were bitmasks, it would be the fastest way for damage checks. Yes, but bitmasks are not extensible... Hard if more the 32 ... Anyway, it should be transparent to scripts You can store them any way you want, really also, if different damages to different types but we should prolly keep it simple, atleast at first. like elmin said, that's mostly script, and can be adjusted later if need be Agreed My goal is to have the engine go back to controlling physics and directing input then have the scripts do the rest... good. I'm a bit concerned w/how networking will sit inside all of this. It's much easier if it's all C, but we need a lot to be Lua. I would be worried about that more if we had plans for a networking engine... eventually I think we need to implement online multiplayer support. there are quite a few people who are requesting it. Well, the question is, do we design for multiplayer from the start, or try to fold it in later? I want to keep the data neeeded for display keep separated as much as possible and not mixed as much as is it now. I agree .. that's pretty much expected now from a game If we try to design it in now, we have to have plans for the engine, and someone's going to have to be around to implement it