• Advertisement
  • Popular Tags

  • Popular Now

  • Advertisement
  • Similar Content

    • By Michael Santer
      Hi!
      We're currently two programmers and a game designer working on a turn-based tactics fantasy board game. For reference you can search for images of "Tactics Arena Online", a fairly dated game that used to have a lot of depth and complexity.
      Our goal is to use the same combat concepts, but giving it a much needed modern touch as well as a whole new set of heroes to choose from with additional abilities. The game is a mix of isometric and 3D and we plan to release the game on Steam and hopefully Android & iOS as well.
      We are looking for someone to work with us pro-bono (just like we're doing) as a 3D character artist. The skills needed are creativity, a hard working attitude and an ability to make minor animations (things like idle, walk, block and very rudimentary attack animations). A perk to have would be the ability to make some VFX. If the game makes it on steam and money starts coming in, you'd obviously be compensated for your hard work, but as it stands this is a hobby project to garnish your portfolio.
      A bit more about the game:
      This game will be an online multiplayer game where each user gets to pick up to 10 characters to place on his half of the board (this would be done before even entering matchmaking. Think runes in League of Legends for example). The user can place his 10 units of choice anywhere he likes on his half board. Some units can be used more than once. So if you want 4 knights and 2 mages or even if you want 10 clerics, you can do as you please. You can then save your setups for future use. The goal of the game is to wipe out the enemy team.
      Each character or Hero (except premium and abyss characters) start with 1 ability and they can ascend (either by playing a certain amount of matches with the character or by forcing the ascension with real money) to gain a new ability or passive. Acquiring a new character can be done by using in-game currency that you earn from playing matches or using real money with the exception of Abyss characters which can only be acquired by winning certain rare matches. The goal is to offer a freemium game with lots of customizable elements while making sure that no user can "buy power" with real money. We want everything that a paying user can get to be available to non-paying users who play the game a lot.
      Ultimately we want this to become a competitive game that people can enjoy and really get invested in. Each character is designed with options for counterplay in mind and synergy with other heroes.
       
      We sincerely believe in what this game can become and we home to find someone just as passionate as we are to get involved in this project!
    • By CrazyApplesStudio
         Hello , i would like to showcase my first game project, a simple endless casual arcade game called Apples Mania : Apple Catcher. The game has simple goal , scoring as high as possible by collecting falling apples while the difficulty gradually increases. Different apples are worth different amount of points and there are also 2 power-ups to help you in your challenge.
        The game took me about 2 months to complete and polish and i made everything except for the music tracks and some of the sound files. Made in unity and blender3d.
        Would appreciate any kind of feedback.
      Google Play Link
       
        A trailer showing basic game-play:
       
    • By Paszq
      Troglodytes are a playable races in Arpago - they usually don't talk much and most of them lives near water sources.
    • By Paszq
      a Fox in a dungeon :)
    • By Paszq
      Fox Folk is one of 3 playable races in Arpago.
  • Advertisement
  • Advertisement
Sign in to follow this  

Unity Engine Design

This topic is 3950 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello everyone, I'll do a quick outline of what I'm using first. Microsoft Visual C++ Express Edition 2005. Mainly programming for Win32, though I plan to eventually port to Linux. I'm using OpenGL for graphics. I'd like a few suggestions on my engine design. It's not strictly a game engine, more like a graphics engine (That can be used for games, obviously). The whole engine is based on a hierarchal design (see example below). This makes it easy to program new parts to the Engine, as well as update the old. However, it also means there's very large include-trees (I think #including one .h file causes 10 other custom ones to be included at one point, which in turn includes even more standard .h files). I'll provide my texture management system as an example (though other parts are based on the same design, ie: geometry, sound, physics, network, etc). I have two low-level classes. One class is the 'buffer', which manages holding image data in system memory, as well as loading files from the hard drive. The other class is the 'Texture' class, which manages the OpenGL texture ID, and copying the data from system memory to the GPU. On the next level I have a class called 'hTexture', which requires both the 'Texture' and the 'Buffer' class to operate. It manages swapping the texture from the GPU/RAM/HD as needed. On the same level is the hGLSL class which manages GLSL shaders. Then, on the next higher level I have the 'Material' class, which, as it sounds, handles opengl materials. It combines multiple 'hTexture' classes for multitexturing, handles properties (glEnable), and requires the hTexture and hGLSL classes. I've spent 1.5 years programming the Engine, so redesign is not an option, however, I'd like any tips and comments about the above design. Is it good? Is there anything I should watch out for? Any interfaces I should provide to the end-user to make it easier to access? In theory, the end-user should only have to access the 'Material' class to make it all work. On a completely different note, my engine requires a WindowContext to be created to display the window, and create an OpenGL context. Some variables in it need to be shared with other classes, however, there may not be any opportunity to pass the WindowContext to the class as a pointer. Currently, my solution to this is to create a global pointer with the current active WindowContext class. However, to have multiple contexts requires switching between each context on a single thread. A more efficient solution would be to have multiple threads, each with its own WindowContext class. However, this makes a single global pointer to the current class unreasonable (as there could be multiple current classes at the same time). I've been reading about TLS (Thread local storage, via __declspec(thread) ). Is this a plausible method? Is there a better way than having a thread-specific global pointer? Thanks for reading my essay I'll appreciate any feedback you may have, ~Zix

Share this post


Link to post
Share on other sites
Advertisement
A few comments:

1 - Why, oh why hTexture? Hungarian notation needs to die an evil death (Only thing I can think of for the hTexture thing). Intellisense rules!

2 - I prefer to keep things simple at the lower levels. You said you have a buffer that loads the texture and holds it in system memory. I went a different route. Putting my loaders (game can use/make custom ones and register them) into their own area and they pass back a buffer which my texture class holds. That in turn is referenced by the material class as one of it's "skins" (bumpmap, specmap, etc). I figured a texture shouldn't load itself, it should just manage itself. But I've seen it done both ways.

3 - You should really abstract out all the OS stuff now, otherwise porting will be a nightmare. It's never too late technically, but mentally it's a chore to do later.

As for your "bonus" question :)

Our engine handles windows creation itself, holding and passing the window handle around as an ID to the other parts of the engine that need it. I use an internal messaging system to do some of this passing later if its needed. Technically the engine currently can create multiple windows but it doesn't allow to multiple message loops. I don't need it right now but it is on the "if you have time and are really bored" feature list :)

Share this post


Link to post
Share on other sites
Thanks for the suggestions. In general, I've moved away from the hTexture notation style things. That class happens to be over a year old, and some of my programming styles have changed since then.

I also can't imagine porting being too hard. I only have to modify the WindowContext class, the sound initialization (FMOD is cross-platform), and the socket management. All of the libraries I use are cross platform, so it shouldn't be very difficult.

I might implement the internal message system idea, though.

Thanks for the suggestions,
If anyone else has any, they're still welcome
~zix

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement