• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
proanim

Unity
engine design

22 posts in this topic

Since I don't want to use thing like Unity and the other robust free or commercial products or engines to make my game, I decided to make my own engine which will serve as at least bare bones for my game (as in it will have everything i need in all engine segments that are required for my game). I can program the game it self entire game logic no problem, but I need something to work with to do this.

When it comes to engine programing I always come to the same obstacle with shaders. How should shader support be designed in the engine so it is actually easy to use while programming the game?
0

Share this post


Link to post
Share on other sites
Its hard to answer your question will such little information.
A generic answer would be to have your engine process everything and then shoot the processed information to your graphics API and thats where your shader code would be.

You may need to provide more information so that others can input more specifically.
0

Share this post


Link to post
Share on other sites
Continue writing games. Then look back and factor out any common and reusable code. This will serve as the basis of your engine.
2

Share this post


Link to post
Share on other sites
[quote name='web383' timestamp='1355522617' post='5010760']
Continue writing games. Then look back and factor out any common and reusable code. This will serve as the basis of your engine.
[/quote]

+1.

This link helps to further this idea: http://scientificninja.com/blog/write-games-not-engines
0

Share this post


Link to post
Share on other sites
[quote name='L. Spiro' timestamp='1355664359' post='5011253']
Firstly there is nothing wrong with someone wanting to write a game engine as an educational tool and the topic-poster had a very specific question about game-engine development. “Write games, not engines” is not the universal solution. If it was then guess what: Games would never be made since no one spent the time to write the engines behind them
[/quote]This is a gross over-approximation. As much as I sympathize with the concept, I always took the recommendation as a hint to focus on design and logic rather than just logic. I don't think anyone suggesting that ever took this to the extreme of not writing logic.
0

Share this post


Link to post
Share on other sites
there is two kind of way treating shader...

one is make shader with designer for 3-4 month ( I highly recommend this way) In making game, theres is quiet just someking of ways of using shader...

so Art director and graphics programmer discuss on shader and for visual and for performance.. they work together and make some standard for it. after that sub artist use that shader and ask few modification sometime ..but most game have very similiar feeling about screen and light it's not often modifying standard shader.. just FX part need new shader constantly ( but it restricted very much)

this way is so simple and very productive and queit good for most game developpment.. even situation on Unreal3's shader tool supported , Art team don't make many formular on shader.. It's so true..changing basic fomular is huge chaos and so much work in Art team .

Secound way is as many big comercial engine build shader compositing tools.. you already know about Unreal 3 and others .( like unitity3) it's base cores is text manipulation and compile it and show to viewport...

It's have plexibility but, extremely hard to optimize and I doubt it's productivity.. It's good for just they don't have good shader programmer at all and need extremly complex scene and object.. really big game..

I hope it can help you... but.. don't worry about shaders it's just simple script :) ( of course It's very similiar ASM but.. think it so easy and be relax )
0

Share this post


Link to post
Share on other sites
Frankly I agree with the above post. There are certain things that are [i]obviously[/i] common to all games, such as loading MP3 or OGG files, PNG or WHATEVER graphics files, etc.
3D file formats are always custom. Loading a 3D file and any animations with it are going to end up being common to any 3D game you make no matter what (your own format, but always the same format for your own games, just with extensions added later).
Sound? Is pan not a feature of every sound engine ever? Is volume not a feature of every sound engine ever made?


There are [u][b][i]obvious[/i][/b][/u] ways to break down engine components into things that you will end up using across all of the games you plan to make, and the fundamental idea of “make games not engines” is simply flawed.


Make games and then look for reusable code? Why would anyone do that when we know from the start that we need a 3D file format, animation format, camera-animation format, sound format, image format, etc. We know [b]from the start[/b] that we need to support basic features such as sound panning, sound volume, camera panning, camera animations, 3D animations, etc.

Whether or not we get it right on the first try is unrelated to our objective. If our plan is to make a game, we will still fail to make the best animation format on our first try. Same if our goal is to make an engine.
Either way it takes practice practice practice.


So let those who want to make game engines work on game engine and practice practice practice.
Let those who want to make games work on games and practice practice practice.


L. Spiro
1

Share this post


Link to post
Share on other sites
[quote name='L. Spiro' timestamp='1355664359' post='5011253']
Firstly there is nothing wrong with someone wanting to write a game engine as an educational tool and the topic-poster had a very specific question about game-engine development. “Write games, not engines” is [b]not[/b] the universal solution. If it was then guess what: Games would never be made since no one spent the time to write the engines behind them. Not only that but I would be out of both a job and a hobby. Some people, myself included, appreciate the lower-level technology behind game development and enjoy learning about it more than we enjoy making the actual games. It is also true that some people dive too deep before they are ready, but this is not the way to inform them of that fact.
[/quote]

There is indeed nothing wrong with people wanting to throw code together under the gise of some sort of 'learning' experiance BUT I'm willing to bet that ANYONE doing that is going to end up with a mess which isn't fit for purpose WITHOUT a project driving it.

Of course games would be made without an 'engine' behind it - If you start from scratch you don't spent months putting together some grand unified design before working on the game, you attack the game, figure out what the game needs and then write the code for that bit refactoring and rearranging as scope changes. At the end you have a nice chunk of code, a shipped product AND code you can reuse as you know it is fit for purpose.

Yes, there are many people who like hacking on low level stuff, hell I'm one of them, but thinking you can sit in isolation throwing out code which is going to be useful is foolish, more so if you are a beginner/someone new to the process as you have NO IDEA what you want and need to do. To use the overused car example; it would be like someone sitting in a shed who has never designed a car trying to design and build a powerful engine block - sure they might be able to do it but when they come to try and fit it into a car they might be in for a shock...

If you take a step back you'll very quickly see that EVERY useful game engine which has appeared in the last 15 years has, at some point, started off as a game or been driven very firmly by game requirements; the Unreal engine was not developed in isolation and thats part of what makes it good.

And I don't throw this out there as a 'oh this could happen...' I've SEEN it happen in a company where a bunch of very clever people sat down to write an engine in isolation without a game to drive it (only a small test scene) and it didn't survive first contact with a game; large parts had to be rewritten (not refactored, chucked and redone), more had to be refactored, massive holes in the design came to light once someone tried to use it. Even things as fundimental as 'spawn an object in the world at runtime' was missing because it wasn't needed for the tiny world based test case. This wasn't some bunch of newbies, this was people who'd been in the industry sometime, had shipped games and still managed to screw up to the point where only one game will be shipped on this engine before it is going to be (effectively) thrown away and rebuild/salvaged using input from the games which will need to use it in the future.
(It also being done slower this time; before the 'renderer' interface was 'designed' in 2 days... this time out we are about a month in and still not settled on a design, although we are converging on something which everyone seems happy with.)

So if professionals can screw up then I give someone who is new at it no chance of producting something workable without a game as their primary focus.

Sure, if they want to spend months/years on something which they have to massively refactor at the end of the process when they realise 'shit, this doesn't work...' then fine, I don't really care, although I reserve the right to point and laugh at them when they realise this.

Thus, if you want to write something which can be used to power future games then write a game - you'll learn just as much if not more while producing WORKING and USEFUL code at the end of it. Even if you don't 'ship' the game at the end, or get 6 months in and decide to switch game project the point remains; with something guiding you'll still have usable code to run with.

Of course, if you don't want to power a game with your code then do whatever; it doesn't really matter, if you want to just get pretty images on the screen then you can just throw things togeter adhoc... *shrugs*
2

Share this post


Link to post
Share on other sites
[quote name='L. Spiro' timestamp='1355924877' post='5012435']
Whether or not we get it right on the first try is unrelated to our objective. If our plan is to make a game, we will still fail to make the best animation format on our first try. [/quote]

OK, so you invent an animation format AWESOMEANIM, you get it hooked up and working, you can see a character being animated in a window... how do you know if this is any good for a game to use? What constraints did you place on it? Did they make sense outside of a test renderer? How optimal is it? Is it going to slow down in a 'real' situation rather than your whitebox test space?

So yes, you might well fail to make 'the best' animation format but you won't know this until you (or someone) tries to use it at which point, depending on how badly you've screwed up, you might well end up throwing away 90% of what you've done in order to support what needs to be done. At which point you might argue 'ah! but we get to learn more!' which I can't argue with however I doubt you'll learn that much more as chance are the core principles are going to be the same, you'll just "learn" how to do them differently with a little bit of extra knowledge on top.

The same can be applied to sound pipelines, rendering pipelines (scene selection, sorting, rendering queues etc; all might look 'great' in your whitebox and fail in real life), UI system, message system.. the list goes on.

Without something to aim at you WILL screw up and you WILL produce code which is worthless and you WONT really learn anything more doing it again... well, aside from 'real requirements are important!' which is something so so so many programmers miss because instead of thinking "lets ask who needs to use it.." they start off with "I'm the best one here, so I'll just run with my ideas and not bother asking those who need to use it..." and then act surprised/annoyed when their "solution" turned out to be bullshit.
2

Share this post


Link to post
Share on other sites
While I agree with most of your post L. Spiro, I also advocate "practice practice practice".

[quote]Make games and then look for reusable code? Why would anyone do that when we know from the start that we need a 3D file format, animation format, camera-animation format, sound format, image format, etc. We know from the start that we need to support basic features such as sound panning, sound volume, camera panning, camera animations, 3D animations, etc.[/quote]
I need to comment on this though. I feel like you've used the word "we" as if everyone is as experienced as you in writing software. Not everyone understands the concepts of these core engine features - nor does every game even require some of the features you've listed above.

How does one even implement 'camera panning' without some concrete requirement of how it's going to be used? I'll usually fall into the "what if the end-user wants to do this or that" trap... and will ultimately end up writing a bunch of code that never gets used. Personally, I'd rather write a feature for a requirement of the game, instead of some generic feature. And then, if I notice this may be a nice chunk of code to use again, factor it out.

Writing software without concrete requirements can be very difficult, which is why I believe writing engines can be so difficult. Writing a game/demo/unit test is so much easier because those applications inherently come with a set of requirements which have purpose, and can help keep a programmer focused.

[quote]I'd much rather think of the "showcase game" of my technology as a way to shape the engine I've written for it. I would rather start with an engine that's broad in scope and use my first game with it as a way to iron out bugs in the engine, discover weak points in my engine code, and streamline the parts of the engine code that need it most so that when I make a game in the future, I have a solid tech to start with that I know will work and I don't have to remove a bunch of extraneous hacks that I had to use to force my previous game to even function.[/quote]
I can respect that darkhaven3. +1.
0

Share this post


Link to post
Share on other sites
[quote name='web383' timestamp='1355937929' post='5012508']I need to comment on this though. I feel like you've used the word "we" as if everyone is as experienced as you in writing software. Not everyone understands the concepts of these core engine features - nor does every game even require some of the features you've listed above.[/quote]

Then maybe that individual shouldn't be writing their own game engine just yet. It is common knowledge that a good game in this modern era generally requires that there be a standard format or formats for images in place that you will read from the disk, audio of some form, and some kind of user interface. I believe all of these can be cleanly separated into core components of a [i]game engine[/i], and you don't have to be the most intelligent person in the world or even a programmer at all to understand these requirements.

[quote]How does one even implement 'camera panning' without some concrete requirement of how it's going to be used? I'll usually fall into the "what if the end-user wants to do this or that" trap... and will ultimately end up writing a bunch of code that never gets used. Personally, I'd rather write a feature for a requirement of the game, instead of some generic feature. And then, if I notice this may be a nice chunk of code to use again, factor it out.[/quote]

This implies that the programmer has no idea what kind of game he will be programming, or will be somehow working on-the-fly without some kind of design document about how the game should be implemented written down first. If you are writing a text adventure, you know you will not need camera control of any kind. If you are writing some kind of 2D or 3D game, you will certainly need some kind of "camera" in as abstract of a sense as I can put it. Don't need a particular camera feature for your game? #ifdef it out in your game header files or something.

[quote]Writing software without concrete requirements can be very difficult, which is why I believe writing engines can be so difficult. Writing a game/demo/unit test is so much easier because those applications inherently come with a set of requirements which have purpose, and can help keep a programmer focused.[/quote]

If you don't have a game design document that clearly outlines the scope and format of the game before you start writing code, I believe you have more serious issues to attend to than deciding how to write your engine. These are all issues that seem easily resolved at the planning stage; if I'm writing a game for Gameboy Advance, I can have it on good faith I'm not going to be needing things like vertex coloring and DX11 tesselation. Likewise, if I'm writing a game on PC and I want it to look fancy, I can implement these features and I will know that I will need to have this information stored in some kind of consistent format.

In short, while I respect that you might find it difficult to write a game engine, it feels like you are assuming that everyone just writes game engines without some kind of idea as to what kind of game the engine will be used for.
2

Share this post


Link to post
Share on other sites
[quote]In short, while I respect that you might find it difficult to write a game engine, it feels like you are assuming that everyone just writes game engines without some kind of idea as to what kind of game the engine will be used for.[/quote]
Certainly not everyone. I did not mean to make that assumption. My initial comment meant to state that if one is having trouble writing an engine, then don't be afraid to continue writing games/apps and then refactor. The notion of "I must write an engine before I write a game" can be a trap for beginners with less experience.

If one is experienced and disciplined enough to write small unit tests for each feature and prove that their implementations work and their API's are intuitive throughout development, then I agree with your methods completely.

The bottom line is, just write code, fail early and often, write more code, and continue learning. This experience will only make you a better programmer overall.
2

Share this post


Link to post
Share on other sites
I think that writing engines isn't a foolish act, given the fact that there are a bunch of engines out there that everyone could afford even for a commercial application. If someone feels good writing their own stuff and feels strong enough to comprehend the concepts behind that or the other technical feature - then let them do it.
I think that if someone is capable of writing a proper engine, then they are capable of writing a proper game too. Writing the game logic and stuff sometimes isn't much easier than writing a renderer for example. In order to make a great use of any engine, a person should know a great deal of 3D math, theory and concepts.
The experience gained while diving into the code is priceless in the long term. You depend only on yourself, your game has no "back box" dll's, you understand how it works , you can put it in your portfolio, you can show your employer that you can write an engine + editor that the previous candidate could only use. :)
Does anyone have a statistics of how many successful indie games are made using third party engines ? [img]http://public.gamedev.net//public/style_emoticons/default/unsure.png[/img] Edited by solenoidz
0

Share this post


Link to post
Share on other sites
[quote name='L. Spiro' timestamp='1355532788' post='5010799']
Stitching means that your shaders are spread over many files, each file containing code for just one small feature/algorithm in the shader.
[/quote]

I am using the [url="http://prideout.net/blog/?p=11"]glsw shader wrangler[/url] for this, and I am happy with the simplicity and functionality I get.
0

Share this post


Link to post
Share on other sites
[quote name='phantom' timestamp='1355926687' post='5012443']
OK, so you invent an animation format AWESOMEANIM, you get it hooked up and working, you can see a character being animated in a window... how do you know if this is any good for a game to use?
[/quote]
Because:
[quote name='darkhaven3' timestamp='1355942626' post='5012540']
This implies that the programmer has no idea what kind of game he will be programming, or will be somehow working on-the-fly without some kind of design document about how the game should be implemented written down first. If you are writing a text adventure, you know you will not need camera control of any kind. If you are writing some kind of 2D or 3D game, you will certainly need some kind of "camera" in as abstract of a sense as I can put it. Don't need a particular camera feature for your game? #ifdef it out in your game header files or something.
[/quote]

In other words the only people who actually run off and code an engine without any clue what-so-ever as to how it will be used are people such as myself who intend to make a middleware company, yet even I have 2 ideas for upcoming games I want to make, meaning that even I am initially building my engine based on some idea of how it is going to be used.

Without experience you may not make the best animation system. Without experience you won’t make the best anything. But you know you’ll need one so you have to give it your best shot anyway, and there is no reason not to mentally organize it as being part of the engine.

The only time I write engine code without actually putting it into the engine library is when it is highly experimental for me and I basically consider that I am not sure how it is going to turn out so I don’t want to commit it to the engine yet. For example my first physics engine. The components and bits of math/intersection tests/collision detections/etc. were directly implemented into the engine because they are easy to prove correct, but the overall “engine” part of the physics engine was created between the game project and the engine project until proved to be working, efficient, and a satisfactory solid base (note I didn’t want to create a whole separate project for it so it was actually part of the game project but so isolated from the rest of the game code that all that would be necessary to move it to the engine would be to copy the folder and add the files to the engine).


Writing games and then trying to stockpile all the reusable bits—I don’t imagine that really works out most of the time. Your reusable bits go from project-to-project and get mangled and cluttered over time. It is easy for you to just keep copying the files to your new game project so you end up with a ton of copies of it and never really take the time to make a proper framework out of it. When you finally do you realize, “Oh, this file was supposed to be reusable but now I remember I was really excited to get results on X project and I threw in some illogical dependencies thinking they would just be for that project, then forget and it grew.”
“Hmm, this file relies heavily on my implementation of X feature, but for Y reasons that code needs to be rewritten so I can’t really move any of this ‘reusable’ file over to the engine.” (This case might actually improve your end results though assuming it forces you to rewrite that code.)

The only way to gain success is to be thinking fairly strictly about what is engine code and what is not, and if you are doing that anyway it is better to actually [i]do[/i] it too.
Besides, if you aren’t able to identify what is or could be reusable, you wouldn’t be able to make “make games, not engines” work for you either.


L. Spiro Edited by L. Spiro
0

Share this post


Link to post
Share on other sites
[quote name='RobMaddison' timestamp='1356036529' post='5012921']
If someone wants to write engines, they will. If they've got to the point where they have an interest in engines, they've probably already made their mind up and nobody on here is going to make them think "wow, writing games not engines, now why didn't I think of that". If they want to write games on the other hand, the same thing applies, that's what they'll do.
[/quote]

In my experience most people who 'want to write an engine' do so because they believe that writing an engine is some kind of requirement before writing a game. Most of these people want to write games really but due to hearing the word 'engine' a lot think the wrong thing and go off in the wrong direction generally because they think they must have an engine and don't want to 'do it wrong'.

[quote]
The OP asked about shader permutations and it sounds like he wants to write an engine and isn't just messing about - shall we concentrate on that?
[/quote]

The OP didn't ask about permutations at all.. he never mentioned them... he asked 'How should shader support be designed in the engine so it is actually easy to use while programming the game?' which says nothing about permutations at all.

Maybe shader permutations factors into this.. maybe it doesn't... of course without knowing what he wants to DO (beyond a nebulous 'make an engine' for some mythical 'game') and how things interact this is close to impossible to really advise on...
1

Share this post


Link to post
Share on other sites
The OP didn't ask about permutations at all.. he never mentioned them... he asked 'How should shader support be designed in the engine so it is actually easy to use while programming the game?' which says nothing about permutations at all.

Isn't this a touch pedantic? Shader permutations/integration/how they're handled in an engine, it's roughly the same subject matter.

I'll reiterate my point again, he wasn't asking for advice on whether he should write a game or an engine, he was asking about shaders.

This is just my opinion of course, if you guys want to wring it out some more, carry on...
0

Share this post


Link to post
Share on other sites

The OP didn't ask about permutations at all.. he never mentioned them... he asked 'How should shader support be designed in the engine so it is actually easy to use while programming the game?' which says nothing about permutations at all.


Isn't this a touch pedantic? Shader permutations/integration/how they're handled in an engine, it's roughly the same subject matter.

Not necessarily. Permutations were first mentioned in my own post, but an alternative was also provided called “stitching”.

But when someone asks about how to handle shaders it is an open-ended question, so using the fact that he never mentioned 50% of the options (since these really are the only 2 options) is a tad on the pedantic side (yes, strictly accurate, but you can’t be pedantic without being strictly accurate), specifically because the original question was open-ended.  You could say that he didn’t mention shrunken mice and rocket boosters just because it satisfies some pedantic quality.  “He never mentioned butlers and jet-packs.”  It is just unfair to mention all the things the original poster did not mention when trying to prove your point, simply because even if it is the correct answer he simply never knew to mention it, and that is the whole basis for that rebuttal.

 

However, yes, he didn’t mention it.  I did.

 

So you are both wrong.

And both right.

 

The best thing to do now is to let this thread fall into the obscurities of future Googler’s since the most important and relevant posts were fairly close to the start of the thread.

Any more and the next thing we know is, “Hello, I am from 3194 and I love to necromance topics when I have an opinion.”

 

 

L. Spiro

Edited by L. Spiro
0

Share this post


Link to post
Share on other sites

[quote name='L. Spiro' timestamp='1355664359' post='5011253']
The second problem I have is, Josh, Mr. Petrie, please change the title of your article. The things you say in your article are not wrong, but people coming into it start off with a false idea about what is trying to be proved and that is away with what they walk. I already posted multiple quotes from people who read your article and somehow took away from it that writing engines is a plague that must be avoided at all costs. They couldn’t even figure out how to write a game because every idea they had involved making some semblance of an engine and from your article they learned that that was evil.

[/quote]
I'll vouch for that. I've seen people with a link to the post in their signature, with the text saying "Write Games, Not Engines." They will take it right out of context.

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0

  • Similar Content

    • By Scouting Ninja
      So I am working on a mobile game.
      It uses slides for a story, the slides are very large. Each slide is almost 2048*2048; the max texture loading size I am using for the game.
       
      My problem is that Unity keeps each slide in the memory after it's loaded, even when it will show only once per game. This leads to the game crashing on older mobiles.
      My idea was to destroy each object after it was shown using a coroutine, so it deletes the past slide and loads the next slide. This worked because instead of crashing on 23 slides it crashed on 48 slides.
      After some profiling I realized that destroy() isn't clearing all the memory that a slide used.
       
      What I want to do now is assign a limited amount of memory as a slide slot. Then I need some way to unload the slide from the slot, freeing the slot for the next slide; without Unity storing the slides in the memory.
      Any ideas on how I would do this? 
    • By LoverSoul
      Hello everyone.
      I had a problem with transferring my character from the creation editor to the game engine. I created the character in Adobe Fuse, then imported it to Mixamo to put rig and animation.
      However, the appearance of my character has deteriorated significantly, and after importing into Unity, the character even began to look like a meme from the Assassin's Creed. Can you please tell me how I can fix all this so that my character's hair does not look like bits of bacon sticking to her head, and her eyes and mouth have taken their stable position in the skull?
      Thank you for attention.



    • By ilovegames
      Simulator driving with two modes of play - a race and free game in the open world!   Features: - 2 game modes - race and free game - 3 modes of transport - Buggy, ATV, Jeep - The open world - Realistic control - Modern graphics



      DesertTournamentSetup.exe
    • By NajeNDa
      Hi there,
      I am a game programmer (C#/C++) who is looking for a project to join. I am computer science engineer plus Master Degree in Game Development, currently working in one the most renown mobile games company (2 yeras academic experience, 1 year working experience).
      I have developed several prototypes or even games almost ready to release, but I always lack of artists, so I am looking for a project already set up or few artist to begin working in something.
      My preferences are:
      Unity or Unreal Engine 4 based project (UE4 prefered) PC/Console game prefered but mobile is accepted too Not interested in VR Serious team with almost all the roles filled or pretending to be filled 3D project prefered over 2D Guaranteed 7 work hours per week, Crunch 20 work hours per week  European team (if timezone is not a problem for you, so its not for me) I am not looking for any kind of money income from games neither the team, I want to do this as a hobby and a way to improve my skills.
      Cheers
    • By INTwindwolf
      COMPANY AND THE PROJECT

      We are an indie game studio consisted of professional and friendly people. Additionally, we are a team of skilled artists and dedicated indie enthusiasts. Our current project is INT, developed on Unity Engine 5 for platforms Windows, Linux, and Mac.

      INT is a 3D Sci-fi RPG with a strong emphasis on story, role playing, and innovative RPG features such as randomized companions. The focus is on the journey through a war-torn world with fast-paced combat against hordes of enemies. The player must accomplish quests like a traditional RPG, complete objectives, and meet lively crew members who will aid in the player's survival. Throughout the game you can side and complete missions through criminal cartels, and the two major combatants, the UCE and ACP, of the Interstellar Civil War.
      For more information about us, follow the links listed below.
      INT Official website
      Steam Greenlight
      IndieDB page
      Also follow social media platforms for the latest news regarding our projects.
      Facebook
      Twitter
       
      TALENTS NEEDED
      Website Administrator
      Unity Engine Programmer
      Please note all of above are remote positions. You will not be required to travel or relocate.
       
      REVENUE-SHARE
      We are unable to offer wages or per-item payments at this time. However revenue-sharing from crowd-funding is offered to team members who contribute 15-20 hours per week to company projects, as well as maintain constant communication and adhere to deadlines. Currently the crowd-funding campaign is scheduled for the first half of year 2018. Your understanding is dearly appreciated.
       
      CONTACT
      Please click each position to view the job in detail, as well as application instructions.
      Thank you for your time! We look forward to hearing from you!
      John Shen
      HR Lead
      Starboard Games LLC
  • Popular Now