Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

1210 Excellent

About SimmerD

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. SimmerD

    ndotL environment mapping?

    The idea here is twofold : 1) there is a tradeoff between diffuse & specular reflected energy.  more diffuse reflections mean less energy available for specular and vice versa.   2) when N dot L is zero, N.H ( or R.L ) should be zero too
  2. There is Marmalade, which has great Windows Emulation Testing, but even its samples are crashing on Android for me right now. Marmalade has both high & low-level interfaces, including in app purchaes, etc. For android, I am using the free nvidia tegra development kit, which has native visual studio debugging on android devices!  This is only low-level graphics and input. I have also used libcinder on windows, which is low-level also.   I made my engine so I can just write three files, System.cpp and Render.cpp for each platform, and then a main.cpp to drive the update,input and rendering.
  3. SimmerD

    When you realize how dumb a bug is...

    This one is old-skool.   My buddy Brad and I were making an Ultima-style RPG in 1983 or 1984.  It had world maps, dungeons, temples, catacombs, towns, etc.  We were at his place working on the tactical combat.  I was trying to add the fireball spell, and every time I typed in the section of code to handle the fireball hitting an enemy, the entire program would be wiped from memory!  This was sooo bizarre.  Our code was a mix of AppleSoft Floating Point Basic and assembly.   We even went so far as to call Apple to try to report the bug in the Basic code.   While trying to make a smaller repro case than our entire game, we realized the bug.  In AppleSoft Basic, only the 1st two letters of a variable are used, and it's interpreted, so commands are executed as they are parsed.  One of our variables was called FP, which was the command to re-initialize basic, and clear the program from memory.  
  4. My dad brought home an Apple ][+ ( 48k of ram! ) christmas 1982.  He knew COBOL, and taught himself BASIC, and taught my sister and I when I we were 13 & 12.  He made a program with 'for loops' that cleared the screen horizontally.  Then I changed it to make it vertical, then diagonal.  Then I made a sort of tron-light-cycle game.  The next year I met another kid at my school who knew basic.  I had started learning assembly, so we hooked up and made some very innovative half-finished games. We even did digital audio recording through the cassette port & playback through the speaker. We each made flood-fill routines, and also fast 14x14 sprite renderers, and a complete Ultima 3/4 type RPG engine.   I got an austin computers 286 16mhz pc in 1988, and taught myself x86 assembly & EGA/VGA low level rendering.  I made a 3d voxel engine in 1992 all in assembly.  All assembly was really hurting my productivity but MS Quick C was confusing as hell to me.  When a friend taught me Turbo Pascal, I was in heaven, and I shipped my first complete game, Hubie in 1996 using Borland pascal & inline assembly.  That same year I saw a 3dfx voodoo prototype, and started to learn more 3d.  Soon after, I learned Direct Draw, Direct 3D 1 & 3, then started at nvidia, learning direct3d 5/6 and gpu programming in general.  Over the next few years I was in the right place, time & role to innovate in a number of graphics areas, such as per-pixel lighting, attenuation maps, shadows anti-aliasing, etc.   One thing that I did a lot was to lurk in game & graphics programming forums.  I've found need a long gestation period to really grok something, so that helps me by seeing something repeatedly over a long time period.  Then I can connect new ideas with old things I've read about or done.  Another thing I'm learning about myself is that my most innovative periods are tied to meeting and working with new people, so I recommend meeting with like-minded folks. 
  5. I have made many changes since my last post, mostly in two areas, sound tracing, and NPC crystal usage. The sound tracing is a system whereby I trace sounds from their source, through portals, towards the listener ( usually the player, but sometimes the camera ). When the listener is in a different cell than the source, then the sound appears to come from the portal, rather than the actual sound source. The volume is also attenuated based on the linear distance from the source, to portal -> portal -> listener. There were latent bugs in the sound tracing system that were only exposed when we expanded the 1st level of the game - issues where there were multiple paths from the source to the listener, each one of similar distance. There were some overly aggressive optimizations not to re-consider a cell already considered which were causing shorter sound paths to sometimes not be considered. This caused a sound to be heard when touching the portal, but not heard ( due to being culled ) when just outside the portal. Very distracting. For a while I experimented with disabling the system, and just leaving the sounds at their true source positions, but since the sound tracing feature has been around so long, the levels sounded really bad without it. I ended up making several fixes, each of which would solve another issue, which would expose another bug, some of which were recently introduced. Anyways, right now I believe the sound tracing system is close to bug-free. Another small change I made was to make closed doors muffle sounds, in proportion to how closed they are. A nice effect when you are opening a door into an area. There are many, many gotchas when doing a sound tracing system. Perhaps I will write them up one day. The other change was pretty minor in terms of code, but seems to add proportionally more to the game is the ability of NPCs to use power-up crystals if they have one in inventory. They don't always use them, however, so the player can find some on NPC corpses. At this point, we're just making some minor adjustments and fixing any remaining issues that come up, and then we will release the next version.
  6. SimmerD

    1.2 Almost ready...

    Every time we add a new level, it exposes latent bugs in the code that didn't show up in other levels. We are adding another area to cavecity2 ( the last area of the shareware levels ), and in it is a winding ramp. Going down this ramp caused the camera to jump around in an unusual way that didn't happen anywhere else in the game. Turned out it was the code added a few weeks ago to make sure the player wasn't obscured by something. In this case, the code just snaps the camera to a safe place near the player. It was getting triggered b/c going down the ramp, you tended to get your arms sort of through the wall while your physics capsule was in the right place. This caused enough of the raycasts to fail, triggering the safe area re-set. Just outside the ramp were some black triangles only meant to obscure the mini-map, but that material was set to physically impede the camera, which was causing more issues. Fixing the material and also making the raycasts more bunched towards the capsule rather than the character's visual bounds fixed the issue. The new AI code is working great - the Patrol state, which previously would get put off track rather easily, is working, and we added some debugging to give context when it fails. I added a character speed adjustment to make the walk & run cycles more realistic. Now one of two sine waves are mixed into the movement speed of each character, making for a better looking and more rhythmic movement. Then, I added a bit of camera up/down bob to match for the player, which is subtle but feels better.
  7. As I'm wrapping up the 1.2 Ancient Galaxy patch, I think back on some of the challenges I've had with the AG Engine and why it can be somewhat of a cumbersome codebase to work with - similar to other complex software systems. A largish piece of it is the fact that so many data and logic dependencies in the engine and game become implicit, and not articulated in any sort of manner that can be automatically checked ( like by the compiler, for instance ). I been thinking one way to improve things would be to add explicit dependencies into the core of an engine, as a fundamental concept. A limited version of this would be ref-counting, where you at least prevent pulling an object away from another that's using it, although there are no guarantees w.r.t what state the object might be in. Rather than ref-counting, which only tells you how many folks care about you, you might do reference linking, where you have a pointer back to the interested parties. With this you can create a rudimentary subscription ( or signal/slot ) model. The next step would be to have an all-seeing, all-knowing subscription manager class that could manage subscriptions, something like this : struct Subscription { enum NotifyType { ntNone = 0x0, ntRead = 0x1, ntWrite = 0x2, ntConnect = 0x4, ntDisconnect = 0x8, ntFrame = 0x10, ntPause = 0x20, ntUnPause = 0x40, ntCreate = 0x80, ntDestroy = 0x100, ntUpdate = 0x200, ntSceneAdd = 0x400, ntSceneTraverse = 0x800, ntSceneRemove = 0x1000, ntContact = 0x2000, ntTrace = 0x4000, }; enum NotifyWhen { nwPre = 0x0, nwOn = 0x1, nwPost = 0x2 }; uint32 _datum_id; uint32 _scope; uint32 _flags; uint32 _subscribee; std::vector< uint32 > _subscribers; // can hold history here, rather than in subscriber or subscribee Datum::Value _history[ 16 ]; class Mgr { std::map< uint32, Subscription > _subscriptions; public : typedef void (__cdecl* Notify )( ( const Datum* const pDatum, const Subscription* pSubscription, const uint32& notify_type, const uint32& notify_when, const int32& datum_age ); One potentially interesting idea possibly beyond a standard signal/slots mechanism is the history, which can include the previous values of the data, for weapon trails, interpolation, etc. It could also be useful for futures and reading 1-frame behind data. You would subscribe to history -1 for the last frame, choose 0 for this frame, etc. I also like the separation of the Pre/On/Post flags from the subscription type. That way any subscription type can be combined with the Pre/On/Post flags to allow you to hook in where you need to. The scope value is there as a differentiator, for instance, an object may get added to multiple scenes, so you could have different scopes that would have separate subscriptions. It seems this would allow things to be more data-driven, which can be good, but also places a larger burden on having tools to display & manipulate these dependencies...
  8. SimmerD

    AI & Camera Tweaks

    Made some more AI tweaks. The AI NPCs now will investigate a suspicious sound, and track the average location of various dangerous sounds they hear over time. This is known as the 'seeking' state. This makes them gang up on the player, sometimes way too much, so I added a quota so that only so many guys can be seeking the player at one time - right now this is set to 4. Now, other NPCs can be attacking the player at once, but only 4 can be seeking him out. Also, the enemies are more apt to detect the player's disguise when in Seeking state. In addition, I added a little bit more camera physics. There was one case where the camera wasn't acting like a physical sphere, and it rarely caused the camera to move outside of the level. The camera now acts like a ~1.5 meter radius sphere that tries to stay at an ideal user-tweakable player-relative position. It moves around physically, except if the player is completely hidden from view, in which case it 'cuts' right behind the player, then resumes it's physical sphere status. This is cut behavior very rare, but prevents much worse cases of the camera sphere getting stuck somewhere on the level and the player's character just wandering off.
  9. SimmerD

    Sound Paths

    Ran some in-game profiling over the past couple of days and found sound pathing tracing taking more time than I'd like. Ancient Galaxy has a system to trace sounds from their source through portals into other cells, and then to the listener itself. This has the effect of making sounds appear to come through portals rather than a straight shot from the sound source if the listener is at least one room away from the sound. It works really well most of the time, but can be a bit expensive to trace the sound paths from room to room every so often. I was considering adding a precomputed data structure to speed this up. Basically the sound path goes SoundSource->Portal->Through Cell->Portal->Through Cell->Portal->Listener The paths are re-computed every so often, if the sound source moves or the sound is a looping sound. I realized, though, that only the SoundSource->Portal and Portal->Listener parts need to be recomputed. The interior part, which could be 7-12 rooms longin some cases, doesn't need to be recomputed, and could actually be cached or completely precomputed. Each Cell or Portal could store its potentially connected portals, up the the limit of some level-specific sound distance cut-off. That way, only the ends of the sound path would by dynamic. It turned out, though, that looped sounds were getting recomputed every frame, rather than only several times per second, so after fixing that, it doesn't look like I will need to speed things up any further in this regard. In the future, I'd like to revisit this part of the engine and add environmental effects. Also sped up the particle system, a couple of camera tweaks, and confirmed that the re-factored AI is still working well...
  10. SimmerD

    Stately Progress

    These changes will be part of the 1.2 patch, which should be the final patch for the retail game. If we get enough interest, we may do an expansion pack or a sequel, in addition to releasing the level editor.
  11. SimmerD

    State Lines

    Yes, I did think about this. The stack would work, as long as I could query states further down the stack for information and context. I initially threw out the stack idea, because I was thinking that states couldn't know about their parents, and then realized that you don't have to do it that way! ;)
  12. SimmerD

    Stately Progress

    I'm happy to report that the re-factoring of the AI code is complete, and was a success! Not only did I fix the main issues that I wanted to address, namely enemies and friendly NPCs occasionally getting stuck and/or lost, but the changes also fixed the Patrol state. Patrol is where the designer has specified a # of triggers to walk to in some sort of order. A Patrol path can be linear or a cycle, and can have random elements as well. There was one level in particular when a group of Aakash lizard-men were supposed to follow the player, and they would usually get stuck or be so slow that the player only encountered the first couple of NPCs - now it works as expected, and that level is now much more exciting. The basic shooting/hiding mechanism for combat works better too - the NPCs just move a lot more fluidly.
  13. SimmerD

    State Lines

    Over the last few days I have been re-factoring the AI code in Ancient Galaxy. It was written by another programmer, and was pretty good for the initial cut of it, but I didn't really take full ownership of it and re-think it later on, and now it's gotten out of control. The original design had a Brain class, that contained a single current BrainState, which could be one of Waiting, Searching, Pathing, Wander, RePathing, Walking, Shooting, Hiding, etc. This breaks down when you want the AI to be in more than one state at once, or remember what it was doing before, say Pathing. This was done in an ad-hoc manner of remembering a 'DestinationState' which was the state to do next. Part of the issue was that the DestinationState was what to do next if things went well. If you lost your target, couldn't make progress on your path, etc, it wasn't always clear what to do next. I experimented with the idea of going for BehaviorTrees, which I have been using at work, but didn't want to implement a completely new system, and wanted the existing levels & save-games to work with any changes. So, the current plan, which I have coded up, and am about to begin testing, is to have three concurrent states in the Brain class. One Main State, which would be the AI's overall positioning & behavior strategy, like Flee, Wander, Follow, Patrol, None, etc. One CombatState, which can be Shooting, Hiding ( for reloading, etc. ), Charging, None One PathingState, which can be Pathing, RePathing, Searching or None. The desired position-choosing logic used to be clustered in the Searching state, which used code like if ( mDestinationState == "Charging" ) // choose a spot near the target to choose a place with a good Line Of Fire, or a poor one ( for cover ), or near or far from the target, etc. The new code uses virtual functions on the Brain states to get things like desired location bounding boxes, location evaluations, movement speeds, etc. The Main State provides the bounding box of where to even look for navnode spots to go to. The Brain then chooses spots randomly inside the box. The Main State then gets to veto or evaluate these spots, then, if not vetoed, the Combat state can then chime in and veto or evaluate the remaining spots. Then the spot is selected randomly based on its desirability. This way, the friendly NPCs can Follow the player, but still find Shooting and Hiding spots to attack enemy NPCs. It feels great to rip out and simplify a bunch of code, but I'll let you know how it works out in game...
  14. SimmerD


    This morning I made some fixes to the 'Slow Crystal', formerly known as the Pulse Crystal. This is an orange power up that lets you slow down the rate of fire, rate of reload, rate of shield regen of nearby enemies, and also shuts down their current shield. I also made it slow down projectile speed as well, which is helpful for avoiding the rocket-like shots from the Higgs Pistol. Also did some work on the new Blue Rescue crystal, which we are calling the Amplify Crystal, representing its new role in amplifying teleport signals. Also made some minor level editor fixes, and adjusted the default camera setting.
  15. SimmerD

    Return to The Ship!

    In Ancient Galaxy, you have a spaceship that is used as a home base - a place to store, manufacture & analyze weapons & crystals, as well as a place to clone into an alien species. We have been getting requests for the ability to go back to your spaceship without dying. Currently the only way to do this is to complete a level successfully and use a teleporter found in the level. Taken too far, the ability to go back on a whim has the potential to ruin the gameplay, but we see that it could be a good addition to the game if it is limited in some way. One of the main changes that we will make is to change the way the Blue Rocks, Stones and Crystals work in order to provide this ability. The current behavior of the Blue Rescue crystal will be gone - that is, the ability to mark a location & return to it later upon death. So, in the new version, your ship will gain the ability to pinpoint your location whenever you use a Blue Rock, Stone or Crystal. The ship's teleporter has difficulty locking on to a single lifeform next to a large planet filled with other lifeforms and a huge mass differential compared to your body, so the Blue crystal element acts as a focus for the ship's teleporter beam. The crystal GUI will display the signal strength that the ship is experiencing in locating you, which is reduced by having other lifeforms or energy discharges nearby and being indoors or without a good view of the sky. Higher crystal strength ( Rock->Stone->Crystal ) will help the ship overcome this issue and beam you aboard with all of your equipment intact. Your ship will require a recharge time so you cannot continually teleport back within a short timeframe. If your signal strength is below 100%, there is a chance that the teleport will fail, and the ship will have to recharge to try again later, and your Blue Rock, Stone or Crystal is destroyed.
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!