Jump to content

  • Log In with Google      Sign In   
  • Create Account

MaxDZ8

Member Since 27 Aug 2002
Offline Last Active Today, 12:52 PM

#5096076 Would this be a good idea? (Episodic release)

Posted by MaxDZ8 on 23 September 2013 - 01:10 AM

This is going to sound harsh.

 

I'd say it's too expensive. Take a look at Desura, Humble Bundle or Indie Royale, a lot of games are shipping below 5USD and I got my games for 1-2 USD, including 5 episodes of a Sam and Max franchise.


that decent pc game has hundreds of devs and thousands of dollars of budget.I'm the only programmer with little to no budget
Irrelevant by consumer point of view.


buy one hour at 7$,the next part will be longer at the same price
Nonsense.


#5096070 Game Logic: Creating a Scripting Language

Posted by MaxDZ8 on 23 September 2013 - 12:32 AM

I also have my own scripting language.

My raccomandation is: give up.

Differently from others, I had extra requirements which made pre-existing scripting languages difficult to use (if possible at all). It's currently core for my game and yes, I trust it well enough.

It appears to me however this thread is considering the goal with a technical mindset only. Besides the technical, I don't see discussion about the why OP shall embark on this project. It seems OP is considering the language in a vacuum and that's not what's going to give good results.




#5095104 This beauty...

Posted by MaxDZ8 on 19 September 2013 - 12:44 AM

Amateur. I've once dealt with code written... I think in Korea. The variables were numbered up to... like 74, in a convenient 800 LOC function.




#5095098 Animation with obj mesh per keyframe in DX11

Posted by MaxDZ8 on 19 September 2013 - 12:34 AM


how can I interpolate
In line of concept, you cannot, because OBJ does not guarentee the order of vertices is coherent across different files. So you have those values somewhere but you don't know where. Consider moving to a more modern format.


#5094441 Level Generation

Posted by MaxDZ8 on 16 September 2013 - 07:37 AM


As to not get to far off track from my original question, why is the data oriented design better then the
first code example. I'm not questioning it's actual purpose or efficiency. I have just heard the name "data oriented design" before 
and would like to know what that is. You don't have to give me a full blown explanation tailored to me. I take links
It's more or less like equations, where we write x + 7 instead of two numbers. This does not come easily as we have to write stuff that adapts to every (meaningful!) configuration for us, thinking in advice what we need. Of course if I tell you what amounts to x + 7 you cannot give me an answer and similarly in code we cannot get a solution... but we have to write code which somehow outputs the correct solution for us every time. We do that by exploiting properties the data is guaranteed to have and to define those properties we need to define the problem.

 

So for example in a tiled world we might be interested in knowing, for each cell in the world (not each tile):

  1. how it look?
  2. is it passable?
  3. if passable, sound of footsteps
  4. if passable, deals damage?

So we might want for example to make a specific cell passable even though it typically isn't, because that's a classic for hiding secret goodies: going through a nonsolid wall. In general we have to decide which property is part of the world cell and which is part of the tile itself.

Instead of defining properties in code we define them in the data itself.

Let's assume for easy explanation we load each tile graphics from a file. Then the actual tile graphics data is not really relevant: we just have to load it up completely, pack it in a texture and draw a quad measuring - say - 2x2 world units.

 

But now I'd stop there and let you figure out what you need to pack in your world.




#5092627 Particle Collision

Posted by MaxDZ8 on 09 September 2013 - 12:22 AM


How would you go about determine if a particle collided with something? We finally got GPU particles working but for rain we want it to create a new particle on collision with the ground. How might one go about doing this?
The first "new gen" stuff I recall is Lutz Latta's "Building a Million Particle System". Also called "UberFlow". The performance was nothing short of incredible, considering it run on midrange Shader Model 3. It apparently ran on Shader Model 2 as well but I'm not sure.

I cannot find the original resource, but this presentation from AMD seems to include it.

Note that this system can make particles collide and react to height fields.

 

Another presentation from GDC2007 covers particle effects from a game in the Command & Conquer franchise. You might notice some similarities with Uberflow but it provides a major update and several artistic reasoning when it comes to why instead of how.

 

Main problem is essentially finding a way so particles can collide with arbitrary geometry without killing their perf. So far the only sure thing is that you cannot just push the whole collision geometry data to a PS. Will you go for the "subset" approach? Or maybe you'll prefer voxelization? I'm torn myself.




#5091740 Venting via Twitter

Posted by MaxDZ8 on 05 September 2013 - 02:06 AM


How do you all deal with the day-to-day minutiae of corporate life?
I vent on social networks as well. Most of the time, nobody understands. And that's fine for me.


#5091733 no gpu onboard ?

Posted by MaxDZ8 on 05 September 2013 - 01:49 AM


for example external gpu are
5x, 10x (?) faster?
Goes like this:

Intel - it or miss. Often not properly documented in leaflets. HD4000 (some ivy bridge chips) is minimum considered decent. Haswell chips have a "Crystalwell" option, 128MiB of L4 cache. This is the fastest integrated option and the most expensive, marketed as "Iris pro" if memory serves.

Intel graphics is not really an option for gamers. HD4000 is the turning point as it's more or less as powerful as a card worth 50 bucks. Crystalwell is a real game-changer, I'd say it's as fast as a 80 bucks stand-alone card.

AMD graphics is better (with Crystalwell being the exception). Worth, at best 65-70 bucks.

In the end, they all get trashed by cards worth 100.




#5090089 what's the C++/OOP way to implement this architecture ?

Posted by MaxDZ8 on 29 August 2013 - 06:21 AM

Going defensive much?

You don't need to.

I think you should start writing something (regarding this) if you haven't already.




#5090013 Pushing Objects in Bullet Physics

Posted by MaxDZ8 on 29 August 2013 - 12:07 AM


The above methods doesn't move the object according to the hit point, I have btVector3 rayHitPoint
Then I suppose you need applyImpulse or applyForce. You might have to start using the documentation sooner or later Medo.


It doesn't work, though I also need to determine "how much impulse will be applied"
You're really supposed to work with "force". The impulse is a different thing and does not make much sense in terms of realistic simulation but it comes handy for artistic purposes. The applied force depends on the game logic, in the real world it's often constant for bullets in the sense they are pushed out of the firearm with a known, fixed force.


#5089098 Pushing Objects in Bullet Physics

Posted by MaxDZ8 on 26 August 2013 - 12:32 AM

If the object is dynamic, just resolve the collision ray, cast the obtained object to btRigidBody and apply and impulse to it.

Ok, it's not so easy. Many things can go wrong:

  • I assumed the object was dynamic but that could be not the case in reality. It could fail to cast to btRigidBody  or
  • it could still cast correctly but be a kinematic or static

In the end this will only work if the object is properly authored (but that's hopefully an easy assumption).

 

If the object is static... I suggest to give up. It's not impossible to destroy it and re-create it dynamic. It might even make some sense in many situations. It didn't in my last project and sure you need some static objects to stay static whatever happens to them. In general, there are artistic reasons for which some objects cannot move, beyond the technical.

 

Kinematics are the real trouble. I think there are good gameplay reasons for which they shouldn't be moved at all but in the past I had a long discussion with a designer that seemed to think otherwise. The main problem with pushing kinematics is what I dubbed "kinematic invariance problem". A kinematic object, when pushed should be working as a purely dynamic object. This is not the case: if you just write your own integrator, there's a high chance its behaviour won't match dynamic.

 

But I suppose you'll be happy with just pushing dynamics around, are you?




#5089094 So how does this look?

Posted by MaxDZ8 on 26 August 2013 - 12:10 AM

Pretty good! You know, I never had the time to deal with vegetation so I appreciated it a lot.




#5089093 Using padding to make vertex structures align?

Posted by MaxDZ8 on 26 August 2013 - 12:08 AM

In my experience, padding was irrelevant on most, if not all hardware I tested.

That said, I stopped collecting so accurate data a few years ago as the hardware grown far beyond my necessities. If there's not enough workload then there's nothing to measure. I usually spend 10-15% on vertex transform so I sure wanted to focus on pixel techniques.

Whatever this will be your case it's an open question but I suggest to just move along.




#5089092 what's the C++/OOP way to implement this architecture ?

Posted by MaxDZ8 on 25 August 2013 - 11:59 PM

There's a major difference between live data (in RAM, workable) and storage data. The concept of serialization is the bridge between the two things and I don't really suggest to even try doing it in a different manner.

Truth is even OOP is a buzzword. Yes, it gave us much more than many other methodologies, but don't take for granted it's the only thing in existance. When sending stuff over the wire (or to storage, for that matter) OOP does not hold much. You must send bits and will get bits, trying to convince yourself otherwise is trying to live in an abstract world. It's just numbers and conventions. The hardware will send you numbers, you will work with numbers. Period.

 

I think the main fallacy in your line of thinking is to draw a single "databases" block while there are clearly different databases involved. I strongly believe you didn't get the whole point of what OOP is, consider:


i'm sure there are other places where this situation arises as well. I think it stems from the OO vs non-OO way of looking at data.  Apparently, in OO, it not uncommon to take "everything is an object" literally, and to the extreme. To the point where individual records in a database become objects, and perhaps even fields in those records. The result would/could/might be a proliferating tree of objects on the heap. Add in creating and destroying objects on the fly, and you have a constantly changing giant rats-nest tree of objects possibly/probably fragmenting the heap.

The inference OOP-->objects on heap is wrong. OOP itself does not mandate heap usage, much less heavy usage fragmenting the heap.

The point is that you have "blobs" of data which you don't modify directly but use specific functions instead. In many OOP languages, the functions are "near" the data they manipulate. But they don't have to be! OOP is possible in C and even ASM.




#5087228 Correct way to implement a scripting language for game logic.

Posted by MaxDZ8 on 19 August 2013 - 02:07 AM

Without elaborating your design, it could be ok or not. So let me check if we are on the same mind set. Let's do that easily by considering items first.

Suppose we have:

  1. food - decreases hunger attribute by F
  2. potion - increases health attribute by P

This does not need scripting. Data-oriented design is sufficient.

Enemies are a thougher call. In general, enemies need to have a set of skills which is where scripting comes into play. Personally I would never allow a script to fully define an enemy: there must be a basic set of properties about them. I'd rather allow script callbacks to evaluate its attack logic or skill use.

In my experience, having a generic Update() call to be shared across all entities is a bit fragile in concept. Better to have things such as RunEnemyLogic() or Tick(time) if everything fails. I don't have an Update() call in my system - distributing script processing is left to the script itself.

So the enemies might be:

  1. man { model: "man.mdl";  skillSet="humanSkills.lua";  skillList="hide, evade, attack"; };
  2. goblin { model: "goblin.mdl";  skillSet="gobSkills.lua";  skillList="attack, fury, resistance"; };

Of course in this case you'd have to figure out a way to maintain, for each "skill" loaded and bound to each actor, a way to maintain its state and design all the proper interfaces. Allowing to "just do everything" might make sense but I'm not quite sold on it.






PARTNERS