Wyrmkeep Entertainment Board
July 16, 2019, 07:16:54 PM *
Welcome, Guest. Please login or register.

Login with username, password and session length
News: Patreon for Inherit the Earth:Sand and Shadows launched!
 
Our sites: Wyrmkeep Entertainment Home   Inherit the Earth Comic   Mole's Quest   The Labyrinth of Time
  Home Help Search Members Login Register  
  Show Posts
Pages: [1] 2 3
1  Game Devlopment Forums / General Game Development Forum / Game Concept: Technical on: February 17, 2005, 06:36:41 PM
It looks like you've made some serious headway with NISS. Wink

Sorry I haven't been able to help at all--I am still entangled in the writhing mass called "college." It is painful and leaves me with little free time.

The NISS journal is cute.
2  Game Devlopment Forums / General Game Development Forum / Game Concept: Technical on: December 31, 2004, 12:41:48 PM
Quote
I've got free time now. Any advice on getting OGRE and PyOGRE set up, anyone?
http://www.ogre3d.org/phpBB2/viewtopic.php...ighlight=pyogre

Precompiled binaries of OGRE3D and PyOGRE bindings.

Sorry, incommunicado, life's been hectic, consulting is fun but hard work, also, its cold.

Love,

Threed.
3  Inherit the Earth Forums / General Inherit the Earth Forum / ITE's Dos version works with xp! on: December 13, 2004, 09:53:51 AM
VDMSound is an sound-emulator program that makes most old DOS-based games run under Windows XP - its much simplier and easier to use than DOSBox, most of the time.

Does it just not work if you try using VDMSound, Puss?
4  Game Devlopment Forums / General Game Development Forum / Game Concept: Technical on: December 03, 2004, 01:49:33 PM
yah. that math shit boggles my cubes, mun.

Quote
Are you and Suule currently working on anything, graphics-wise? I've been staying away from that end of it.

"Not I," said the little bunny rabbit, sinking his fangs into your neck.

I'd say there's still junk to discuss, language, user interface, map file format, etc,, etc, other things deserving of kung-fu action.

Alternatively I could just start hacking away in a language I know best and then try to backport the code to whatever (trust me, it will be backporting).
5  Game Devlopment Forums / General Game Development Forum / Game Concept: Technical on: December 03, 2004, 11:44:28 AM
The dissonace is having tile-based graphics with a freeform movement system!

@Finding nearby tiles and their items:

I think using a Binary Search would make this much more efficient, if the list of objects were sorted. But that requires sorting, resorting, and searching.

Having said that, the actual performance hit for iterating through an unsorted array is not very bad; most users wouldn't notice unless you had thousands upon thousands of objects all loaded at once.

Problem is, you're going to have to have some kind of coordinate system to lay down objects - what's the granularity? Is 1.1 similar to 1.01?

Hexagonalalalala isn't too bad; it actually adds, like, 4 more possible areas of movement - 8 potential moves, almost freeform movement, but not quite; however, what are the benefits of a freeform system like that? If this were an FPS you could argue that you might pull some "emergent behavior" like jumping between two very hard-to-get-at-rocks.

Zelda - at least on the SNES - was tiled based. It seemed like you could move in every direction, but attacking or throwing objects would only go in four directions; you had the illusion of freeform movement, but not the benefits, which I thought was weird.

You could take it to the extreme and divide everything up into bazillions of "tile" based quardinates, then each object has the potential to spawn multiple mini tiles, thus creating the illusion of freeform phatness, but I've never done that before, so its all theory. (Theoretically this allows for neat things like scrawny characters being able to fit where fatter characters wouldn't, or can't, because they occupy way more characters than the slimmer ones that just snuck between two big rocks).

Quote
Checkpoints, rockslides, and mysterious doors can block paths.

Not necessarily bad - I played Max Payne 2 three times in a row, mainly just to get the good ending, the one I so richly deserved, RIGHTEOUSLY DESERVED, but it was still a blast even on the third go round, but maybe I just liked shoot-diving into a crowd of gangstas and thugs to save the day.

Although I'd like to blow up the world some day, and leave my initals floating in outer space using the Earth-debris.
6  Game Devlopment Forums / General Game Development Forum / Game Concept: Technical on: November 22, 2004, 09:31:57 AM
Quote
No, I think the 2D distance function is:

d = sqrt( (x2-x1)^2 + (y2-y1)^2 )

"Kajuta Stan"?
 
Stan of the Kajuta, of course.

Yes, its right.
7  Game Devlopment Forums / General Game Development Forum / Game Concept: Technical on: November 20, 2004, 05:50:34 AM
Tile based is not necessarily bad. Using hexagonananalalal tiles, you get much more movement space and it seems more fluid. Alternatively, you can abndon the concept of "tiles" for guiding player movement and just use collision detection, little rectangles around special, impassible entites, to determine wheither a player is allowed to walk through them or not.

Quote
Uh... yes?
I thought of it as, "All flammable GameObjects have flag self.flammable = True. When you create fire, a Fire(range, temperature) message is sent to all GameObjects in range; if an object's flammable is True, it catches fire."
Alright; two means to the same end.

The problem is that you're going to have to add a self.flammable variable to every entity you create. =D Probably not that much, though, if you inherit from a base class... just toggle self.flammable whneverekrjlkjelkfjkljsdlkfjslkdfjslkdf

KAJUTA STAN.

What are you doing?! GO BACK TO THE CON RIGHT NOW.

There might be hot chicks dressed up as sexy fox vixens AND YOU'RE MISSING IT ALL RIGHT NOW.
8  Game Devlopment Forums / General Game Development Forum / Game Concept: Technical on: November 19, 2004, 09:14:50 AM
Now, having actually read S's reply, I think I can comment some: (=D)

Quote
...We need 2 Engines that have a similar object-handling/scripting system with diffrent views needed. Since we all be basing on SDL as the base of the project (OGRE uses SDL, right?) the only thing that would link our project would be that we would use the same data structures for objects. Threed can take care of Isometric part, while I code the indoor/flat BG part. How does that sound? And the language I would use would be of course C++ (Borland Compiler).

I think he's proposing two completely seperate engines that share a common file-format and scripting language like Lua or Python or whatever. Then, whenever the scene -- no, I take that back, have no idea what he's getting at. I thought it was coding two seperate engines and just switching between them dynamically, or two seperate rendering engines that then overlay a rendered bitmap over one another.

I have no idea what I've even said.
9  Game Devlopment Forums / General Game Development Forum / Game Concept: Technical on: November 19, 2004, 09:03:32 AM
Lua is a scripting language dependent mostly or in large part on a C++ engine that provides it data structures, which can then be manipulated through Lua.

Code whoring: Sule is obviously proficient in C++ (ANSI99 if he's a youngin'), Kay's forte' obviously lies with Python, and mine is typically C# or Boo (AKA, "Python for .NET."). One of these is a language, one of these is a slim language-dependent platform, and one of these is a bulky language-agonistic platform. They each favor different coding styles and conventions; templates in C++, tuples and type inference in Python, tuples, type inference, dadda dadda dadda. Kay's never going to touch C++ - I can tell by the knee-jerk reaction Kay's had to Java and C#, because in terms of complexity, it goes, (least to greatest), Python-->C#/Java-->C++. I write C++ code, but only as a complete and utter last resort - its either Python or Boo or C#, 'cuz I hate dealing with all that mundane shit like pointer arithmetic. Suule... well,  I take it he's hardcore C++ ninja fellah.

Getting Python or C++ to work together (PROPERLY) is very hard; though the Python interpretor is embeddable into C++ code, it requires careful consideration and standards on how you're going to expose C++ data to the python interpretor, and the person doing the python scripting will require YOUR SOUL -- uh, er, they'll require close communication, because in large part how the python code might be structured depends entirely on what's exposed to it by the C++ code. And then, of course, gotta deal with returning values from Python to C++, of which I have no idea how that works; never had to bother. (won't mention C#/Boo, 'cuz I'm biased. Does writing that make me more biased, or less? Maybe if I used 'drugged up on rootbeer and pizza,' would that count?).

Alternatively, it can be written entirely in Python, and thanks to Python's modular approach, speed-intensive modules can be written in C++ and invoked from Python, summoning great DEMONS FROM BEYOND TO CONSUME versatility when you wanna be that way.

*has no real comment towards either, just wanted to make sure everyone understood the issue at hand*

Temple of Elemental Evil used Python for some of its logic - the game was buggy but only because it did not go through QA enough times towards the end. Technology wise, awesome game; grab it for 9.99, download Patch2 and the Circle of Eight patches to make the game playable. Its pretty fun then. Oh, shit, is this a tangent?


Quote
-It'd be a good idea to have other tags like "flammable," "fragile," (or Durability, or HP) and "magnetic." Then you don't need a list of what objects can interact with what others; instead a flame spell "naturally" sets appropriate stuff on fire.

For example:

"All flammable GameObjects implement the IFlammable interface, which requires they expose a public method signature called "Burnination(duration as int, damage as int); thus, when you call FlameAttack(player as GameObject, damage, duration), the FlameAttack() method will check to see if player implements IFlammable; if so, call Burnination(), then the standard Attack() methods; else, just call the standard Attack() method."

That?
10  Game Devlopment Forums / General Game Development Forum / Game Concept: Technical on: November 18, 2004, 02:24:49 PM
PyOGRE is not .NET dependent; it just requires use of the Visual Studio 2003 C++ compiler - which is a free download from Microsoft. PyGame is a Python wrapper for SDL with a few things built on top; its a bit of a higher level abstraction that deals with concepts like sprites instead of raw images, automatically handles movies, dadda dadda dadda.

Crazy Eddie's GUI is an abstract GUI system that happens to have implementations under OGRE, Axiom, and some other engines. Yake, last I checked, was C++ based with using Lua as a scripting language.
11  Game Devlopment Forums / General Game Development Forum / Game Concept: Outline on: November 17, 2004, 08:25:54 AM
Oki doki! Wink
12  Game Devlopment Forums / General Game Development Forum / Game Concept: Outline on: November 16, 2004, 11:26:14 AM
@Suule, on the issue of me being too fast, bai-bee!

The reason I code is generally born out of necessity* - I want something and there's nothing else that suffices, so I general subscribe to the more pragmatic view of software engineering: "Ok, someone else wrote an acceptable <INSERT WORDS HERE> library, I'll use that instead of reinventing it myself." Its why I use high level languages like Boo (Python-esque for .NET), C#, Python, Ruby, etc - using C++ means I have to go through agonizing loop-holes to reinvent stuff that is available by default in those higher level languages.


*I'm not interested in the beautiful simplicty of the fibonacci algorithm, for instance, and I wouldn't bother playing with it unless I needed it for a project.

@Kay, on OGRE and why I'm incredibly lazy: Yeah, OGRE has a Python wrapper. The scene graph engine is still in C++, but the PyOgre wrapper lets you do the logic and control the library in Python. I only advocate 3d scene graphs because (I, uh, think I listed these somewhere else, but I'll parrot myself):

  • 3d pipeline architecture in most video cards has far exceeded 2d pipeline architecture. AKA, "its still going to be faster if you use a card's 3d functions." Why care? Faster pipeline = more stuff you can do. Remember the scene where Riff's on the mountain ridge and you can see the tempest in the background? ;0
  • Scene graphs are a higher abstraction - they don't deal with pixels, just meshes. Instead of having to massage your own entity view abstraction into place (you'll need a data structure that keeps track of X, Y coordinates, current animation state, and a built in function, either global or static, that erases that image when its time to move to the next frame), you just create a 2d polygon with the texture you want to draw, and attach it to your data model. Tell the scene graph to move the polygon to X, Y, (Z), and that's it - there's no crazy bit blitting, the scene graph jsut moves the polygon and changes the texture if you tell it, and it looks like magic. Again, Gish (because Gish is cute and I'm high on a cherry Icee).

  • Free lighting. Add a new light source and everything in range instantly becomes affected without any additional coding. Along with this, free special effects - again, recall the storm scene that I mentioned earlier. You knew someone spent hours doing all that junk by hand, trying to make sure that the algorithm lit just the right pixels.
  • Free, as in, I don't have to pay for it, its a library, and my language can use it, so what the heck to do I care? =D


That's the pragmatic person in me talking. Wink

@Suule, on the issue of Furcadia graphics:

Regardless, you still need place holder graphics or you'll run into a ton of trouble down the road when you're trying to track down a visual artifact - is it a rendering bug, or is it the way you parse and load image files, is it the way you use a coordinate system onscreen; maybe it has something to do with the transformation effects you're applying for per-pixel lighting? You need place-holder graphics - even a simple stick figure - to ensure that things are not broken before you move deeper into the codebase.

I mean, writing a game isn't going to be some easy pa-cheesy 500 line thing, man.



Below is a completely uninformed ranting session that I started to write. There is absolutely no point to it, and I wouldn't read it unless you want a good chuckle or to be offended.
----
I was writing a Furcadia client, from scratch, in C#- C# - and its 32 source files, not including the unit tests I started tacking on later (I broke a previously working function and couldn't figure out where the regression was for, like, hours, so that taugth me a valuable lesson)!

That's a lot, for an application which has very little logic processing (most of that junk happens server side, and the server simply informs the client what to draw on the rendering pane, and what to display in the text pane).

I'm not harshing on anyone in particular, I'm just saying that *a lot* of thought needs to go into it before a line of code is written, or you will end up with Furcadia's graphics engine (its been so intricately woven into the code that there's no way to rip it out and start over; the guys producing it stopped or went out of business awhile ago), the way Felorin architectured Furcadia's protocol, or, worst of all, you'll end up with what I did on my first pass at packet parsing: parsing each packet individually "by hand" and generating nested switch-case trees that are impossible to maintain (I later went back and refactored all of this into a simple polymorphic PacketBase object, but its still not very clean, because Furcadia has different command packets that begin with the same syntax and have variable length - '@' means something, but '@...(some variables here)' means another thing entirely, so now you've gotta lump two completely seperate packet-types into one parser).

AKA, unnecessary work.

The one thing that my keyboarding class in high school brought me was the ability to type all of that in less than five minutes. I'm the champ, baby.
13  Game Devlopment Forums / General Game Development Forum / Game Concept: Outline on: November 15, 2004, 02:16:21 PM
Yeah, that's right, I'm the pessimist; deal with it!
14  Game Devlopment Forums / General Game Development Forum / Game Concept: Outline on: November 15, 2004, 02:13:43 PM
Quote
I'd rather write an engine from scratch. Why? Cause we can profile it to suit our needs without some nasty workarounds (which are in most cases messy).

You should really think about what you're getting into, 'specially if you're going to write a 2d engine from scratch. There are alot of things you need to take into consideration - Z-ordering, sprite lighting effects, tiling issues, perspective issues, map layout etc - that you get "for free" by using a Scene Graph like OGRE (PyOgre bindings!). Just use thin 2d quads and stretch the images you want to display over them as textures and you're done(ish).

Of course, the best reason to use a 3d scenergraph for 2d is the fact that 3d accelerated hardware is now much faster with its 3d pipeline than the 2d pipeline in most cards, so by going 2d, GDI+/WhateverDrawingSystemHere style, you'll actually be slowing your graphics down.


Also, I like Ham and Cheese.

Check out the demo: http://www.chroniclogic.com/gish/

The graphics look pretty 2d for a 3d game, eh?
15  Game Devlopment Forums / General Game Development Forum / Game Concept: Technical on: November 13, 2004, 04:30:34 PM
Alternatively, you could use a random element to determine the odds of the AI doing something "else" in response to the stimulous instead of the normal response.

I think you'd need to start using abstract classes if you did either of my suggestions, though, so you could still have different AI models.
Pages: [1] 2 3
Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Valid XHTML 1.0! Valid CSS!