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...
  10. Ok, this might be like the wrong answer and completely over the top, but here is my implementation, of my new defunct project: http://libqgl.svn.sourceforge.net/viewvc/libqgl/trunk/obj2qgl/src/ It's obviously over the top because it uses the parser construction tools bison and flex... Even if you think it is overkill, I would suggest that you write a lexer / parser with a more standard approach: char stream -> lexer -> token stream -> parser -> objects You have a lexer (aka. tokenizer) that determines the type of token and the associated value. The you write something like a recursive decent parser that will trigger on the "keywords" (o, g, n, f...) read a batch of values. You detect errors when you get a token that is not of proper type. You should look over your code. It's awful, for C++ code. But I can't see any obvious flaw.
  11. rioki

    How road creation works?

    It is true what pto and Hodgman said. This technique is commonly used in game development. I just wanted to point out that there are other techniques that are more procedural. You can model a terrain and add roads by placing way points. By using some heuristic the terrain is altered to match the road and make it look natural. For example on a slope the terrain is caved to match the road. Then buildings and other Objects are placed on the terrain. This works for any game, including racing games. Examples for this are CityScape as seen on GameDev or the CryEngine2 Sandbox.
  12. rioki

    Skydome and clouds

    It really depends... If your are marking a 1st or 3rd person game where you stay on the ground, maybe a skybox with photo texture may be a better bet. Does it have to by dynamic? You can buy a set (6) of high res textures for 10 bucks or google soem free ones... Of course you can implement the cloud rendering algorithm detailed don this page: http://www-evasion.imag.fr/Membres/Eric.Bruneton/ The question is it worth the effort...
  13. rioki

    Max array size C++?

    Quote:Original post by jpetrie Quote: It really depends on the model itself. Im just coding the loader. I dont want to put a limitation on the 3d artist. If an object requires 10000000 (unlikely) vertecies I want to be able to support it. Even thought it might run a slow. Why aren't you using std::vector, then? I do not want to deter the question. You are bound by stack size if you use static arrays. To get out of that problem you can use dynamic memory; then your have about the size available in your virtual address space (32 bit / 64 bit). But it seems you want to hard code the array size. Why the hell do you want to do that?! Use exactly the size needed. This can probably be read out of the model format before reading the single components. Finally, here is a general rule of thumb: Do not allocate arrays of things with new. It is error prone and you gain little in performance or memory consistency. Use standard containers. If you use standard containers use std::vector if you *need* to have continuous memory space. In all other cases use one of the containers std::list, std::deque or std::set depending on your needs. (std::map is special case for key/value associations.) http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=204
  14. rioki

    SDL Sprites

    If you look at the sprites you can see that the point of reference is the bottom. So basically you can align them to that point of reference. A trick you can use is to keep all sprites the same size. Use the largest sprite and leave larger blank spaces on the smaller ones. In that case you do not have to care about different sized sprites.
  • 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!