Jump to content
  • Advertisement

BoReDoM_Inc

Member
  • Content Count

    165
  • Joined

  • Last visited

Community Reputation

112 Neutral

About BoReDoM_Inc

  • Rank
    Member
  1. BoReDoM_Inc

    C++/SDL database?

    Sounds like another job for SQLite :)
  2. BoReDoM_Inc

    Parts of a Game Engine?

    Input, OS event handling etc. would also be a part of the game engine. AI is usually a part of a game itself. A game engine usually comes with tools for world creation, asset importing etc.
  3. Quote:Original post by kbar I recently went through myself looking for game engines, I put a list on my site at Game Engines That's a rather unusual list, how were they ranked? I haven't heard of quite a few on the list but XNA itself is not a game engine, it is a bunch of frameworks/libraries so I find it difficult to believe it could rank higher than any real game engine, including those that didn't even make the list. In regards to the new Unreal Engine Indie license it sounds very interesting. It doesn't come with source and 25% royalties will probably hit hard for some but I can't blame anyone for giving it a shot. Having access to a professional AAA-quality engine is quite exciting for indie devs. I know I'll be trying it out sometime in the next couple of months.
  4. Quote:Original post by Dryak Correct and I do, but I would like to publish my games for a profit and they won't let me do that on a student license. Where did you read that? It is the exact professional copy, same license. There are conditions listed on the Dreamspark website but they're not part of the official license nor do the forbid the using the software for-profit.
  5. Quote:Original post by Dryak As amazing as the Unreal Engine is, I don't know how to link it to Visual Studio Express nor do I know the language (of course, I could learn the language if I could figure out the linking deal) Not related to game engines but I thought I'd let you know that given you're a student you probably have free access to Visual Studio 2008 Professional via Microsoft's Dreamspark Program.
  6. I'm a university student myself, although I do work as a freelance game programmer as well. To be honest I don't know much about Leadwerks so I can't do a comparison for you. However according to wikipedia: "The base license for the Leadwerks Engine is a commercial license allowing the creation of any type of game/simulation with the exception of a game engine or overly modifiable game that will allow the end user to 'create something outside of the intended scope of the original product'. Leadwerks includes a full EULA and hosts the same file on their website[7]. The base license costs $150. A full source code license is available for an undisclosed price." If this information is up-to-date it looks as though you don't get access to the engine source-code. In regards to shaders, C4 has an in-built graphical shader editor, the purpose of which is to ensure that shaders look the same on all hardware. However at present you can't make your own post-processing effects although there are some built in. There is full support for LOD with planned support for automatically generated impostors/billboards. Here is a link to C4's wiki article on lights and shadows. In regards to culling, C4 obviously uses frustum culling but it also makes use of a portal-based culling system. I don't know if you're interested in terrain however terrain uses a voxels instead of heightmaps so you can create overhangs, you can still import heightmaps though as a starting point. Version 2.0 (due to be released this month) adds the first ever geomip voxel terrain LOD system as well as native rigid-body physics support. The community itself is great, there is a community contributed tools section available to licensees. There are free particle system creation tools, third-party physics implementations (PhysX and Bullet), exporters etc. In regards to learning about the C4 Engine the two best things you can do are look at the wiki and look at the developer documentation, both of which are freely available.
  7. If you decide C4 doesn't suit your needs that's fine although given the requirements you've listed I do find that a bit difficult to believe. Here are some screenshots, there are some more videos and screenshots in the showcase forum. C4 is without a doubt the cleanest engine I've ever come across in terms engine code and methodologies for building your own game using the engine. Like I said earlier though, I don't recommend paying too much attention to demo screenshots. What graphical feature do you feel the engine is missing? A company spending hundreds of thousands dollars into purchasing art for a demo rather than putting that money into resources and development of engine functionality doesn't benefit users of the engine. A common misconception about game engines is that if a demo has pretty graphics any game built with that engine will look good. This is simply not true, you can't use assets provided in the demo you have to use your own. It is the artistic cohesion of assets that make games look good and not the engine functionality itself. Graphical capabilities of an engine are only a theoretical limitation, unless you have hundreds of thousands of dollars to spend on assets you're not going to reach this limitation in any modern engine. NewBreed's suggestions of the DevMaster engine database was a good one. You can look at reviews from user's of many different engines.
  8. I highly recommend the C4 Engine. The current license model will give you unlimited updates forever. I've used C4 for over a year now and it is absolutely brilliant. I won't go into details as a quick look around the website will give me you more information than I could. The official demo doesn't do the graphical capabilities of the engine justice so I recommend looking at screenshots of other projects using the engine.
  9. majourab, I recommend that first you learn C++, this is a very good online tutorial. From there you have many options and different directions you can take. I would recommend that you start with 2D programming first. SDL is a great library that lets you focus on graphics, input etc. without worrying too much about OS specific code. SDL is great in that it can be used in conjunction with OpenGL. For learning OpenGL I recommend Nehe OpenGL tutorials. For engine development and game programming in general I strongly recommend this book. It doesn't delve too much into coding but it goes over a lot of key game development concepts and will help you relate maths to game development. You can probably read this book simultaneously as you learn C++, OpenGL etc.
  10. +1 for Codeka. Furthermore, why would you base your own game engine on Unity. Sure Unity is a great little engine but the majority of its power comes from the editor. As such the whole class hierarchy is designed to be used with the editor, unless you intend to reproduce the editor functionality as well you might find you're better off basing your own engine on something different. I'd suggest an open-source engine with a permissive license if you're worried about legalities.
  11. No worries at all. If you're curious the engine that I use is C4. Don't let the ugly textures in the demo throw you off though it's a very powerful reasonably priced engine.
  12. Technically the rendering code does exist and server does link against OpenGL. However this is simply because dedicated server functionality has not been completed in the game engine I'm using. Because the model functionality is a part of the engine when the dedicated server is completed the rendering code will not be compiled on the server. In regards to nodes, yes these are nodes in my scene graph. A controller has an Update() and Travel() method. It does not have a Render() method. The Render() method is included as a part of the nodes that need to be visibly displayed and is called by the engine when a world is loaded on the client. On the server the render methods aren't called and as such could be conditionally compiled. Mind you the code called in the Render() method actually makes no mention to OpenGL as the low level rendering is very well encapsulated, as such even if you did decide to leave this code around it isn't really a problem, what you would want to remove is the low level rendering code. This would be done with conditional compilation. I know a lot of people dislike conditional compilation, I also don't like it when it is done unnecessarily however in a lot of projects it is sometimes the cleanest (or only) solution, especially when you're developing cross-platform code.
  13. What you've got so far seems like quite a well structured design. The way I'd go about making the database would to have a table each for Cards, Abilities and Effects. The Effect table would have columns for all the possible statistics that can be changed as the results of an effect, hitpoints etc. If an effect can only modify one statistic then you would not need a column for each statistic that can change but instead you could just have a column that represents the statistic that will be changed and another column representing how much the statistic will change. Most importantly you will need an ID column. Then in your separate Abilities table, depending on how many effects an ability can have you could either have a column for each effect, or if you want to support an unlimited amount you could have a column that is a comma separated list. This/these column(s) would store the corresponding ability ID. You abilities would also have a column for a unique ability ID. Then your card table would have a card ID, name, description as well as columns (or a column with comma separated values) to store the IDs of the abilities of the card. Then the game could have three different dictionaries for each of these objects. You would load the effects first, abilities second and cards last. You would have a list of Effects in the Ability class. An effect would be added to this list as it is retrieved from the effect dictionary (using the effect's ID). A similar approach would be used for cards except that cards would have a list of abilities instead of a list of effects. EDIT: Changed the post so it actually made sense ;)
  14. BoReDoM_Inc

    Programming Guidance

    Given the current layout you've provided, in your Update() method I'd recommend you call the behavioural updating code first, this where you will set a bunch of flags such as movement direction. The behaviour will be different whether the object is player or AI controlled. The AI will run over a bunch of flags and consider a bunch of conditions and then determine what it should do. You would usually use a state machine for this sort of functionality, once the AI decides what to do the AI is said to be put in a certain state. As a part of the state the AI might decide it is walking forward, and as such you would set a flag telling the object to walk forward. For a player in the behaviour section you might check for input, or you might have a separate input manager that sets a bunch of flags for the player. For example when the player is holding "W" or Up you might set the forward movement flag. Once you've established the movement flag (or desired movement flag) you can do a bunch tests to ensure the moment is actually logical, i.e. Ray cast. If the player is up against a wall you probably don't want them to try and walk into it. If you don't check for this here in the behaviour section the model would animate as if it was walking but it wouldn't move at all because it's stuck against a wall, this way the model want actually try to walk. At either the end of the behaviour section you can apply a movement force and also set the animation the model will perform based on the characters final movement flags. I would probably have a separate method for movement so all objects get to run their behaviour before the world starts to physically update. In the movement section you would want to convert objects force and velocity to a resulting velocity and apply any translations to the model. In the movement method you'd probably also want update the models skeleton based on the amount of time that has elapsed and the currently playing animation. If done correctly you could make rendering run on a completely different thread. The rendering should only need to render the model's altered mesh (based on the bone positions) in 3D space based on the 3D transform that was changed in the movement section. EDIT: Collision detection and such would occur in the movement phase. You first move all object to their desired 3D position and orientation, if in doing so they passed through each other you would have to solve the collision based on a bunch of constraints. This can actually be quite complex and you'll have to read up about this and physics in detail.
  15. If the game is meant to be real-time then you probably won't want to use a database to store the cards types, although you certainly could use a lightweight SQL server like SQLite to store cards when the server shuts-down. When it boots up you can then load the cards from a database. In regards to this I'd recommend having only, at most two classes that represent cards. Each cards could have a bunch of parameters representing, health, attack listing, cost etc. each card type would then be registered in a dictionary container on the server (and client, although the client may not need the whole list). Creating new cards could be done two ways, first you could have an admin account that you login with from a client, then on the client you could display a card creator tool, once the admin has finished creating a card the data can be sent to the server, verified and then added to the list of existing cards. The alternative would be to update a database or text file where all the cards are stored, you'd still need some mechanism to tell the server to reload the list of cards and as such you'd probably still need an admin account to instruct the server to do so.
  • Advertisement
×

Important Information

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

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!