Jump to content
  • Advertisement

rioki

Member
  • Content count

    72
  • Joined

  • Last visited

Community Reputation

559 Good

About rioki

  • Rank
    Member
  1. rioki

    Nuclear Launch Console

    You both raise good points. Getting the timing right is sort of the hard. On the one hand the experience of a launch officer is basically just waiting around. On the other hand when you distill that in a game, I understand why people would go "why the hell would I do this?".   I think on putting more events into the game and reducing the interval of the drills. I was also thinking about messages sent by the enemy, that would not authenticate. Basically put more meat into the "story". 
  2. rioki

    Nuclear Launch Console

    Technically speaking once the missiles are unlocked you can hit the launch button at any time. There is no "software limitation" and that is sort of the catch.   The real question is, did you play the game until you got the real launch order? Did you launch the nuke?   This is what bothers me most, I fear that many will give up way before that. There are a total of 5 drills spaced 2 min apart, with the final order 2 min after the last drill. After drill 3 you get the alert message (sort of DefCon 3) and after the 4th drill you get a target update message. But I think that most people will be turned down by the waiting.   BTW, if you want to read the epilogues without waiting 15 min, you can read them at http://nlc.rioki.org/#/launch and http://nlc.rioki.org/#/nolaunch.   Thank you I will think about your input. I was thinking of implementing a "manual" that slides in from the side with more detailed instructions.
  3. rioki

    Nuclear Launch Console

    If you want to space 15 min of your time and find out if you have things it takes to launch a nuke, find out with the Nuclear Launch Console.   [attachment=23120:2014-08-11 21_13_01-Nuclear Launch Console.png]   Seriously, if you can find 15 min of your time, I would like some constructive feedback. It is a small experience I hacked together over the course of two weeks (~20h), but still interesting; I think,    
  4.   technically, OOP is not required for implementation of a C-E system.     That is true, but it helps. 
  5.   Yes! No! Maybe! Having implemented many a system, inside and outside of game development, I can say that a ECS does neither favor nor deter from a solid concurrent execution model. The most solid case for the ECS is the Intel Paper Designing the Framework of a Parallel Game Engine. Even through they never lose either the words entity or component, if you look at their universal object and associated specific system objects, it quickly looks like an ECS. In this paper they basically do functional decomposition to use as much concurrency as possible.    On the other hand in their excellent video series Don't Dread Threads, they make the very valid point that function decomposition has it's limits. You may actually get more out of your system by doing data decomposition. The key benefits here are two, first you probably can provide a higher level of concurrency and in most cases you can get away with almost no synchronization primitives. Using openMP to parallelize a few core loops may actually give your the biggest bang for your buck. Granted the real art is to do both, functional decomposition and data decomposition.   The thing that an ECS provides is an extreme level of flexibility at the cost of added complexity. In regard to concurrency it fares similar to other solutions. The key point here is added complexity; if a small simple system outperforms on one core because of memory locality an ECS with a high level or concurrency, you have gained nothing. Only use and ECS if you really need these extreme levels of flexibility.   Concurrency is like with optimization, don't do it until you really need it.
  6. I am honestly humbled by your constructive criticism. I must admit that writing this article was sort of a knee jerk reaction to yet an other starry eyed ECS article. After some introspection, I think my biggest qualm is not the ECS itself (it is just a pattern after all), but the naive and oversimplified rhetoric surrounding the issue. It is a bit like the screen graph gospel two decades ago. (Two decades?! I feel old.)   This article went through half a dozen revisions and rewrites, ranging in tone between CS paper and the ramblings of a crazy old man. I settled for my normal and rather informal writing style, I picked up from Jeff Atwood. The tone shifts at the end are sort of intentional, they interrupt the lull of the rhetoric and as a result make you question your line though and my reasoning. I must agree that this stylistic element is not the most popular.   Typos... I am dyslexic and even though I put a lot of effort into checking my writing for spelling mistakes, some always end up in the text. I am grateful for each typo found; i would rather have somebody point it out, than having the mistake linger.   Although I could have spelled it out more explicitly, the "OOP vs ECS" discussion is a non-starter and misses the point. Each and every article I have ever read about the ECS hat two problems it tried to address, a deep inheritance hierarchy and a god class. The problem is that the ECS is not the solution to these problems, it is rigorously refactoring the biggest offenders of well established  OOP design principles. The result will probably not resemble even closely an ECS.   But if the ECS does not actually address deep hierarchies or a good class, what does it solve? It provides flexibility where none would be. I fully agree with the approach the Unity engine took. Their use of the ECS is the solution to the problem "How do we get game designers to build objects without code?".   It is no coincidence that the other place I found an ECS outside of game development was in the implementation of a scripting engine. The ECS is great at providing a high level of flexibility, especially for run-time composition and for this it does the job quite well.   The flip side of the argument is that, if you need this high level of flexibility, why are you using a strongly typed language anyway? So my question is, if you need this high level of flexibility why are you actually not using a weakly typed system? It is shocking how few developers even know about the concept of duck typing or soft/hard layer mixing.   The reason why I did not delve into the specifics, such for example debugging, is because the ECS is already mildly flawed on a design level. What is bad about a wide inheritance hierarchy? The term you are looking for is "ravioli code".   One of the my biggest issues I have the articles about ECS is that few talk about how an ECS could fit into the entire engine. There are sane ways to integrate a ECS into your game, but none of the code samples I have ever seen get close sanity. (If you have actual rendering code in your components, you are doing it wrong.)   There are valid uses cases of a ECS, where the benefits outweigh the flaws. The important part is to be aware of these flaws and keep and open mind. Maybe the problem you are trying to solve can be solved differently than you initially though.   Thank you for the feedback, my writing and reasoning is far from perfect. 
  7. rioki

    Post Mortem: Da Boom!

    glm: http://github.com/rioki/glm pkzo: http://github.com/rioki/pkzo spdr: http://github.com/rioki/spdr   I forgot to link to the libraries in the article, will amend it.
  8. First off I want to say: Do not cut up user stories! I have seen this advice all over the place, but it is ill advised and comes from the Watterfall model. The falcy is that if you can't estimate one big task propertly then maybe you can estimate a five small tasks properly. The underlying though is that errors will even out (Law of Lage Numbers), but that is not true, small tasks have a bias towards underestimating and this results in an overall underestimation. And finally the entiere idea if a user story is that it describes one chunk of usefull functionality for the "user". If you chop them up you don't deliver that functionality until all bits are done. But now that they are choped up you stop seeing which user stories go together and you end up making the user whait longer and longer on the needed features. Back to the topic at hand. If you are starting to catch up so much delay this early, then probably your estimates suck. You have tow options either you start to use a estimated to real time function to correct the error. This is what they do with XP, you estimate in ideal time and then convert that into real time for planing. Take your current factor and apply that to all additional estimates. A different aproach is the poject velocity, you take the number of estimated man hours you where able to do this sprint, this is the base line for the next sprint. From this you can interpolate when your expect what feature to be done. These two metrics will change over time and often improve, since you often overlook mundane tasks that need to be done. Also if your estimates suck, you might want to look into planing poker. I think programming is the hardest to estimate task, since each problem is a new one. Although planing poker is not very acurate, but it takes into account that estimating is basically guessing and on average the result is quite solid. Programmers are a odd bunch, I know I am one and strongly suffer from the student problem. The student problem is, no matter how much time you give him for an essay, he will use up all the time. Many programmers want to make "the right thing", which unfortunatly often leads to overengineering a problem. Ask them how they would solve the problem in half the time. I have good experiance in pushing developers to do things in shorter times and then let them refactor the bunch into a properly formed application. Just time box each step and make the programmers comit to the timebox. Honestly I found it gives better results if you give them a fixed time and variable feature set than a fixed feature set and variable time. The odd thing is they are better at maximising (more featuers) than minimaising (less time per feature).
  9. rioki

    Ocean Rendering

    Really really really nice work. But... I happen to be an occasional surfer. The water looks quite realistically for a calm day on a large lake. How well do the waves scale up? I am thinking of a swell of around 1-2 m... True, I must admit that rendering shore waves is a real challenge. One thing I want to note, waves normally don't align themselves along the shore. Waves keep the basic direction and get slightly deflected by the shallows. This is quite important for surfers, because that means that waves start breaking at a specific point and keep breaking for quite a long time. If they did align along the shore and the shore happens to be quite straight they just go flop. Occasionally you see this nature... That are the days when you tend to hand out in a bar instead...
  • Advertisement
×

Important Information

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

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!