Jump to content

Pixel Perfect

Members
  • Posts

    2,110
  • Joined

  • Last visited

Blog Comments posted by Pixel Perfect

  1. Definitely not crazy Ken, this is very nice indeed. I too have kind of followed a similar path in my development creating my own editor in which my game engine runs in real time and I can switch to edit mode at any point and edit in real time.

     

    DDD and real time editing has some huge advantages and is a great way to work intuitively especially when designing and testing game AI. Like you are suggesting with your engine; my engine currently supports FPS as well as RPG/Adventure game functionality (the hard coded side) and is pretty much data driven too. There is still some way to go as I guess there is in yours but essentially it sounds like a similar approach.

     

    I really like your editor interface and tools, very nicely thought out and implemented. I look forward to seeing how you progress this, you are demonstrating some great skills and concepts here!

  2. Sorry for that, it's just lazy and implied quoting on my part. Honestly it's exhausting sometimes trying to give arguments in text as you have to cover your butt so much as to not offend or leave gaps. I much prefer in person smile.png

    That's ok Rick. I wasn't implying you had deliberately set out to misrepresent what I'd said. It's not always easy when replying quickly on forums and I'm sure I've probably done the same in the past.

  3. I felt that the "For anyone already familiar and skilled in C++" has no merit in the statement.

    I know C++, and I was listing reasons why Lua has some advantages over it (agree to disagree sort of thing).[/Quote]

    Advantages exist for just about everything you care to look at in life, but people don't base informed descisions on advantages alone, it requires a much more balanced weighing up of both advantages and disadvantages.

     

    I stand by what I said and, within my full statement, there was never any inference that Lua couldn't be used to develop a whole game. However, the cut down sentance you posted would imply just that to most people reading it. Neither did I mean to imply that AI or game logic was neccessarily simple, but that Lua was simply being used as a scripting language in this context.

     

    The use of Lua as a scripting language to code the 'game' as opposed to the 'game engine' which was what I was advocating brings about the major advantage you've cited for Lua anyway, namely no need to recompile during the game development cycle.

     

    I have no problem with you disagreeing with anything I say Rick, that's your prerogative and I'm open to a convincing argument anyway. But I dislike being miss quoted, as that is no longer a true representation of what I said, regardless of whether you think the rest of it was relevant or not!

  4. You always take my comments completely out of context Rick. I said and I quote

     

    For anyone already familiar and skilled in C++ I can see no advantage in using Lua other than as a simple scripting language.

     

    not

     

    I can see no advantage in using Lua other than as a simple scripting language.

    which completely changes the meaning of the sentence. I don't understand why you do this!

  5. For anyone already familiar and skilled in C++ I can see no advantage in using Lua other than as a simple scripting language. To have the game engine framework and mechanics written in C/C++ and the game logic and AI scripting implemented in Lua seems ideal and makes full use of the underlying benefits of each language.

  6. I think the design is very critical in an LE game where you have multiple people because part of that design would need to be the interactions between components. Start a project where you, NA, Master, & Max make a game and only give a vague design and tasks and combining all that code will most likely be a nightmare. But have a detailed design doc where you describe the functionality for a specific task and the interaction interfaces that task needs to expose/consume and you'll have a much better chance at success.

    Sure, if there is to be a common communications interface used by all components then someone would need to design that up front, that almost goes without saying as you are requiring everyone else to use that, but then the rest boils down to functional specs again for the remaining components.

     

    If you want say a path finding system writing, or a foot placement system with IK, or a blended animation manager please don't tell me you'd be designing all that up front and telling me how to code it because that would probably result in any decent programmer walking at that point as you have effectively de-skilled the job and demotivated your staff by turning them into a team of monkeys who just churn out code.

     

    Sure you can operate in that way, but that's your own choice. It's not because it has to be that way. Maybe lots of software houses do operate in this way and I've just been lucky in not working for any of them yet, I don't know.

  7. In my working experience of team based software development programmers are given functional specifications to work from and actually do all of the design themselves, often starting with a detailed design document which may be subject to review.

     

    I admit that where an actual game engine is being designed which is a fairly performance critical component there might well have to be much tighter control on the overall design, but again you would expect to employ people who have experience in this field and any desired techniques to be implemented discussed in advance of any design work.

     

    When it comes to people using Leadwerks to design their games I wouldn't have thought the design was that critical in many areas for someone to have to do all the design up front simply to delegate it out to programmers to code, unless the quality of the programmers employed was very poor!

  8. This argument ends in one place and one place only ... no future gaming if you take the big players out ... was really refering to removing all of the big companies including the hardware producers as the argument seemed to be edging towards big is bad.

     

    I totally agree that we could lose the big software houses overnight and smaller companies could supply games to the market place. But then capitalism being what it is will simply start the process of growth and acquisition all over again and we'll be back to where we started.

     

    I don't disagree with you Josh over the efficiency gains of remaining smaller but modern life demands a lot of companies need to operate on a scale well above this and its inevitable that they will no longer be as adaptable or possibly innovative as the smaller ones, but they do deliver things the smaller companies are just incapable of delivering and as such are often needed.

     

    I don't personally see the big game companies disappearing any time soon because, as Afke pointed out, they know there is a constant stream of new purchasers coming on line and lots of people crave big block buster type games as well as movies. But it's certainly never been a better time for small Indie developers to sell their games too.

  9. Well I don't think the millions of people buying MW3 are doing so out of an obligation to make Activisions shareholders rich, they are doing so because they genuinely enjoy the games, regardless of whether we feel they are getting real value for money!

     

    I'd also like to point out that there is no escape from the multi-billion dollar companies of this world where gaming is concerned .... as the hardware they all run on are produced by them. We don't get little Indie hardware companies producing affordable tablets and mobile phones for worldwide consumption do we, or even better 'Open Source' hardware :) Shall we damn them and their shareholders too! This argument ends in one place and one place only ... not future gaming if you take the big players out.

     

    Sure we Indie game producers have a rightful place in all this and can cater for a market that wants more creative output rather than just playing it safe and churning out the same content over and over again but lets not lose sight of reality altogether! Hollywood has been doing the same for countless decades. You don't need to like it but to say there is something wrong with that is elitist ****, it simply caters for a market that exists. That's what capitalism does!

  10. There are good examples and bad examples at both ends of the spectrum and to make out that small is good and big is bad is not really very scientific or to be honest very astute. Minecraft may sell like hot cakes but fails to keep my interest much beyond half an hours game play whilst Skyrim (which has also sold like hotcakes) has had me hooked for the last two weeks continuously. If that's an example of game companies targeting five year old technology and not pushing the technology forwards then fine, because it delivers on the sort of game play I enjoy. Maybe pushing technology forwards is not all it appears to be .. as to use your own example most Casual games are hardly pushing the technology forwards, they are simply running on the latest technology!

  11. The simple fact is large teams are required for large endeavors. You are not going to make a modern AAA title with two people so big teams are required if that sort of product is being created.

     

    I agree with Josh in as much as any large production team will inevitably have a few key people at the top with the big picture who have the vision and direct things. Certainly, large team work does require different working practices and procedures as Rick has already hinted at. However, if its handled well there is no reason why individuals within a big team can't contribute to the creative process and inject their own input. It's really down to how the key people choose to manage the projects.

     

    What I'm really saying is large team production work requires a completely different kind of professionalism and discipline from small Indie projects. It is what it is, I don't really think it makes any sense to compare one with the other as they are such different endeavors.

     

    I personally find working in small teams more rewarding as the level of involvement in the overall project and communication is far greater, however, the scope of the projects are always going to be correspondingly smaller. So it is good to get experience of working in larger projects but you very much need to be a team player and not everyone is cut out for that. Some people have a nature where they need to control everything or have communication problems and are unable to work effectively with others.

     

    But as a general 'look at what I've done so you can do it too' prep talk I agree with Josh. If this forum is representative of a lot of others I'd guess that probably less than 10% of the total membership of this forum have ever worked in the software industry so have any first hand experience of this.

  12. I don't see any of this behaviour in EKI One which is using Recast, so I'm guessing its just an issue with understanding at this point. You'll get there! Interestingly, why is the nav mesh seemingly being generated as a uniform grid type system of tiles and not optimized. There are huge area there where tiles could be represented by a much larger polygonal area.

     

    This is the type of optimized nav mesh generation I am used to seeing with Recast, also shows off the dynamic regeneration quite nicely (you might want to take a look at this Naughty Alien):

×
×
  • Create New...