Mephs

Members
  • Content count

    1168
  • Joined

  • Last visited

Community Reputation

354 Neutral

About Mephs

  • Rank
    Contributor
  1. The point of having it in it's own thread rather than the main thread is so that execution of the task can be paused and resumed at will, so the job can be completed in bite-sized tasks without a major refactor instead of as one big lump as it currently stands. If I tried to do this in the main thread, I would have no way of pausing the task whilst others complete without losing my place in the code being executed. In a separate thread, execution of the task would be paused rather than broken out of. Are you trying to say that this is not possible? I'm thinking it might be possible with boost signals/slots. I should also mention that the code in question is also not called very often. It seems to cause the chugs at a rate of around 5 chugs per 5-10 minute period. Thanks, Steve O
  2. Hey all, I'm trying to stop my game code from chugging at the moment by making as much of the time consuming code asynchronous and thread safe, as possible. I have managed to get the vast majority of this accomplished, but I'm struggling a little with some code which I am unable to make thread safe because it is using a DirectX device and is very low level code within the engine (non multithreading aware D3D Device for performance reasons). The code in question was not written by me and is very low level which makes it even harder to refactor. I'm wondering if it would be safe to move the non threadsafe code into its own thread and halt execution of the main thread whilst the job in question is processing. The idea would be to then code an object which, when instantiated, will periodically stop the current thread from processing and allow the main thread to continue. When the main thread has sufficient processing time remaining in a cycle, the main thread will again be locked and the thread the job belongs to will be allowed to continue. Repeat this ad infinatum until the job has completed. All that would then be required is that the code instantiate these objects to give the main thread a breather every now and again and the job is effectively spread over several cycles whilst hopefully still remaining thread safe. Even though the code is itself not threadsafe, the main thread is always locked whilst the code is executing and nothing would use the code in any other thread. I always get my head caught up in thread safety stuff, so firstly I'm wondering if my scheme sounds like it would be threadsafe despite the fact the code is not running in the main thread and is not inherently thread safe. Secondly, I wonder if anyone might have a better suggestion as to how to cope with spreading code that takes a while to execute over several frames without having to drastically refactor it? The code in question is making lots of calls which are not very expensive on their own, but add up over a period of time. Roughly 6,000 calls to about 5 different functions is taking about 0.05 seconds which is the cause of my chug as far as I can tell. Any advice would be very much appreciated :) I can provide extra info if needed. Many thanks, Steve O
  3. I've not got as far as speaking to them yet, but we did see a similar problem in the past in fullscreen mode as well, which I think was solved by either enabling vsync, or enabling vsync and performing a lockstepquery. We were dealing with nVidia at the time and apparently they were quite sketchy on the issue and didn't want to be drawn into giving an answer either way until they had a chance to run the app through some diagnostic drivers (I'm not sure if this ever happened or not in the end). The more I think about this issue though, the more inclined I am to believe that it could be some kind of query related problem. The reason for this is that my work colleague described the problem as looking like caches on the GPU were being filled, which forced the card to flush, which stalled the system. As I understand it though, queries do exactly this if you call GetData on the query before it has completed. They stall GPU and CPU until they get the result back from the GPU. I guess that it is possible that something about going back to our character select screen might be stopping the queries from taking place, or might change something about the timings behind it all that brings everything back into sync. Of course, I could be on a complete wild goose chase :P Thanks, Steve O
  4. Hey all, I've been practically bashing my head against a brick wall trying to debug a problem I'm seeing at work so wondered if anyone might have any input on the problem! Basically, what I'm seeing is that in windowed mode only (NOT a problem in fullscreen), when I get to a certain portion of the game, the game stutters. If I then log back to character select and back into the game and play again, the stutter is gone. I should point out at this point that the problem only occurs on my machine with XP and an ATI card. My other machine has Vista and an nVidia card and never seems to experience this problem. The nVidia graphics card is I think slightly more powerful, but not hugely so. If I stick some logging calls into the render code for each frame, the stutter disappears almost entirely, which seems to imply that spending a little more time on processing stops the problems from occurring in this case. I've used Microsoft PIX to analyze what is going on with Direct3D and it seems that the game is rendering several frames at an effective rate of 60 FPS, then it will render one frame at an effective rate of about 6 FPS, then it will recover again for a few more frames. CPU usage is showing as 25% on a quad core system, i.e. full utilisation of a single CPU. When I go back to character select and play again, cpu usage is showing as 7-8% rather than 25% and there is no stutter at all, though I'm loath to believe that the game really is doing anything else. I'm guessing I could be legitimately CPU bound, but I have an inkling that this might not be the case. I've read up on the issue of micro-stutters which generally occur in multi GPU systems where one frame out of several is rendered much slower than the rest, which creates a jarring visual effect despite the fact that the average FPS is really high. This sounds like the same behaviour I'm seeing, and I had read one forum post which suggested that some motherboards may have a PCIe timing issue which can lead to micro-stuttering even on single GPU systems. One of my work colleagues thinks that it may be an issue with throwing too much at the GPU and a cache becoming full and causing the stalls. Again, this sounds plausible, but I'm not sure why returning to the character select screen and back again would solve the problem. Also, the amount thrown at the GPU according to Microsoft PIX is almost identical in the case where I see the stutter to the case where I don't see it.... so again, I'm loath to believe that this is really the case. I've had a couple of ideas from browsing google, such as updating my motherboard drivers (aready done GPU drivers!) and trying to toggle the "force triple buffering" graphics setting. I'll give these a try, but if anyone else has any input based on what I've described, I'd really love to hear it as I'm almost out of ideas! Am I seeing a form of micro-stuttering or am I perhaps CPU or even GPU bound? Many thanks, Steve O *EDIT* Another possibility I have discovered is that it could be our occlusion queries. I gather that inefficient use of occlusion queries in Direct3D can produce stalls that appear to be both CPU and GPU bound. [Edited by - Mephs on April 1, 2009 4:52:32 PM]
  5. I found this when looking at the LostGarden site yesterday. Having given it a play for about 40 minutes or so, I think it might be right up your alley in terms of researching ideas. I don't think anyone has posted it yet, but if I'm duplicating a suggestion I appologise in advance!! Anyway, I was hooked for a short while, and I'm sure there are more than a few potential nuggets of inspiration lying in the design of the game. Hope that helps, Steve O
  6. Looking for character ideas

    I like the idea of a "grounded character". I think that probably sums up what I'm after, but unfortunately a juggling waitress doesn't quite fit the bill. Part of the mechanic I'm trying to work with is that the game should play like a 3d platformer with the obstacles being as much in vertical space as along the ground plane and I feel that a juggling waitress would only work in a single plane of movement which is not quite what I had in mind. Otherwise that would be an interesting idea though :) Another part of the mechanic is that possession of the "ball" must slow the player down, otherwise the player has no need to fire the ball anywhere to speed up their progress.. they might as well just keep hold of the ball. I'm thinking in terms of it being something like a golf game, but without using golf clubs. I think it would create interesting gameplay. The player has to watch out for hazards around where the shot might end up and the platforming gameplay becomes easier or harder depending on how good the shot is. This can also be extended with some light puzzle elements such as having to trigger certain switches to clear a path for the ball as a very simple example. Players have to weigh up risk and reward by determining whether to take a short but safe shot, or a long shot which could go off course and slow them down when they have to get to the "ball", but which potentially gets them closer to the goal in less time than a short shot. So perhaps with that bit more detail about how the mechanic will work it might be a little easier to understand what I'm after. That said, a couple of your other ideas sound interesting. A tight swarm of Fireflies is a nice alternative to a ball that might fit in well with an appropriate accompanying character and I like the trail of light idea :) My only concern here is how to slow down the player while they are in possession of the swarm and how to explain the firing of the swarm like a ball. I could see the Turtle idea possibly working as well, but I'm not quite so keen on it as the firefly suggestion. Anyway, I'll think some more on it, but thanks for the input so far! Steve O
  7. Hey all, I have an interesting idea for a game, but I'm a bit weak on my character designing skills and having trouble coming up with a suitable character to fit the concept. The idea is basically a ball game of sorts... players will be able to move around a level, pick up a ball-like object (which could be a ball, or an egg, or a rock, or something a little more unconventional than a ball, but generally a roughly spherical object!). The player will be able to collect the ball and then fire it out quite a way from themselves, perhaps using the ball as a projectile attack or for some other means. The game will be about getting the spherical object from point A to point B via a set of obstacles. So what kind of character might fit such a game? Something like Yoshi Could go with a frog or a lizard or anything else that could use a long tongue to eat eggs and spit them out. A human cartoony character with a magnetic glove This idea is a bit more sci-fi than the previous, so perhaps would appeal more to a subset of fans and could limit the games appeal? A caveman style character running around throwing boulders This idea would be funny and interesting, but could limit the scope of the games theme a little. An alien or a psychic human moving the ball with the power of their mind Another sci-fi idea, but a little more humerous than the last sci-fi idea... I imagine seeing little lightning bolts coming out the characters head and manipulating the ball. Robot Another geeky idea... the robot could eat the ball "pacman style" and fire it out by a cannon built into their mouth. Well those are some of my ideas so far, but I'm not sure they are the best ideas... I think maybe they are a bit too generic and/or a bit too geeky and I would like to have my game idea appeal to a good sized audience. Perhaps someone here could imagine a better fitting character to use in a game roughly along the lines of my description and how they might interact with the ball? Many thanks for any/all suggestions!! Steve O
  8. As far as you idea for linking planets, how about explaining it by having some planets simply referred to as Homeworlds or Ruling Planets. Taking control of a Homeworld could then cause linked planets to succumb to your rule. This would introduce a simple element of strategy... do you attack planets that pose a higher threat, or do you fight your way through a couple of minor planets to reach the homeworld and destroy the leadership chain. Immediate resolution of problems versus a more effective long term strategy. Perhaps using a slightly more complex version of this, each planet could boost the resources/defences of neighbouring planets, so every planet has a different level of strategic value in reducing the effectiveness of linked planets. You could easily describe this as a flow of trade/resources/etc between the linked planets. Of course, each boosted planetary statistic would have to be applied to a separate bonus pool, otherwise planets would get a boost from a neighbour, which would then be applied to it's neighbours, which would lead to an infinite loop of boosting :) I think this system would balance itself out. Sure, your forces could grow and require a bit more micromanagement, but as you become more powerful, your planetary influence will grow and remaining planets will be easier to conquer. Just my 2 cents anyway! Cheers, Steve
  9. Plausible Zone Limits

    I don't have time to post a comprehensive reply at the moment, but I thought you might be interested in this article from Gamasutra about creating plausible obstacles. I think it should be right up your street in this case :) Hope it helps, Steve
  10. Yes, I too have heard the game referred to as being similar to Solitaire in a sense. I would agree with the statement. Every game is a bit different, every game takes very little time to play. It's pick up and throw away gameplay, but due to the design there is enough of a hook to bring you back, though I believe it could be improved even further in these respects. The idea of treating events like a deck of cards is interesting and the ability to move "between decks" under certain conditions sounds very interesting too... you could completely change the feel of the game in this way which is very novel but the circumstances that cause the change could be different every time. I also agree that the events need to be tied together and somewhat persistent. I would love players to get attached to certain characters and find a certain niche of gameplay they enjoy (such as a stealthy approach, diplomatic, trading or combat). Movement tracking is interesting. Perhaps a simple implementation of this would be to have "cards" move between sectors over time and have the moving cards sometimes become intertwined with event cards in the new area they have moved to or sometimes just providing their own events. Yes, I'm quite liking the sounds of that :) Then, if an NPC character survives an event, you may encounter them again in different circumstances at a later point. Perhaps some kind of rudimentary attraction/repulsion system might work as a simple AI for movement of NPC encounter cards so they move towards areas of interest and away from offputting areas with each character having their own set of motivations (i.e. some may seek danger, others money, others rare mineral, and so on). I also agree with shurcool in that the system could suffer from being difficult to adapt to if it messes with the game rules too much. Perhaps in this sense, the number of events could act almost as a difficulty level of sorts. As most of the event system would be behind the scenes though, I think it may also be a little easier to grasp, as the player does not see all this work going on behind the scenes, they just see the outcome in terms of scenarios. Anyway, thanks for the comments :) Steve
  11. That's not so much of an issue. I have an idea for a scanner system which will allow players to ascertain threat levels of nearby encounters which I think will help in those regards. Also I'm not planning to go for character growth so much as character diversity in the same way Guild Wars achieves it. New weapons will not make you all powerful, they will just add to your skill set which may well make you all powerful, but only against a limited subset of encounters. Also, part of the appeal of SAIS and WW in my opinion was that sometimes you could get really lucky and end up with awesome equipment and do really well. As each game was relatively short, the imbalance was soon corrected and somehow I think it worked. The focus of the game just shifts from "how can I get the best score ever!" to "how can I perform the best given the situations the game has thrown at me". I think it will be fine in those regards. Steve
  12. Hey all, Further to Wavinator's thread on 3rd person space shooter control systems, I'd like to talk about one of my own ideas. I'm thinking of an idea along the lines of "Strange Adventures in Infinite Space", or the sequel "Weird Worlds". I loved the idea of a pick up and put down 20 minute experience, where every game plays slightly differently. I'd like to take the idea, tweak it a bit and run with it. Firstly, SAIS and WW both went with a 4x game feel. The combat was based more on light strategy than on action. I'd like to go more for the action approach making my idea more similar to a vertical scroller, albeit with 360 degree movement. So, taking this as the basis for the idea, I'd also like to run with the idea of procedurally created galaxies. I think these two games had great potential, but suffered from a few flaws in this area. *EDIT* I only had time to go into detail about one specific flaw here, but may expand on this later if the thread gets any interest! *EDIT* Firstly, you could guarantee certain events would occur in almost every single play of the game. You would always come across one of the trader species that would allow you swap any items for their stock free of charge and you would often see the same events occurring each time you played. It didn't take long for you to come across most of the content, or at least most of the significant content. For my adaptation of the idea, I would like to go with a hybrid of procedural content and hand crafted content. Players will fly in zones or sectors in my game. Each sector will have a variety of standard friendlies or enemies, but each sector will also have a chance of containing a number of events/encounters to spice things up a bit. These events will be the hand crafted elements of my hybrid system, but I would also like to make it a little more procedural. Rather than being happy with random events, I would like the random events to further generate their own content. Say we have an event where pirates are attacking a cargo ship. If we add in a procedural element that wherever pirates are, there is a random chance of "Space Police" turning up to put an end to their nefarious deeds, then we increase the potential for this single event to become unique. Further to this, there could be a chance with any ship that is has succombed to "space rot", which could cause one of the police ships to fall apart unexpectedly in the middle of a battle and infect other nearby ships. Adding random chance situational elements should hugely expand the replay value of the game. Running further with the police/space pirate example. The player could encounter a police barricade. Due to the earlier event, the procedural system could determine that the pirates want revenge on the space police and so a squadron of fighters arrives to attack the barricade. How the player handles the situation, what happens during the event could influence future events. A stray bullet may pit you against the police forces, or you could be commended for your bravery and awarded extra credits. I think this kind of system would make for a very interesting game, but what I'm interested in discussing is how we might take this even further and make it even more interesting, unpredictable and above all, fun :) I look forward to any discussion! Steve *EDIT* For reference, here is my current list of ideas for events: Death Squad Distress signal Weapons of mass destruction Warp signature trail Wild goosechase Ambush Blockade Piggy in the middle Chase Hide and seek Bully Nemesis Sabotage Bounty Hunter Solar Storm SlipStream (use comets slipstream to get a speed boost) Sentinels Harbingers Arbiters Custodians Point origin Galactic core Space Rot Recurring characters Mysterious benefactor Lost World Kamikaze Traitor Smuggler Infestation Interception Drifting Wreck Secret stash Spatial Rift Treasure hunt Space Weed Bound evil Onslaught [Edited by - Mephs on July 13, 2008 3:11:35 PM]
  13. I've been working on a space shooter control scheme too. I'm not sure if mine will fit your needs or not, but my idea is going down the lines of a space combat/trading game too, so it may well be of some benefit to you. I am however working on keeping the gameplay simple and accessible, so I have chosen to go with the 2D plane of movement. I have a picture to illustrate my concept which could be applied to mouse control, the keyboard, or a joypad and should hopefully be equally simple regardless of input device. It's similar to how most vertical scrolling shooters work, except it allows 360 degree movement and has some other interesting elements. The yellow line represents the screen area. The black area is inside the screen. Forward movement in this area could also control forward speed though it is not marked on my diagram. Left and right movement in the area cause your ship to strafe left and right allowing you to dodge bullets as in a conventional vertical shooter. This is one key element of the design. Most 360 degree arena shooters do not allow you to strafe very well for dodging bullet as it is difficult to accommodate both turning and strafing. This design lets you do both naturally and is why I think it is intuitive as simply strafing into the turn zone will cause your ship to rotate its heading. When the player moves off the screen, the view will of course scroll to maintain sight of the player... it just gives us some more area to work with the idea of a zoned control scheme, whilst still letting the player maneuver using the full space of the screen. Moving into the defence mode area provides you with extra armour in my game idea... which will be graphically represented by having armour plates slide into view, covering up weapons but providing much better protection. This will have the effect of temporarily disabling your primary weapons and providing access to the use of a secondary defensive set of weapons.. perhaps not quite so powerful but more useful in a utility role. Moving off the screen and even further back will reduce your speed and maybe even allow you to reverse. I think this area based control scheme gives a huge amount of flexibility, full 360 degree control over a 2D plane and room to add/remove features as you desire. Movement aside, you then have an offensive and defensive mode, both of which (assuming you're using the mouse) could have a primary and secondary fire on the mouse buttons.. so you effectively get 4 actions there from 2 buttons. Even more if you dare venture into the realm of double clicks or sustained clicks or context sensitive clicks (not that I'm saying it would be a good idea!!). You could also venture into using the mousewheel to switch between weapons. Obviously a keyboard or joypad control scheme would have to adapt this system to suit. To illustrate my idea further... here is a short video capture of an early prototype I made. Here is another. To make the system as user friendly as possible, each zone change would have a transitional effect to make the user aware that a change in state is coming if they continue moving towards that area. i.e. if you move very close to the armour mode zone... your armour plates could start to slide out to a halfway point and lights could start glowing on the ship. If you move close to the turning zone, your ship starts to partially bank to the left or right to show that you are about to start turning. Also I have considered the problem of players travelling down a restricted corridor and being unable to reach their "turning zone" because an obstacle is in the way such as a wall of some sort or 2 asteroids side by side. In this case, you could simply transform the width of the zoning to be as wide as the corridor and the system would work as normal, albeit you could not strafe into the obstacle as you would enter the turning zone and turn away from it automatically. Anyway... I hope that's of some help. I know the explanation is a little rushed and perhaps difficult to follow as a lot of the design probably just makes sense to me, but if it's maybe even just useful as inspiration for another alternative design, that's good :). Cheers, Steve [Edited by - Mephs on July 13, 2008 9:28:50 AM]
  14. I'm not dead... I feeel fiiine... croak

    lol! Well you did say that you didn't want all those emails clogging up your inbox ;) Never mind though, I think they're planning a follow-up at some point, but not sure if they are changing to a different game or not... I hope to get some revenge in Q3A though, so I'd like it if we did that again :) Anyhoo yeah, the export stuff is going nicely... just a shame that I'm away for a week in Cornwall now the work is taking off (and now it's looking like terrible weather in Cornwall!)... I've now got bones exporting and an early framework in place for keyframes, IPOs and all the rest of Blender's animation stuff... I'm dying to see a proper animated model all exported in my own format!! Anyhoo... see you in a week! Steve
  15. I'm not dead... I feeel fiiine... croak

    I haven't completely given up on it. The code to load the XML is still in there. My idea is currently to develop the two in parallel and use the XML version for debugging as you have suggested. I am however writing this in the hopes that perhaps one day I might be able to have a marketable game at the end, and I'm figuring that every easy byte saved is a good thing as regards the final download size. :) Cheers, Steve