Excuses for the somewhat lacking amount of posts last weeks… months. The reason is not that we’re doing nothing anymore. But there is simply no visual eye-candy at the moment! Busy with upgrading physics and that entity system at the moment. So I could show you some dull movies of tumbling boxes, buoyancy physics with still some errors, or Micheal Jackson ragdolls that get an epileptic attack (don’t worry, doctor Sascha Willems is on it). But then I could better refer to some REAL physics for now:
http://www.youtube.com/watch?v=qMAaza_rrxQ
1:33 is even more badass than Charlie Sheen. If I ever make a RTS game, that’s how the physics should look. 2:32 reminds me of squeezing pimples BTW.
Anyway, instead of pictures, I might interest you with some more story bits… Morgan Freeman, up to you.
============================================================================
Story fragment #2
============================================================================
"
For some reason, I can't recall how this flat -number '22'- looks from the outside. It feels as I've been working here all my life really... But judging from the interior, my guess is that the building looks pretty much the same as the other gray concrete monsters around here, except that it's a lot taller. Don't know the exact height, neither when this block was built. Probably somewhere in the late fifties. Although some parts here look a lot older already. But that just might be deferred maintenance as well.
Just like other buildings, it has a few elevators, a stairhouse, and endless corridors. Dark, old, corridors with countless doors. Closed, unnumbered anonymous doors, telling nothing about who might live there. The wallpaper and paintwork can be peeled off just by looking at it. Bugs found their way in the little holes and gaps. Some ceilings were left unfinished, revealing the rusty beating pipes and electric wires above them. Not uncommon either, the building has a couple of shared facilities here and there. Such as a laundry, or showers and toilets for the apartments that aren't connected to the water.
The same goes for the apartment interiors. We all share the same collections of furniture, thin mattress beds and kitchen sets. Some bright plastic utilities, flower curtains and small cheap decorations to add a little bit happiness to the otherwise depressing, pre-fabricated rooms. The apartments just do what they have to do: provide shelter and warmth for the cold winters.
Though I must say there are some impressive halls and wall paintings scattered around the building. Ones you would find in a church, or stately building. Who would have made them? I can't imagine they were part of the original design for a building like this.
When thinking about it, I noticed more and more uncommon details. For one thing, many of the windows are barricaded or just not there. It's hard to get a glimpse on the world outside here. Another thing that strikes me is the unusual floor lay-out. You would expect the elevators, central stairs and main corridors to connect all the apartments in a logical manner. But from what I have seen so far, not a single floor looked the same. Elevators aren't working or only bring you at a few locations. Stairs just stop at some point, and the hallways are mangled like a maze. Clearly the architect didn't follow his study here, where simplicity and efficiency are basic construction fundaments.
My work brings me at places where a normal person wouldn't or shouldn't come. Such as maintenance area's or ducts. With such 'privileges', one would think I could dream this building by now. But I feel there is a whole other world behind the locked doors, service ladders and twisted hidden shafts. In fact, in combination with the absence of anything alive except the crawling bugs so far, I'm feeling... claustrophobic. Scared actually.
I asked for a map, a layout of the building. But apparently, there is none. Again the Boss didn't really answer my request. Just a vague reply. Words like "The doors will lead your way, or block your way where you are not supposed to come.". Guess I'll have to make a map and notes myself on a piece of paper. Before I get lost some day.
"
Monday, April 18, 2011
Monday, April 4, 2011
Puppeteer Part #2
Nice. Our cry for someone who can solve E=MC^2 formula's has been answered by Sascha Willems. If you think, "Hey, I heard of that name", then you are right. He is a moderator on the Newton forums, made Delphi headers to use the DLL’s, and part of the Newton development team. So... guess I can't get much closer to the source! Well, I just wrote a document with 100 and one Physics questions he can hopefully answer. I guess some of the questions + answers can help other Newton users as well, so I was thinking about publishing that document once it got answered.Either how, this subject will surely return a couple of times on this Blog.
www.saschawillems.de
Another little detail I forgot to mention is the (prototype) logo on top of this Blog. Just a little present from a good friend who has his own business in logo & design since a while:
www.pixelridder.nl
Last but not least, in case you missed, we gave our engine a name…. Engine22. Not as brilliant as “Source”, but yet I like its simplicity. It doesn’t change the quality of the game, or how Earth orbits around the Sun, but it’s nice to call the beast with a name.
Off topic. Quick drawing by Jesse. Nitpickers as we are, sketches should help the modelers with details like these, rather than just go ahead and poop some polygons. Atmosphere is key baby, so every stupid wooden panel is handmade craftwork. The expected release date for Tower22 is May 2086 BFSM (Before Flying Spaghetti Monster) by the way
-----------------------------------------------------------
Back to the “input & output” story then. Previous time in The Bold & The Beautiful, we made an Input module. To register keypresses, mouse motion, sweat sensors and lightsaber velocity. Yeah, with some hardware knowledge you can do whatever you want there. Measure the player heartbeat, use the room temperature, make your own exotic joysticks, Duckhunt Zappers, dumbbell sensors for your own Dolph Lundgren fitness game, install a Boeing cockpit in your room and so on. The Input module abstracts the physical input to a listing of common controls that can be used in most types of games. And otherwise it's easy to extend.
But the real question is, what to do with it? Unlike earlier (messier) engine attempts, I made a strict difference between Input and Output this time. The Input module isn't aware at all of the game status. It doesn't know if you are controlling a HUD menu, Haiku Robot, or Lara Croft. Neither does it know which buttons are allowed or not. It just registers input, that's it. What to do with it completely depends on "the others"... whatever that is.
Sounds pretty simple, but there is a catch. Where exactly do we code the output? Didn't I say to keep game/entity specific actions apart from the core-engine? You don't have to follow my advice, but personally I don't want to litter Engine22(yeah) entity system with stuff like
- "player spawns 20 blood decals on bullet hit"
- "tanks accelerates forward when FORWARD is pressed"
- "Goku charges up powerlevel to a maximum of 45.000 while bashing the ACTION2 button"
You could try to make a super-entity that can do everything in the world, but that is asking for failure. Abstracting everything makes hard-to-understand and/or lacking code that just doesn’t do what you really want. Instead, like you do in small specific industrial applications, focus on the specific task. More effective, faster, less error-prone, and especially more fun. Finally you feel like you are programming an actual game!
To break up this large piece of text, just some relaxing carpet. A dull screenshot indeed, but carpetting the building has to be done as well. It should be somewhat more spectacular as soon as the carpet layer makes some holes and throws around carpet-tiles...
Right, that means we have to move the specific "game-logic" elsewhere. I'm not 100% done with the design, but I have some ideas... Half a year ago I mentioned Python scripts already. In short, when the engine detects a certain event such as onBulletHit(), onUse() or onSectorLeave(), it can call a Python script for the specific execution. Each entity (a barrel, player, monster, shotgun, …) can have its own script. Since Python scripts are external files, you can do whatever you want here. And also adjust whenever you want without needing Delphi, MS Visual Studio or other tools. Python scripts compile at run time, so you don't have to rebuild the Game project when you just added a "player health = 9999" cheat in the player script. That also means you can screw up the game any time you want :D
This is effective, but it still has some downsides. So far I used Python scripts for rather simple tasks that are only executed when X happens, not every cycle. Updating complex tasks like physics, controls, animations, AI and pathfinding each cycle (more than 30 times per second) might be too much. I have no idea how slow or fast Python really is, but it IS slower than normal compiled code. That's for sure. Maybe updating one entity isn't much of a problem, but how about 10. Or 100? I'm not taking the risk, neither do I buy "That few milliseconds don't matter as long as it works". That's a lazy approach sir.
Asides from speed, Python isn't as flexible than your trusted uncle Delphi. For real complex stuff I still prefer a traditional language (or at least I don't know Python that well). So... what to do now? How about making entity DLL's?
Instead of letting the engine fool around with lots of specific actions, let the DLL do it. Yeah, even maintaining a simple "health" value can be different for each entity. Some are immortal, some are sensitive for headshots, others bounce back bullets, others explode when they got hit, etcetera. So, remove "health" and all the possible effects from the core-engine, and let the DLL (or script) do the job call.
The Engine is doing less and less… specific action is moved to the surrounding units, making the Engine more like a “manager”. All rendering functionality is (still) inside though. Even though we could move that to an external unit as well of course.
Engine22 only does what all entities should do when getting updated, hit, spawned, or whatever event there is. The DLL and/or Script tell the specific output by using the API delivered by the engine. API? Yeah, Application Programming Interface. Engine22 has a large list of varying functions that can be called by Python scripts. And also by DLL's now.
In Delphi terms, we just pass an "Interface" type towards the DLL when it asks for it. This interface is just one big listing of method pointers, towards the engine. You don't have to do it that way of course, but it looks nice. Either how, we can call those functions whenever we like. The beauty is that you can drop the choking "keep it universal" way of thinking once you are in your DLL. Sure, using some frameworks helps, but basically you can code whatever you want here. Ah.... it almost feels as good as when I began with programming games 10 years ago. No worries.
Some of the DLL & API functions...
Next time, in the last part, I’ll give some example code to illustrate some common game mechanics. In the meanwhile, eat your vegetables!
www.saschawillems.de
Another little detail I forgot to mention is the (prototype) logo on top of this Blog. Just a little present from a good friend who has his own business in logo & design since a while:
www.pixelridder.nl
Last but not least, in case you missed, we gave our engine a name…. Engine22. Not as brilliant as “Source”, but yet I like its simplicity. It doesn’t change the quality of the game, or how Earth orbits around the Sun, but it’s nice to call the beast with a name.
Off topic. Quick drawing by Jesse. Nitpickers as we are, sketches should help the modelers with details like these, rather than just go ahead and poop some polygons. Atmosphere is key baby, so every stupid wooden panel is handmade craftwork. The expected release date for Tower22 is May 2086 BFSM (Before Flying Spaghetti Monster) by the way
-----------------------------------------------------------
Back to the “input & output” story then. Previous time in The Bold & The Beautiful, we made an Input module. To register keypresses, mouse motion, sweat sensors and lightsaber velocity. Yeah, with some hardware knowledge you can do whatever you want there. Measure the player heartbeat, use the room temperature, make your own exotic joysticks, Duckhunt Zappers, dumbbell sensors for your own Dolph Lundgren fitness game, install a Boeing cockpit in your room and so on. The Input module abstracts the physical input to a listing of common controls that can be used in most types of games. And otherwise it's easy to extend.
But the real question is, what to do with it? Unlike earlier (messier) engine attempts, I made a strict difference between Input and Output this time. The Input module isn't aware at all of the game status. It doesn't know if you are controlling a HUD menu, Haiku Robot, or Lara Croft. Neither does it know which buttons are allowed or not. It just registers input, that's it. What to do with it completely depends on "the others"... whatever that is.
Sounds pretty simple, but there is a catch. Where exactly do we code the output? Didn't I say to keep game/entity specific actions apart from the core-engine? You don't have to follow my advice, but personally I don't want to litter Engine22(yeah) entity system with stuff like
- "player spawns 20 blood decals on bullet hit"
- "tanks accelerates forward when FORWARD is pressed"
- "Goku charges up powerlevel to a maximum of 45.000 while bashing the ACTION2 button"
You could try to make a super-entity that can do everything in the world, but that is asking for failure. Abstracting everything makes hard-to-understand and/or lacking code that just doesn’t do what you really want. Instead, like you do in small specific industrial applications, focus on the specific task. More effective, faster, less error-prone, and especially more fun. Finally you feel like you are programming an actual game!
To break up this large piece of text, just some relaxing carpet. A dull screenshot indeed, but carpetting the building has to be done as well. It should be somewhat more spectacular as soon as the carpet layer makes some holes and throws around carpet-tiles...
Right, that means we have to move the specific "game-logic" elsewhere. I'm not 100% done with the design, but I have some ideas... Half a year ago I mentioned Python scripts already. In short, when the engine detects a certain event such as onBulletHit(), onUse() or onSectorLeave(), it can call a Python script for the specific execution. Each entity (a barrel, player, monster, shotgun, …) can have its own script. Since Python scripts are external files, you can do whatever you want here. And also adjust whenever you want without needing Delphi, MS Visual Studio or other tools. Python scripts compile at run time, so you don't have to rebuild the Game project when you just added a "player health = 9999" cheat in the player script. That also means you can screw up the game any time you want :D
This is effective, but it still has some downsides. So far I used Python scripts for rather simple tasks that are only executed when X happens, not every cycle. Updating complex tasks like physics, controls, animations, AI and pathfinding each cycle (more than 30 times per second) might be too much. I have no idea how slow or fast Python really is, but it IS slower than normal compiled code. That's for sure. Maybe updating one entity isn't much of a problem, but how about 10. Or 100? I'm not taking the risk, neither do I buy "That few milliseconds don't matter as long as it works". That's a lazy approach sir.
Asides from speed, Python isn't as flexible than your trusted uncle Delphi. For real complex stuff I still prefer a traditional language (or at least I don't know Python that well). So... what to do now? How about making entity DLL's?
• Each entity can(doesn’t have to) be assigned to a DLL
• DLL does the cyclic update, physics, events, queries from other objects, handling the input, etcetera, etcetera
• DLL gets access to the Engine API so it can call all kinds of things (render something, apply force, get another entity, play sound, and so on).
• Most “simple” objects like a stupid box or chair can all do with the same DLL. So don’t worry, you won’t end-up with thousands of little programs.
Instead of letting the engine fool around with lots of specific actions, let the DLL do it. Yeah, even maintaining a simple "health" value can be different for each entity. Some are immortal, some are sensitive for headshots, others bounce back bullets, others explode when they got hit, etcetera. So, remove "health" and all the possible effects from the core-engine, and let the DLL (or script) do the job call.
The Engine is doing less and less… specific action is moved to the surrounding units, making the Engine more like a “manager”. All rendering functionality is (still) inside though. Even though we could move that to an external unit as well of course.
Engine22 only does what all entities should do when getting updated, hit, spawned, or whatever event there is. The DLL and/or Script tell the specific output by using the API delivered by the engine. API? Yeah, Application Programming Interface. Engine22 has a large list of varying functions that can be called by Python scripts. And also by DLL's now.
In Delphi terms, we just pass an "Interface" type towards the DLL when it asks for it. This interface is just one big listing of method pointers, towards the engine. You don't have to do it that way of course, but it looks nice. Either how, we can call those functions whenever we like. The beauty is that you can drop the choking "keep it universal" way of thinking once you are in your DLL. Sure, using some frameworks helps, but basically you can code whatever you want here. Ah.... it almost feels as good as when I began with programming games 10 years ago. No worries.
Some of the DLL & API functions...
Next time, in the last part, I’ll give some example code to illustrate some common game mechanics. In the meanwhile, eat your vegetables!
Subscribe to:
Posts (Atom)