Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Member Since 18 Nov 2013
Offline Last Active May 08 2014 05:40 AM

Topics I've Started

Object interactions in a multithreaded game

27 November 2013 - 03:16 PM

So I have been doing research into multithreading for no reason other than curiosity and I have noticed something which I'd like to bring up. 


The best way to multithread any software, apparently, is data-decomposition. As in instead of putting subsystems on different threads, you break up the processing of one subsystem into multiple jobs to do concurrently, scaling to n number of threads. 


This is all fine and dandy, but say if you were to do this to the physics system, my logic would be to break it up so for n threads divide the number of objects by n and give each thread a group of objects to update. Then you would have a situation were conflicts would occur. Say object A collides with object B, but A and B are being updated at the same time on separate threads. Problem.


Another example is for updating game logic on gameObjects. What if object A is dependant on the health of object B. But again, they are being updated on different threads.


Now I know the simple answer is, minimize interaction and communication between objects, however this is not always going to be good enough, especially in physics, since object interaction is critical to the function of the system.


I have not worked on a game were objects never have to talk to each other, so how do you get around this problem when designing a multithreaded game?

Singletons in a component based architecture.

25 November 2013 - 02:10 PM



So I wanted to write a game using a component based architecture for the obvious reasons of wanting quick iteration and such, thats not my point tough.


What I have thought up is a system were components are implemented in Lua instead of c++, and then Lua can call functions that are implemented in c++. All fine and dandy, however I see a problem.


From the c++ point of view most of my code is just going to be a list Lua functions implemented in c++, with no need for inheritance or things such as that.


Furthermore, if I just put all these Lua functions in classes, as merely namespaces, I will have code, from the c++ point of view thats just a bunch of singletons, with Lua functions in them.


This goes against what I know to be good practice in c++ OOP programming. So my question is, everyone talks about the components and data, but what about the rest of the code, is there a way that all this functionality is normally implemented, as in the functionality for components to use?

Should I open source my engine?

22 November 2013 - 09:41 AM

For the purpose of learning I started making a game engine (fully featured, editor, scripting, asset management, .....) over a year ago. Now though its grown into the largest project I have ever undertaken and I am quite proud of it. Its not perfect, but I made it with huge effort and time. So now I come to my dilema. I have two options:


1. Make it open source, and have far better programmers help out and make it even better than I ever could. This would encourage it's use in real world game development and I could sit back and smile in happiness that I started this engine that is used to create games. The biggest reason for doing this is so its development could be aided by others to make it as good as possible. The downside is that I would not be paid for my hours of work. This is a big downside.


2. Make it closed source, and charge some sort of business model to try and make money from it (like Unity). This would mean I would get money from my hours of hard work. The money would be used to live, and improve the engine. The downside is that it may not improve very rapidly with me at the helm and also, the market for selling engine license is very small, and I may not make very much money at all. I could have an asset store type thing and make money in this way as well, although the market is currently dominated by Unity.


Leaning towards making it open source, I thought maybe I could make money in other ways, like selling tech support and training. I have no intention of become rich with this engine, I just need money to pay for food and such. I lean towards open source, because it would make me happy to see it grow, although not completely under my thumb. I have yet to make a decision and I would appreciate hearing other people's thoughts.

Can text adventure games still work?

19 November 2013 - 01:25 PM

While playing a game called Device 6 on iOS recently (interactive novel type game) I thought to myself, could text adventure games still work these days?


I'm sure many talented game designers could craft brilliant text adventure games, the problem still persists that graphics these days is used to market games. Since people cannot play the game they get shown pictures and videos. This can't work for a text adventure game.


I thought maybe a well made demo could replace trailers and images to entice players more. The recently released Stanley Parable has shown me that, when done well demo's can be very effective. Most demo's these days cause a drop in sales of the game in question.


So theres two parts to this. Firstly can a text adventure game be fun when compared to modern games? And secondly, would it sell?


I suppose this is a wide question but I thought it would make for a nice conversation topic.