FPS 90's style - WIP - New Video!
Blitz3D Forums/Blitz3D Beginners Area/FPS 90's style - WIP - New Video!
| ||
| I love raycast games. Without these early shooters much of what we love about the PC industry may have never happened. My facination with these games grew into more than simply a collection but an obession as time progressed. I always wanted to try and make my own shooter, one that could have possibly hit the shelves in the mid to late 90's and could have competed with maybe even Duke3d and Doom? After messing around with making maps and simple mods for titles like Wolf3d, Rise of the Triad, and Doom it left satsified me for awhile but still hungry for more. Now once again for fun I want to try and create a basic raycast like engine from scratch. What I mean by "raycast like" is that the engine will not use archaic algorithms or overly rely on 2d sprites. The game world will be 3d but be carefully designed to feel like a oldschool corridor shooter. This way I have none of the limiations or pain of working with antiquated game design techniques. Even if my game map is showing 5000 polygons or more each map is only created from the following few models. MAP LEGEND  I'm not exactly sure how a cpu and gpu process 3d information, but to me this seems like a logical way to keep the memory requirements low. My plan is to draw the map information by storing everything in an array. 0,1,1,1,1,2,1,1,1,0 0,0,0,0,0,0,0,0,0,0 0,0,0,0,0,0,0,0,0,0 1,1,1,1,3,3,3,1,1,1 Let's say that 0 = the floor model and that 1 = the standard wall. 2 is actually the same model as 1 but with a different texture. 3 might be the same wall with yet a new texture but the orientation might be inverted. Following me still? :) I have a basic framework coded so far that allows the player to move around a map, change the lighting, and checkout a few assets I modeled but nothing more. I need some advice/examples how how to code a proper level system to easily design my maps with code.   Hand drawn textures : *removed* Rendered textures : *removed* End Result:   I created everything you see above a few years ago. The Pulse rifle is from Aliens Online. During this time I attempted to construct a simple 4 player cooperative version of AVP. ( AVP on the Atari Jaguar) It would have worked but it was very difficult to get things working the way I wanted hacking up the Rise of the Triad code. So I abandoned the idea. How may people here love old raycast shooters? Anyways I need some advice on how to proceed next as I continue building the framework for my game. Influences: http://www.mobygames.com/game/hired-guns http://www.mobygames.com/game/jaguar/alien-vs-predator http://www.mobygames.com/game/windows/aliens-online Special thanks: Yasha, Kryzon, JohnGalt,Stevie G. Sorry if I missed anyone! |
| ||
| I think it looks great. For some reason the bottom two screen shots remind me of a 3d version of an old Amiga game called 'Hired Guns' by Scott Johnston. The 4 player co-op mode would fit in nicely with that game style too. As for advice on what to do next I would add things like sliding doors, force fields, lifts and a switch/lever mechanism to activate it all. The key though is to try to keep things simple. Throw in some NPC's and collectables and you've got the basis of an enjoyable game. |
| ||
| I did study Hired Guns when I was developing this concept. Some of the best games ever made were for the Amiga. Hired guns had a excellent atmosphere which is key if you're trying to make a survival horror type FPS. I loved the maps with the sentry turrets. The problem I have right now is coming up with maps. I can easily model a small complex, texture each piece, then manually add each section into blitz3d. But I want a faster way to come up with simple levels using code. Currently I create everything in Maya using the grid with snap on. Game engines like Doom stacked square polygons to create the level geometry. Rise of the Triad used more traditional racycast techniques but with the option to create maps with height variances. Wolf3d was limited to 90 degree walls without any height variance. |
| ||
| The problem I have right now is coming up with maps But I want a faster way to come up with simple levels using code. I have managed to do procedural building of corridors and rooms for my underground city project. It is not hard to do, simply think about how you proceed when you build a map, and extract each step, then convert these steps in code and you can have the computer do the work for you :) But ! If you want the maps to stay coherent, i suggest to define the purpose of each room before you create it. Else you will have many different empty rooms that you don't know how to fill with furnitures, objects (see my worklog for an example of what i mean, it is empty !) I plan to rewrite my routines which procedurally build the corridors and the rooms by including the purpose of each room before trying to create a room. This way it is possible to know how to fill it with furnitures, objects. Sometimes i wonder if it is not faster to build manually one level each day instead and make it coherent instead of using a procedural approach. But on the other hand i have no inspiration to build rooms manually so this is why i use a procedural approach. Also i like to be surprised when i see the results, it is as if i had many workers who build a structure following my instructions, and i like that :) |
| ||
| Here are a couple of techniques you could consider depending on your requirements. 1) Procedural map generation - There's a simple maze generator in the code archives somewhere that could be adapted to your needs. Pro's - fast map generation and an almost infinite variety of maps. Cons - You have virtually no control over the final layout of your map. Maps can look 'samey' and uninteresting. 2) Write your own map editor. There are several ways to do this but one possible way would be to create map sections out of meshes and simply adapt the game code you have so far so that you can literally run round the game world placing the desired map section into the 'cell' in front of you as you go. When finished just save map to a custom map file. Pro's - Re-use of game code you already have means you can knock up a simple map editor like this fairly quickly. Just add some form of map tile selection and a way of being able to load/save your work and you're practically done. Cons - A restricted 1st person view like the method above means that it could be difficult to visualize the overall layout of your map so far. You could provide alternative top-down views and/or a mini-map of the current floor level you are working on. 3) Use a 3rd party 2d tile map editor. In this case you're designing your map 1 floor level at a time placing 2d tiles that represent your 3d map tiles. Pro's - No extra coding required other than loading in floor data into an array then generating the complete map from a 3d tile set. Cons - Designing a multi-floor map with a 2d map editor one floor at a time can make it difficult to visualize how those floors 'connect' with each other. For instance a lift shaft or even a wall might not be aligned correctly with those on the floor level either above or below it. Another possible way you could generate your maps (but again on a floor by floor basis) is to pick a colour to represent each tile type and simply use any art package to draw the floor layout into a bitmap sized to your map world then load in the bitmap and reconstruct your map from there. I'm out of ideas now but I hope there's enough there for you to think about. I hope you knock up something soon I'd be interested in seeing something playable :) |
| ||
| Take a look at FPS Creator. It is very similar to your system and could give you possible ideas of what you could do with yours, including a similar map editor. (Yes, I know it's by the makers of DarkBASIC, rival to Blitz3D!! Personally I prefer Blitz for its simplicity even though DarkBASIC can do a lot more) |
| ||
| FPS creator is how should I say this..... TERRIBLE? Even if someone made a decent game with it that energy and passion could have been better spent. But if only for a learning exercise it may prove useful. Darkbasic in theory could maybe do more than Blitz, but based upon my experience Darkbasic games are far buggy and less polished than what I have encountered using Blitz. Blitz is very fast and well supported so that is why I'm sticking with it. Machines I have tested my Blitz projects on: Toshiba Laptop 2.4ghz - 128mb integrated card (XP PRO SP1) Lenovo Deskpro 3.4 ghz -128mb PCI Video Card (XP PRO SP3) VPR Matrix Desktop 2.8 Ghz - 128mb PCI (XP PRO SP2) Emdeon 3.0ghz Dual Core - 1024mb BFG PCI Express (XP PRO SP3) Intrex Pro 3.0 Ghz - Integrated 64mb Intel - (XP PRO SP2 Custom) 3.8 Ghz Alienware Shuttle PC - 256mb Nvidia - (XP PRO SP3 custom) i5 QuadCore - 2048 ATI - (Windows 7 64bit) i3 Dual Core Lenovo Workstation - 512mb Quadro (Windows 7 32bit) This doesn't include people who I let alpha test my game. With a healthy mixture of different processors and graphics cards you can see Blitz simply rocks. The Toshiba laptop I treat as the worst case scenario for my user base. If I can keep my game running smoothy on such an old machine then it should be fine. When visiting friends I carry around a jump drive with my project so I can test it in as many real world conditions as possible. So far no issues! :D |
| ||
| If the art at the top is representative of what you want levels to look like, you should also be able to get a good performance boost by completely disabling/hiding large sections of the map that are out of sight. The grid layout may make it substantially easier for this game, compared to engines supporting more "generic" layouts, to determine what should be culled from the scene. B3D doesn't automatically optimise scenes very much: -- anything within the camera's view frustum is drawn, no matter whether it is obscured or not -- animated entities don't turn themselves off when they're out of sight for the same reason, which also wastes CPU time on the animation itself (can be quite involved) With a grid like this you might be able to efficiently identify hundreds of candidates for HideEntity that would otherwise just be wasted on overdraw. |
| ||
| Hiding what is unseen is an absolute must. HideEntity removes collision checks though, this could prove problematic when writing AI? Wouldn't EntityAlpha 0 still provide performance increase? For now the gameplay will be no more advanced than let's say Wolf3d. I do not think I even need a collision check for the floor or Z level. (Y in Blitz) The player can only move in a 360 degrees and no jumping. I thought a animated 3d entity automatically hide when it was not scene in Blitz3d? |
| ||
| Well, getting rid of collision for areas you aren't using is also a valuable performance boost, so turning off the checks is usually good. Other things to consider in this vein: -- B3D's built-in collision engine is really slow (ColDet is 10-100 times faster at the same things) -- in a grid-based game with 2D movement, you really, really don't need to be using render meshes for collision and AI data: use pure math constructs One particularly "unclean" idea that B3D unfortunately promotes is the idea that collisions, and other logic work, should have anything whatsoever to do with the data you loaded as renderable meshes. In a normal game engine, information flows "one way" through various layers. Collision data comes out of the collision system, informs the AI, which is then rendered using renderables. B3D encourages users to simplify the process, but in so doing creates vastly over complicated collision scenes by building them out of render mesh data (usually, far too many polygons and unneeded details). i.e. you usually should definitely not using your renderable meshes for collision purposes anyway if you care about performance. In your case, the grid layout again provides you with a huge advantage. You can almost certainly use a much, much faster 2D collision system that doesn't have the complexities of meshes involved in it at all. An animated entity's mesh will be hidden when it's out of the camera frustum, but it won't stop animating because animation can affect collisions. |
| ||
| An animated entity's mesh will be hidden when it's out of the camera frustum, but it won't stop animating because animation can affect collisions. A way to avoid playing the animations of meshes outside the camera frustum would be to use the command Animate() only for the meshes in view after a culling routine and just before renderworld, but then there will be 2 updateworld() in the loop... It is a shame that we can't have one command to calculate/detect collisions and one command to calculate/update animations. This is something i don't like about Blitz3d. |
| ||
| Thanks for all the input everyone. I have a lot of work to do. If I run into any problems I'll let you know. I started mocking up the a map from Aliens Online the US Coronado. It's a real shame that the good Aliens themed games ended with AVP2. (in my opinion) |
| ||
| You're right, Aliens: Colonial Marines was a disaster. This question is probably very dumb, but did you want to create some super fast Quake-like shooter or rather something slower, like Wolfenstein? I don't think you'll be needing to calculate the AI's movement out of sight, would you? You could just make them spawn just before the player can see them, so you don't waste time on calculating movements. What this means is that you wouldn't just be hiding the AI but completely deleting the enemies out of sight (or in a certain range) |
| ||
| Definitely not as fast as Quake but much slower. Like Rainbow Six for the marines but perhaps quake like for the alien players. The AI will be very generic. Moving toward the closest player or whoever damaged it last. Doom has a really neat system that used deaf or non deaf sectors to see if monsters heard the player. Often I would make an entire map in Doom with no deaf sectors. It gave the level a more alive feel because the monsters would start pouring out from every area searching for the player. I'm also studying old raycast engines for idea's how to implement simple AI and weapon ballistics. But to answer your question something in between Quake and Wolfenstien. |
| ||
| I wasn't aware of Animations affect collision - do they? I was working on my fps engine in blitz for a couple of years. As of 2010 or so, when commercial fps releases became huge projects that a single develkper by far couldn't competite,I stopped further work on it. But maybe you're right, maybe the old corridor feeling is the way to go. Www.melog.ch/dropper/ if you wanna take a look. I wouldn't worry too much about performence tho. Todays hardware is so fast. And the nostalgy look may include lowpoly NPCs anyway. Copyentity works well for NPCs btw. |
| ||
| I actually checked out that engine before. Many of the demos would not work because of that darn "Memory Access" error. I tried everything I could think of to get them working with no luck. But those machines did have workstation cards. I need to try those again on different Windows7 machines. Yeah I can't hope to compete with a modern FPS but that's a good thing. I dislike many modern FPS games for a variety of reasons. I honestly got much more longevity & fun out of 90's-2000 era shooters than anything current. I still play many of the classics because they're still fun! Back to my project. Once I correctly implemented tweening all of my performance worries went away. There is still a hiccup if you run the game in a window but I think that's a problem with Blitz3d itself. Performance is a major concern for me because I want my project to support up to 64 players. |
| ||
| I wouldn't worry too much about performence tho. Todays hardware is so fast. Hardware has come on a bit, but remember that one of Blitz3D's less fortunate quirks is that it does literally everything except the rasterisation of the final polygons themselves on the CPU, and CPUs simply aren't designed for that sort of work any more, nor have they seen the same explosion in performance as GPUs (especially because B3D won't use any new, or "new", features, in the name of long-irrelevant backwards compatibility). So you can throw hundreds of times more static polygons at a scene now than you could in 2001, but try to animate a scene of similar complexity to any commercial game and it will suddenly slow to a crawl because it's not using hardware skinning. For animated characters vertex count remains tremendously important in B3D for this reason. If your retro look lets you keep the vertex count low, definitely take advantage of that. |
| ||
| Good point Yasha. Fortunately the way I'm designing the maps combined with how Blitz3d can limit the draw distance I shouldn't have any issues. I estimate that the largest amount of polygons drawn at anytime will be no greater than 20,000 being the worst case scenario. The textures are very simply and occupy no more than 4mb of Vram. However I have noticed that the memory usage doubles if the display resolution is higher. Thanks to your help with tweening my game projects run without a hitch even on really old hardware. I think my ancient Pent3 with a 32mb diamond viper can easily do 20,000 polys. I'm gonna dig that thing out and test it today! |
| ||
| Oh btw. About that memory allocation violation MAV error, you didn,t try to run the exes from inside the zipfiles, did you? If so, you'd really need to unpack them to the harddrive first. An other issue was the exe packer Molebox that made problems I guess with XP SP3 and later ones. Did you try my VRV demo? That one used an other packer. Or my subgame that wasn't packed at all: www.melog.ch/subgame . Sorry for the offtopic. It just hurts to hear that all my b3d-stuff mavs these days. |
| ||
| The subgame worked just fine on a freshly built Windows 7 32bit machine. Most of your demos also worked but a few didn't. I unpacked all of them to the hard-drive. I like your subgame a lot but I think you could easily bump up the texture quality on the submarine. I don't consider this off-topic because much of this thread is about performance optimization and avoiding errors that may crash Blitz3d programs. That being said what I'd like to figure out is a easy way to remove mesh based collisions from my raycast style game. I only have one collision check right now so I'm not having any performance issues but I'd like to see how much cpu time this would actually free up. |
| ||
| remove mesh based collisions from my raycast style game What are you colliding against what? 1) If you can possibly avoid using B3D's mesh collisions, do so. They're incredibly slow. If you're colliding moving characters against the level, consider the possibility of representing the level as a collection of boxes and using sphere-box collision instead of sphere-mesh: it will be faster if you can arrange the boxes efficiently. 2) If you have to use mesh collisions, consider using ColDet for collision instead of the builtin collision system. It's hundreds of times faster, and also offers mesh-mesh collision detection (which is still faster than the builtin collision engine). You could also use OPCODE or a full physics engine like ODE or Newton (yes, even these will be dramatically faster), but ColDet has the advantage of being a popular and tested B3D solution. "Optimising" B3D collisions is a waste of time, the core collision engine is simply too slow for high-performance use, and they are more easily replaced with an alternative engine. On the other hand, optimising thing that aren't bottlenecks is a waste of your time, so tread carefully. Given that your game look to have blocky architecture, you could probably knock together non-collision-based solution that simply keeps players in their blocks and doesn't allow movement elsewhere; this would obviously be the fastest of all, if the level design allows for it (e.g. if your players can't jump, there is no reason to apply gravity and therefore no need for the floor to be solid). The best collision solution is to not use collision if you can possibly avoid doing so. (In fact you could extend this to pretty much everything.) |
| ||
Only colliding against the level. I do need gravity because players can duck, jump, and even roll. Here is an explanation of what I have going on so far. 1. I make the map in a 3d program like Maya or 3dsmax.  2. Polygons with different textures are exported as separate meshes. I decided to do it this way because it allowed be to build the maps visually and I saw no performance difference drawing them with code. Maps are loaded in multiple sections but basically its one giant piece. This seems like a waste of geometry at first but I had concerns about the lighting and getting the textures to tile correctly. Creating the maps like this allows me to mimic maps from Aliens Online down to the smallest detail.  3. Here I'm selecting one of the many texture layers. I can turn off the walls, floors, grate texture, or whatever else I want to view. Pieces actually start out as cubes but I trim off the extra faces one everything is snapped into place perfectly. Another reason for doing the maps with all these faces is so the lighting behaves correctly. (see below)  4. First in game shot without lighting. As you can see the map loads in identically as it appears in Maya. Every piece shares the same collision code.  5. Triggering the nifty wireframe mode allows you to see the in game polycount. The demo map is so far 1500 polygons but the world only draws a maximum of a 100 for distance. Anything beyond that is not rendered.  6. Another angle of the outside area in wireframe mode. The texture wraps around and tiles with the polygon perfectly. The original Aliens Online had true 3d levels made up of cubes. Possibly using BSP? I'm not sure though.  7. Here I'm trying to achieve a shoulder lamp type effect. The lighting here is smooth. The problem is that it only follows the players horizontal movements and not the pitch up and down.  8. Same as above but with hard lighting instead. If I rotate it 90 degrees and above the players head is matches almost exactly how the shoulder light behaved in Aliens Online. It wasn't very realistic instead surrounding the player with a small circle of light. I'm not sure if I will make the light realistic or leave it as it appeared originally. I know the flashlight affect is not dramatic enough but when I was messing with the lighting I was using a CRT so it looked dark enough. If I understand what you're getting at Yasha is that I should simply the geometry even further? Those rooms could be trimmed down more thus reducing the current polygon load in half. But I wanted to make sure the textures scaled correctly without messing with the UV coordinates for each room. I think Blitz3d has enough power to spare with the extra polygons. Everything in my project except for the level will be made up of sprites. However I do feel its still very important to make the code as fast as possible to eliminate any potential lag or strange glitches regarding collisions or gravity. Over analyzing and over optimizing is kind my habit, but I agree I shouldn't waste time on gaining a 1% difference when I so much more still to do. :D My geometry abuse is nowhere near anything like this.  |
| ||
| I should simply the geometry even further? Those rooms could be trimmed down more thus reducing the current polygon load in half. But I wanted to make sure the textures scaled correctly without messing with the UV coordinates for each room. The collision geometry should definitely be simplified if possible. This would not affect UVs - an important thing to remember is that there is no need or even reason to use the same mesh for drawing and for collision. The meshes you have now can coexist with a simplified, invisible mesh in the same space that has collision activated. This doesn't have any negative performance effect since as one mesh goes only to the renderer, and one goes only to the updater, there are no redundant operations. Using two meshes - one simplified, one visible - is a standard technique used by most games. It is actually a general guideline that you should never use render geometry for collisions, because even at best it's optimised all wrong (as you observed, it has to have UVs for a start). Render meshes need lots of small even polygons for decent texture and lighting; collision meshes need big polygons to minimise the number of checks and seams, and maximise contact area. A clever engine can often generate the collider at load-time so you don't need to do this in your editor. |
| ||
| But Blitz can't do that. So I will have to export even more simpler versions of my maps and load them in for collisions. Not a big deal but making maps is already tedious enough. |
| ||
| Blitz can't do that ...automatically. Ain't nothin' stopping you from adding the code to do it though. Remember, Blitz3D isn't a game engine, it's a game engine builder. What I'd recommend from looking at your wireframes (what I had in mind earlier) is that when you load a map into the final game, you create a second copy to use as the collider template and then do a "simplification pass" over it. You don't need to simplify everything: I was just noticing your huge grids of squares that make up floors and walls - you could have the simplification pass be as simple a matter as detecting four identical quads next to each other and unifying them into a single quad; two or three passes of this will dramatically simplify your collider mesh, taking out only the guaranteed-redundant polygons. (How you would detect the presence of quads depends on the structure of your level data.) e.g.:  The wireframe on the right has the exact same physical shape as that on the left, but with fewer polys. You can see that a lot of obvious (to a human) optimisations aren't made: this doesn't matter - by only choosing the most obviously guaranteed to work (in this case, choosing squares of side 2^n), it stays simple for a machine to do. There's no penalty for doing this (except a slightly slower load-time), since as I said above, each mesh is only used by one of the two B3D engine components; even if you didn't simplify the mesh at all it wouldn't actually be slower at runtime, so there is no performance loss to adding a "speculative", conservative simplification pass. ...anyway. This is an optimisation that you can apply at load-time. You obviously don't have to and I don't mean to derail the thread. As before, your own time is usually more valuable than the machine's. |
| ||
| It should be fun writing something to remove redundant polygons. Iterate through all triangles, detect and collect coplanar triangles, build the boundary shape of each collection and triangulate this boundary shape into a mesh. Depending on the texturing half the work is done already, since some vertices were split\duplicated to allow adjacent faces to have different brushes. http://blitzbasic.com/Community/posts.php?topic=98349 |
| ||
| In one of my game i use rooms of 15x3x15units and they are subdivided like what you show in your wireframe. And even with all these tris for the collidable mesh (receiver), i have found that the collisions calculations are fast enough, even on a netbook. In the scene i have : 100 rooms, 100 corridors For each room 1 collidable mesh (receiver) up to 50 columns, sculptures, containers For each columns, sculptures, containers 1 collidable mesh low tris (receiver) 10 characters For each character 1 collider ellipsoid (emiter) 1 collidable mesh low tris (receiver) up to 100 projectiles For each projectile 1 collider ellipsoid (emitter). But i have a routine to create or destroy a collider ellipsoid depending on if it moves or not and depending on if it is near where the player is or not. There is no point to calculate the collisions on the walls of 100 rooms ! So i don't know what Yasha has done but i don't agree that Blitz3d collisions are slow. They can be useful if used in the right way. Or maybe it depends on which machine it runs. |
| ||
| For the record, my experience with B3D collisions being "too slow" involved collision checking and line picking on scenes with dynamically-deformed meshes of several hundred thousand polygons. That's going to bring almost any collision system to its knees. I also wasn't using the newest of systems. If I'm fair, I should probably rather phrase it as "ColDet is ludicrously fast" rather than "B3D is ludicrously slow", as using it solved most of my problems (and in fact upgraded the situation significantly to have those meshes bashing into each other instead of using spheres); but the problem was also rather self-inflicted as most users don't have the same level of detail requirement. B3D collisions are certainly fast enough for this engine as proposed so far. |
| ||
| For now I will just use a collision box to separate the collisions from the mesh. Now for calculating ballistics for weapons I need it fast. I thought of doing it like in Doom with a hitscan but those can often end up way too accurate if there is any lag involved. |
| ||
New screenshot. Trying to give some new life to those old textures with some 3d geometry to enhance their effect. In this image I made sure to preserve the pixeliness of the textures. The scaling on the door is way off but I think the corridor looks pretty neat. This is part of an original map I'm designing for my AO reboot. |
| ||
| looks pretty good. i like the way you play with darkness. tho, one thing, the brownish metal and the blueish metal on the floor may not fit together perfectly. but thats peanuts. from a DPs point of view, you would in fact use exactly these two tones, since they are complementary colors, but they would be rather two diffrent light sources, one blueish and the other one brownish or golden, than two kinds of metal. of course, that matters only in a perfect world, so basicly: great job! |
| ||
| In this image I made sure to preserve the pixeliness of the textures. Awesome. If you really want to take the "software rendered" look to its ultimate extreme, you should do a forum search on disabling bilinear filtering on your textures. That will make the pixels hard-edged. There is apparently a way to do it using free DLLs. (That said I think it looks better as-is, more like a late- than early-90s game, but very coherent art style.) |
| ||
| Short video. Yeah I'm with you on some of the texture colors clashing but I plan on tweaking some of the original assets to fix that. Also once the in game lighting works correctly that should take care of some of the texture inconsistencies. Have you ever looked at the textures from AVP1 on the PC? Without the lighting the textures are butt ugly. |
| ||
Suggest you put this in your gun.Graphics 800,600,0,2 SetBuffer BackBuffer() Color( 120, 120, 120 ) value# = 0 speed# = 0.017 Const SCREEN_X# = 400 Const SCREEN_Y# = 350 Const AMPLITUDE# = 60 offsetX# = 0 offsetY# = 0 While Not KeyHit( 1 ) Delay 10 Cls value = value + speed If value > 1 Or value < 0 Then speed = -speed offsetX = SmoothValue( value ) * AMPLITUDE offsetY = SmoothValue( (value*2.0) - (value>0.5)*(value-0.5)*4 ) * AMPLITUDE/2.0 Rect( SCREEN_X+offsetX, SCREEN_Y+offsetY, 300, 320, True ) Flip Wend End Function SmoothValue#( x# ) Return ( x * x * ( 3.0 - 2.0*x ) ) End FunctionEDIT: Doesn't use trigonometry anymore, just interpolation. It's faster. |
| ||
| Thanks a bunch Kryzon! I will add this in ASAP. |
| ||
| When can we expect to try a little demo? This looks really good. |
| ||
| I would prefer not to release anything until I have something playable. The maps are quite static at the moment but that will change soon. Building the maps is easily the most time consuming task. To do list: + Environmental lighting +Weapons +Player Hud + Doors & Lifts |
| ||
| Impressive and keep going :) |
| ||
| *deleted* |
| ||
| Sorta just experimenting with some stuff. Here is the end result. :) Better entry here: http://www.moddb.com/games/aliens-online/videos/aliens-online-redux-project-3d-concepts |
| ||
Two new screenies. Starting to mess around with lighting. Lights are attached to spheres so I can move them around wherever I want.  In other news a friend of mine has agreed to help me with the programming. This is great because now I can focus my attention on the art assets. |
| ||
| Update: 1/14/2014 I didn't give up on this but I decided to shift my focus back to my main project which started while I was still in college. Some of these assets will get tweaked and reused. Unless fans of Aliens Online come out of the shadows and demand this to be finished it's being put to the side for now. At this point it's been a real toss up between rebuilding the original game or taking the basic concept and modernizing it a bit. Who knows what I will do in the future? :) |
| ||
| Wow! I don't know if my advice can POSSIBLY be of any use to you advanced folks! But I ALWAYS simplify my meshes PRIOR to exporting them. I mean the rendered geometry itself. I'm doing a lot of hand-building of scenes right now. Yasha's definitely right about a simplified scene for collisions! But you should be aware (obviously) that macros are your friend, and a surprising amount of work CAN be done automatically (map cell generation), but sometimes you've just got to take matters into your own hands and optimize areas of your scene (then I have to redo the UVW projections again). Downside? Yeah. The cells aren't separate anymore, and you can't hide them for optimization algorithmically during rendering in the game by DISTANCE anymore except by frustrum. Did I just catch myself spewing nonsense? My maps are needfully simple because they're almost all outdoors and are HUGE. I would offer screenshots, but they look silly. Upside? One player only. I will be adding some read stupid NPCs for humor and decoration. |
| ||
| I'm not an advanced programmer in any sense but I do have a Game Design degree. Early on testing this FPS idea I did no optimizing, I was more focused on getting everything working. Later on I trimmed out all the extra unseen faces on the level meshes. Some of those grates could be done with textures but I have a bad habit of trying to model every little detail in 3D. Blitz3d can actually push a fair bit of polygons long as you're sensitive to the draw/rendering distance. Later on for these Aliens Online maps I went back and created a collision box for every room using minimal geometry as suggested. It all works very well but any aliens themed projects like this are always risky. On your own thread you should post some screenshots Mikorians. I'm interested to know more about your project. In between working on my ambitions Battlezone 2 inspired project I may churn out a simple 90's FPS similar to Wolfenstein or Corridor 7. I grew up with those games and always wanted to make my own classic corridor shooter. |
| ||
| I love the old FPS games. Mine is a special, kind of artistic thing. It started out as an experiment in virtual reality. I always liked the simple simulations like you'd find way back in the eight bit days. Plain by today's standards. But there were a few that were cleverly designed to be 'playful', Like my little example showing a lift and a spinner. I've been trying to recreate my old theme park simulation. It's a kind of carnival. Nonviolent. |
| ||
| Your post made me immediately think of Castle Master. One of the many Domark VR style games. https://www.youtube.com/watch?v=5l1bjzsPWBM I loved games like DOOM of course but if you got sick of the violence it was nice to relax with something like Driller, or Cybercon III. There is just something special about simple primitive shapes and that limited color palette I still find alluring to this day. It reminds me of a simpler time when computers still seemed very mystical and strange to my young mind. Are you a fan of Domark at all? I played around a lot with their Virtual reality construction kit when I got it. I still have two sealed box copies which are very rare. The 1.0 version game with a VHS tape which I still have stored somewhere. http://www.mobygames.com/game/virtual-reality-studio-20  |
| ||
| Those flat-shaded polygons remind me of the first Alone in the Dark. I was quite fond of the FM based soundtrack for that game, written by Philippe Vachey.  The main programmer for this game has done a "post-mortem" presentation in a GDC conference, and you can find it here: http://blitzbasic.com/Community/posts.php?topic=100829#1193729 |
| ||
| Alone in the Dark! What an absolute classic. It actually scared me to death. I think the 3rd one is underrated but each of them were really well done. Any of them could have been a great movie. Listening Hollywood? Wait no don't! What didn't use flat shaded polygons in the early 90's? :D At least Alone in the Dark had rendered/painted backgrounds. Mechwarrior and later the superior EarthSiege really are what turned me onto 3D gaming. When I finally got a 3d card it was all about Forsaken, Rainbow 6, and Tribes. Good times! |
| ||
| Yeah, you've got my tilt. The 2nd box shot of the kitchen below the mansion and the cityscape back then was captivating because of what WAS incredible detail. It was a time before texture maps. I continue to try to exploit this type of minimalism with curious, sometimes amusing results. I find that I can focus more on what an object DOES vs what it looks like. With appearance, you have to have a- "Aaaa! It looks fine!" Kind of an attitude. But you've got to watch yourself with the old games- like Venture, or you'll find yourself enjoying Polkas in the kitchen whilst you're cooking... |
   |