Jump to content
  • Advertisement

coderx75

Member
  • Content count

    1426
  • Joined

  • Last visited

Everything posted by coderx75

  1. I prefer to keep game development as a hobby and engineer enterprise applications/web services by day.  I rarely work late which affords me some time to work on a game.  This gets tricky though.  I spend nights with the wife and kids so I'm usually up anywhere from about 3:30am to 5:30am.  I'm at work by 7.  I bring my laptop so I can work on the game during lunch.  Sometimes, I get some time in at night on the weekdays and I usually knock out a good 8-10 hour day on the weekend.  It's tough but I get the best of both worlds: professionally engineered solutions vs. crazy-fun game stuffs.   My two cents on keeping game dev sane: - Learn to refactor and keep doing so until you have a solid, comfortable-to-work-within(TM) game framework  - Make time for the non-gamey stuff: tools, menu systems, etc. - Make time for the cool stuff: I used to put all my time into the big tasks but have started maintaining a list of really cool, easy(-ish) to implement features and tackle those whenever things get stale.  A lot of great gameplay and unexpected features have come out of this.
  2. coderx75

    Tech Arena Returns!

    Not so much of a "return" as it's been in development. Things had slowed down during the whole family-building process but have been in full swing for the past few months (as in spare-time full swing). Tech arena allows players to build vehicles (and pretty much anything they want to) from components and compete against friends, enemies and AI in an arena. These components and their functionality are each defined by scripts. On the front end, the player may create new components from existing types but these types are really templates of Lua scripts. If one so chooses, however, they can use the in-game code editor to write their own components from these templates or from scratch. I've posted a new video testing out the new rocket launcher component and the physical effects of explosions in general. Fun stuff!
  3. coderx75

    Slightly ambitious?

    I've had some experience working with large-scale maps in my own projects. What I've learned is that in-game real estate is a serious consideration. As scale increases, the complexity of the required code increases exponentially. More importantly, the purpose for the extra playing area becomes questionable. Essentially, you're investing development time to increase player enjoyment. Being in charge of a project, one must constantly consider the return on investment for time spent by the team. As the world size increases, the return on investment quickly decreases. From the player's perspective, how much are they getting from the larger world? At some point, the answer eventually reaches zero and the justification for the larger world (time vs. return) dwindles long before that. I'm pretty skeptical of to-scale planetary surfaces in games (we're still a long way from pulling it off AND making it interesting to players) and 184,000 times the surface area of the Earth is just not happening for under a half-million dollars. This would be a fantastic project to attempt on your own but it's a risky game to play with other people's money. I'd suggest building a small-scale planet surface with content, collision detection, etc. to get an idea of how difficult it can be to have all the components of a game working together effectively at that scale.
  4. coderx75

    Dawwwww

    The irony of your forum title just hit me. HAHAHAHA!!!
  5. coderx75

    Dawwwww

    Congrats! And you'll sleep again... if you shed any notion of staying up past 9.
  6. coderx75

    Help me pick a logo!

    jjd makes a good point that the silhouette does not scale well. The overlay of the blocks only makes the shape harder to discern when reduced. On the other hand, the silhouette just screams "game company!" I really like the idea that it seems to be jumping off of the logo as if in a platformer. I'd lose the blocks though. Remember: a design is good not when you can not add any more to it, but when you can not take any more away. Try Servant's original idea without the blocks and just the blue color rather than red. Perhaps a different or modified silhouette might make is scale better as well. Maybe not. That silhouette's growing on me.
  7. coderx75

    The Making of Epoch, Part 1 - Why?

    This is pretty ambitious. I saw your last post and thought, "Five years to write a compiler?" Now, I see. This made me think of an idea I had a while back for a compiler or VM (or both) that relied completely on metaprogramming. I don't know if it would be of any use here but I thought it might be worth sharing. The idea was inspired by metatables in Lua and I thought "why stop there?" What if the behaviors [i]and[/i] features of the language could be externally implemented and defined through metaprogramming? I never really fleshed out the idea but, if it could be done, it would make the development of a complex language more manageable. So, the syntax would be designed around metafeatures and the features would be defined through it's metaprogramming, even going so far as to allow code in separate modules of the same application to use separate memory management schemes or even compilers (bytecode or binary). Sounds cool though I'm not sure if this would lead to more bad than good... and the performance... eesh. =/
  8. coderx75

    Future of Gaming: Facts

    [quote name='neutrix' timestamp='1326387611'] This leads me to believe that it is a very very long way off, even if it is possible. [/quote] It's good to have someone weigh in with some background in quantum computing (I don't know enough to really give solid arguments) but I think the above statement pretty much wraps up every argument I've made in these two posts. LoreHunter is prophesizing on the future of things that we're already working on every day and I'm trying to give my insight on the things that I have experience with, showing there are drawbacks that cause the technologies mentioned not to match the (mostly his) hype (long way off even if possible). Anyway, it's a lost cause. I need to go do things that have a hope of being productive. [quote name='LoreHunter' timestamp='1326388140'] ...believe me. [/quote] Seriously, why? Jason out *blip*
  9. coderx75

    Future of Gaming: Facts

    Then why did you include video of a physicist directly contradicting that belief? He states that things become erratic at small scales (nanotechnology) and that the calculation of 3 x 5 = 15 was a major step forward in quantum computing. He gives a timeline of Moore's Law breaking down in 15 to 20 years and quantum computers being usable in about 30, leaving a 10 to 15 year period of stagnation. We're a ways from quantum computing and nanotechnology is only taking us so far. It isn't, if fact "changing" the processor, only increasing efficiency to a point. Believe what you want but there will never be a 204.8 Ghz on a silicon-based chip, with or without nanotechnology. Look into light-based processing. I saw an article a few years ago about a team that used light, rather than electrons, to build a (at that time) table-sized processor and they were promising performance in the teraflops. You want pre-quantum speed, that's the best bet that I know of.
  10. coderx75

    Future of Gaming: Facts

    Michio Kaku said it best. It would be 50 to 100 years before AI can best the human mind (make us dance around in a zoo, as he puts it). So, you're not going to see the video game becoming the video game developer any time soon. He also mentions the collapse of Moore's Law within the next 20 years. You're not going to see 204.8 Ghz processors on the current CPU architecture because it's simply impossible, not to mention that CPU speeds haven't increased since about 2005. There may be some small increases yet to come but, otherwise, we're reduced to adding cores for more power. Kaku also talks about quantum computing and this is where the real promise for the future of computing is. At that point, you're no longer talking about gigahertz but well beyond. Although I love what guys like Kaku and de Grasse are doing, they really are the TV personalities of physics. So, they know their stuff but they dumb it way down for their audience. The "retarded cockroach" is still a bad analogy for computing but, in this context, he's using it to give the audience a perspective on today's computers compared to the quantum computers of the future. Today, we're operating on retarded cockroaches, tomorrow, human brains. Bad analogy, good comparison. However, where you're getting the brain analogy from now makes some sense. I've been following the development of Infinity since it started years ago (journal is right here on GDNet if you haven't been). Procedural content is one of my main interests and I've been working with agent-based generation in order to achieve varied and interesting gameplay. After working with this for a few years, the limitations have become very, very obvious. It's not so much that we can't create "interesting" content, it's that the human brain is so goddamn hard to fool and "interesting" rarely means "fun". So, fun activities are few and far between and there's oddball things happening all the time. I'm very enthusiastic about this direction of game development (as you seem to be) but I'm also willing to admit that I may be on a fool's errand. Quantum computing would be a great help (generate TONS of content and have some method of stripping away the silly/boring stuff) but I'll be nearing 70 years old by the time that happens. It's good that you're excited about this stuff and you should certainly take part in it (we need all the help we can get). But, it's like Kaku said in your second video: "we're the ones that have to build this stuff". It's all so much easier said than done.
  11. coderx75

    Future of Gaming

    Honestly, the GDNet guys threw you to the wolves by featuring your journal. =b All I'm saying is, for future reference, if you want to post and have any impact, know your audience. You can get a lot out of this site, mainly because a lot intelligent, skilled people here that deal with technology on a day-to-day basis and expect you to think about what you say and do. This is not a bad thing. It's one thing to say "In future, we can see infinite details in our games" or "every game will be infinite" and another to show available techniques, current progress made towards these goals and, most importantly, references. This triggers discussion and, in the process, you've been forced to think deeply about the topic. Let me try giving a little more perspective here. Take this as an example: [quote name='LoreHunter' timestamp='1326299633']In this situation, you can look at the brain as a computer. Memory of how a certain object looks like - 3D model. You can look at decision making as combination of code lines, or AI; etc. [/quote] Okay, I've been programming since 1982. These two examples are supposed to eradicate 30 years of knowledge and experience in order to install a new framework for which I am to think about computing.
  12. coderx75

    Future of Gaming

    [quote name='LoreHunter' timestamp='1326271707'] In this situation, you can look at the brain as a computer. Memory of how a certain object looks like - 3D model. You can look at decision making as combination of code lines, or AI; etc. [/quote] You have to understand your audience. Many of us understand this stuff at a pretty deep level. I can't look at the brain as a computer. Even the terms "memory" and "decision" mean completely different things when referring to the human brain and computer software/hardware, in both functionality and in their end results. I don't mean to nitpick but when you say something like "[color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif][left]machines as powerful as [sic] human brain", I have to ask what you're talking about. We're just not speaking the same language. You might as well have told me that the weather is quite automobile today.[/left][/font][/color]
  13. coderx75

    Future of Gaming

    Sure, technology is exciting but I'd reel it in a little. We are entering a point of diminishing returns. Not that there aren't some fantastic things still to come but... what more do we really need? About 15 years ago I was looking forward to the day when computers could produce and process music/sound real-time and how I'd be able to do everything I want to on one machine and with little to no extra hardware. That day's come and gone. I've produced about 3 CDs worth of music, I'm writing a video game, I manage all business affairs and communications on my computer and my entire work day is spent right here at this same machine. I like that we are able to do more important tasks from smart phones but I really don't see hardware changing my life that much more than it already has. I don't think it needs to. It's software that I see bringing the next great advancements. "Infinite games" are more of a software/content problem than a hardware problem. Procedural generation and streaming content allow for it now, however, content creation is expensive and procedural content generation tends to be unpredictable and, in most cases, boring. Honestly, I'd rather have a well-design, replayable game than an infinite one. Voxels fail to excite me. It's like comparing bitmap fonts to Truetype fonts. Oh, but you can increase the scale of the bitmap. Well, anyone that has done any print work knows that pixels are weak. Voxels are no different. Personally, I'd rather be working with vectors. Using LOD systems with content generation, there's no limit to detail, unlike voxels that are limited to the resolution you set. Also, the human brain really isn't a good comparison for computer power. It's not even remotely relevant, unless we can successfully produce a quantum computer. So, I know computers are going to be pretty damn powerful by 2020 and that the prices will be similar to today's hardware prices. Where the brain comparison fits in to this, I have no idea. I think there's still a fantastic future in computing and our lives will be changed in unexpected ways. I just don't see those changes having anything to do with infinite voxel-based video games *shudders*. As for hardware, today's technology is mind-blowing as it is and people use it to check Facebook. That driving the market, I'm more worried than excited. =b Hehe
  14. coderx75

    First BETA Test Session Results!

    He lives! I'm excited for you! You've certainly earned it. =) I was just on the Paradox website the other day to find out if a release date had been set (first quarter). Looking forward to it!
  15. coderx75

    Das LEGO side-project.

    Wow! LEGO has come a long way since I was a kid. I have a 1yo son and have been eyeballing some of the new sets. I'm actually feeling inspired to pick up a set after reading this. I had a pretty large collection as a kid and enjoyed creating some pretty complex monstrosities. There was no elegant solution to building a transmission with PRND. I'm curious as to what these new sets are capable of.
  16. coderx75

    There are many kinds of ugly

    Great entry! I will say that not all code is the same and shouldn't be treated as such. If you're hacking away at the architecture/framework code, you've got serious problems. Hacking away at a module that can later be replaced by another module is completely different and leaves plenty of opportunity to cut corners if necessary. Some code should be near perfect and this investment should be made from the start. Expecting all code to be pretty will only lead to wasted time. @Facehat: I was very much guilty of this after reading Gang of Four. Everything had to be meticulously engineered. I think this was the one point in my life where I accomplished absolutely nothing. Reading a book on design patterns may certainly be a good first step, but it's useless without a great deal of practice.
  17. coderx75

    Doin' the .com hump!

    Behold! The life-death-cycle pattern that nearly all startup companies have been following for nearly 20 years: [size="2"]A) [color="#696969"]Design application with the user's needs in mind but also with a long feature list that is "successfulwebsite.com-like".[/color] [size="2"] [size="2"]B) [color="#696969"]Throw a bunch of programmers at it.[/color] [size="2"] [size="2"]C) [color="#696969"]Launch.[/color] [size="2"] [size="2"]D) [color="#696969"]As always is the case, you can never really hit the target right out of the gate when it comes to the user's needs. First round of changes.[/color] [size="2"] [size="2"]E) [color="#696969"]Code is inflexible and typically sloppy so changes require a lot of band-aids.[/color] [size="2"] [size="2"]F) [color="#696969"]Adding more features and, as a result, adding more problems.[/color] [size="2"] [size="2"]G) [color="#696969"]Development (or adding problems) vs. fixing problems evens out. Team's getting frustrated.[/color] [size="2"] [size="2"]H) [color="#696969"]Your most important asset, knowledge, begins walking out the door. Begin hiring new people.[/color] [size="2"] [size="2"]I) [color="#696969"]Downward spiral of which there is no escape. Some projects may be well-funded. So, the possibility of tearing it down and doing it right exists in this case. However, they will almost always choose to throw money at the old codebase, as that is (of course) the cheaper solution. Spiral downwards in slow motion.[/color] Nothing is more powerful than an idea whose time has come. Victor's right. I've spent the past several years learning whatever I could about producing successful technology. Software architecture, team infrastructure, communications, methodologies, any knowledge that can help me be a better programmer and be able to handle creation of a lasting product. However, after putting in this enormous time investment, I'm only coming away frustrated because the idea (investing in technology) has not caught on. I'm holding the holy grail and ready to lead my employers to a better tomorrow. My employers, on the other hand, are doing the .com hump. Why has this pattern not been identified and anyone following this pattern not given 40 lashes and stoned to death? Why are non-technical people still brazenly leading their companies down this same path? Hubrous, of course. Still, it's the same pattern over and over. How is it not obvious? Recently, a project that I'm working on was about to be steered off a cliff and I stepped up with my experience to save the day. Rather than heed my advice, I was told that they deal in results, not theory. Since then, I've laid out a strict overtime payment structure. The Solution So, enough ranting about the stupidity that I'm sure many of us have witnessed first hand. I'll propose a solution. Given the biz-people's love for anything "successfulwebsite.com-like", we'll call it "The Google Model" (it doesn't matter if it's technically accurate, these are business people we're talking about!). A) [color="#696969"]Set up infrastructure for development. Put incentives in place so developers have a reason to stay more then a year.[/color] B) [color="#696969"]Stick to your core competency and invest in it heavily. No added features!!! In other words, keep it small, make it flexible and manageable. Also, don't be afraid to put some usage metrics in place.[/color] C)[color="#696969"] Launch.[/color] D) [color="#696969"]Gauge how users are interacting with the software. Successes? Failures?[/color] E) [color="#696969"]First round of changes. No problem. Preparations for this were made ahead of time.[/color] F)[color="#696969"] Add features based on common usage. Keep them simple.[/color] G)[color="#696969"] Build on existing features, add new ones when necessary. Adapt to your users.[/color] H) [color="#696969"]Development team begins building up steam having worked on the same project and with eachother for some time. I can not stress the importence of employee retention enough![/color] I) [color="#696969"]Review code constantly, making improvements where necessary and jump back to step (D). If expanding, jump to step (B). Rinse and repeat.[/color] Success comes from a strong core concept and not from tons of bells and whistles. More importantly, success is adaptability. Much can be added here (and feel free to) but my point is that the constant repetition of the same mistakes with the expectation of different results is, by definition, insane. I believe the time has come that these mistakes be recognized as such across all applicable fields of interest.
  18. coderx75

    Doin' the .com hump!

    Netscape did tear it down but they didn't do it right. That was the moment that the company I worked for and many others threw in the towel and stopped supporting Netscape altogether. There is a point where you're better off working with old code and that depends greatly on your situation. This is really secondary to my point. I'm more concerned with the hordes of companies that want to get into technology without feeling they need to invest in technology from the get-go. Companies with financial backing that continue to avoid the necessary investment in technology have usually been far surpassed by competitors at this juncture, thereby strengthening my point on the need for initial investment. However, this was meant more as a side note and has nothing to do with my original point or the solution I proposed. As for programmers typically choosing to implement their own system, that's very true but exactly why I stress employee retention. If a large portion of your technical knowledge walks out the door (and, in many cases, into your competitor's), you've pretty much failed.
  19. coderx75

    Become a Good Programmer in Six Really Hard Steps

    Great article! I have to second Nick's first point of communication though I'd like to build on this a little. As programmers, communication doesn't always come naturally. However, there are numerous tools available to facilitate communication without requiring the programmer to do anything more than they [i]should[/i] be doing. What should a programmer be doing? 1) Commenting code! 2) Using cource control and actually typing messages with each commit. 3) Writing code that tests their code We can probably go a lot further here but I'd like to keep it as brief as possible. [b]1) Commenting code![/b] We need to communicate how our code works so that other programmers may find it easier to work with. Commenting does this but doesn't serve as a reference. Using a standard format for commenting allows documentation to be generated automatically with the build. Use DOxygen, JavaDoc, etc. [b]2) Using cource control and actually typing messages with each commit.[/b] We need to communicate that we [i]are[/i] in fact working. Our higher-ups are rarely all technical people and, even for technical supervisors, we don't want them to have to look over our shoulder or, worse, "facilitate" meetings where we run down our list of work completed. Our commit messages may be scripted to send e-mails or, better yet, generate a log. Even better yet, there are online services that do just that, even providing ticketing systems to allow for a two-way conversation between employer/client and programmer. I use repositoryhosting.com (SVN) which provides Trac for ticketing and hooks-in to Basecamp (this further generates an RSS feed of all goings-on including commit messages from RH). [b]3) Writing code that tests their code[/b] We need to communicate that our code works but, more importantly, when our code is broken! If a change elsewhere in the software breaks our code, we should communicate that immediately. When writing modules, I typically write test applications for them. However, when I've completed the module, I move the test code from the application and place it into a static test() method. This function serves as a regression test that can be called during the build process. If something breaks, it usually sets a red flag right away. [b]...[/b] So, you're doing all of this anyway, aren't you? (If not, then [i]BAD[/i] programmer!) Why not convert the common things you do as a programmer into communications to your team and employer? I'd say this would be the #7 step to being a good programmer, but the title is "Become a Good Programmer in Six Really [b]Hard[/b] Steps". This isn't hard and therefore doesn't qualify.
  20. coderx75

    What you got to do to get a job, dammnit?

    Alcoholism, plummeting towards rock bottom, unemployed and a video game project. Ah, I miss those days. Damn, I actually feel somewhat jealous. Just don't be too hard on yourself. You'll come out of this with a completely different perspective on life. Eventually, you'll come across a few ego boosting experiences to remind you of what you're capable of. Things usually turn around with far less effort than you'd expect. As for finding jobs, I usually leave interviews feeling that my lack of a jaw ache and knee pads lost me the position... and I'm usually dead-on right. I just took on a project with a company in the middle of an acquisition but the guy I interviewed really impressed me. It's much better to work for good people in a bad situation than to work for bad people in a good situation. By the way, I'd warn against freelance sites. It may not be a bad long term solution but in the short term it'll likely just tear down your self worth. Probably not what you need right now. Just don't quit the game.
  21. coderx75

    A small bump in the road

    Great news! After two months of job hunting, I managed to find something with good pay and a flexible schedule. I set out to find a job that would not get in the way of the development of Tech Arena and my other personal projects. TA has been on the table now for over 10 years because my work schedule has always made it impossible to do anything with it. So, I'm extremely excited to have this opportunity. The past two years have been spent working on TA but making very little money. Finally, I can breath easy, have money left over to put towards the game and see what has been a life-long dream to completion. Where da game at? I left off some time ago promising screenshots and expecting to have a playable alpha build by now. I'm more than two months behind and I have an AJAX web site project I'll need to complete before getting back on the game. However, I'll be using this to build the TA web site and integrating it with the game. So, it's important to the project and will have some screenshot-worthy captures while I'm working on it. I'll be writing up some entries about the AJAX-based system and how I'm planning to integrate it with the game, so stay tuned!
  22. coderx75

    Demo, Video Settings, Culling

    Looks cool! I was reading about your culling technique and noticed that you're using a square root on distances. You should be able to factor this out. Squaring two sides of an equation yields a valid equation, so, distance < distance is the same as distance^2 < distance^2. Instead of this: distance1 = sqr ((x2 - x1)^2 + (y2 - y1)^2) if distance1 < distance2 then... You could say: distance1 = (x2 - x1)^2 + (y2 - y1)^2 if distance1 < distance2^2 then... Just thought I'd point out this little optimization if you haven't caught it already. Hope this helps!
  23. coderx75

    Demo, Video Settings, Culling

    Looks cool! I was reading about your culling technique and noticed that you're using a square root on distances. You should be able to factor this out. Squaring two sides of an equation yields a valid equation, so, distance < distance is the same as distance^2 < distance^2. Instead of this: distance1 = sqr ((x2 - x1)^2 + (y2 - y1)^2) if distance1 < distance2 { ... } You could say: distance1 = (x2 - x1)^2 + (y2 - y1)^2 if distance1 < distance2^2 { ... } Just thought I'd point out this little optimization if you haven't caught it already. Hope this helps!
  24. coderx75

    Untitled

    The new terrain generator is still being integrated with the game's resource management system. I was planning on having it ready this week but it's only stable on small scale maps and the generated textures haven't been incorporated into it. This means no screen shots. =( However, it is coming together nicely and the new terrain certainly proved to be worth the extra effort. So, screen shots are postponed until early next week, but, since I'm taking a little break, let's talk saving massive amounts of development time. Complex Features on a Limited Schedule I've been planning the Tech series for over 10 years now and as much as I've thought about gameplay, I've also thought about making the project practical for a one-man show (at least in the beginning). Although Tech Arena's features have been boiled-down to a bare minumum, it's still a great deal to accomplish. Component development, trading/economy, managing resources, etc. have all been major problems looming over the project. However, I worked out an easy solution that has greatly simplified the development of the game's more complex features. After reading "Programming in Lua" by Roberto Ierusalimschy, I realized that the Lua VM, itself, had some powerful, yet elegantly simple, features: easy integration with DLL components, debug support, environments for seperate scripts, metatables which could be used to restrict and grant access to data, garbage collection, weak tables, easily serializing and deserializing persistant data. It's such a simple and powerful virtual machine, that I thought, like other "machines", it should have an operating system written for it... and boom went the dynamite! Why integrate Lua into an application when you can integrate your application into Lua? The Solution: TechOS Using the game's already existing GUI, input system, rendering system and other major components, I set out to write a kernel for the VM that would treat scripts as applications which could be integrated together to drive the game's interfaces and features. The actual game is, itself, a Lua application (although it's mainly for initialization, firing up threads and responding to input). Even vehicle components can be treated as seperate application instances. There are quite a few things to consider. - Applications must be encapsulated (your cockpit code can not access my targeting system code) - Must allow some form of multitasking but also allow for strictly single instance apps or even one-off scripts - Applications must easily integrate with eachother - Some applications are more restricted (vehicle components can not access OS functions) - Must be some control over the order in wich things execute - Apps must easily be able to save state - Must be extensible (DLLs... Lua already does most of the leg work here) The OS maintains tables of all currently running scripts. When an application is run, an environment table is created and that table gets an access metatable assigned to it. The access metatable contains read-only references to all functions, objects and tables for that access level. For instance, OS level apps are assigned the global table (_G), giving it full access. Persistant tables are also maintained by the OS. An application can call Sys.Persist() on a table which then returns the current state of that table (restores if previously called). This is somewhat similar to the Windows Registry except that only that application has access to its data. Multitasking, Instances, Integration and Priority These four issues are all handled very simply. First, event-driven multitasking is used rather than actual multithreading. This gives control over order of execution and avoids the nightmare of using multiple VM's across seperate threads. Applications (and vehicle components) typically have OnCreate(), OnUpdate() and OnDestroy() functions that are called from the OS. "Global" code and data executes when loaded and affects all instances of the app. The three event functions are passed an instance table to hold all instance data which is maintained by the OS. Without these functions, the application is treated as a one-off script and is terminated upon completion. Single instance apps implement OnCreateOnce() instead of OnCreate(). Rather than opening another instance, the OS will focus the currently running instance. When apps are opened from other apps, they may pass parameters which are received by the OnCreate function. This also allows apps to share tables for integration by passing those tables as parameters. Extensibility Some exciting possibilities come to mind now that this system is (mostly) in place. Rather than creating only vehicle components, an industrious user could possibly write applications for the OS and extend the games interface and functionality. Although DLL's currently are loaded as OS level functions only, I plan to allow other access levels to be extended. This leaves the development of the game wide open for community participation. I've even considered backing up DLL's that have name collisions with currently loaded libraries so you have an option, in-game, of which to use. Don't like the graphics engine? Write a new render.dll. It's a crazy idea and would require that all players in a network game run the same DLLs. Still, it would be easy to implement at this point and probably worth a try. In Conclusion... All of this took about a month to write and was definitely time well spent. The in-game IDE, which was one of the more daunting items on my task list, was implemented in under two weeks and ended up with many more features than I originally planned. I've been considering releasing TechOS seperate from the game for those interested though it probably won't be worth much until I document the core API. Well, that's enough insane rambling for one day. Back to being productive! ;-)
  25. coderx75

    Untitled

    Thanks! I highly recommend reading "Programming in Lua" if you haven't already. It's superbly written and contains great examples. I was blown away by some of the mechanisms it uses to solve non-trivial problems, such as closures and upvalues. Which brings me to your comment about the GUI... Only OS and app level scripts have direct access to the GUI and input system. However, user level scripts which are used to drive vehicle components have access to a "control" class which can be instantiated by a user script to define a component as a control point in the game. Players can have multiple control points. For instance, the cockpit obviously would be a control point but there may also be a motorized turret on the vehicle that the player may want to switch over to... or may be manned by another player in co-op/team games. The real power of the control object is in its use of Lua's closures. The control object wraps GUI and input functions in closures that grant controlled access of those systems to the component. Using or switching to that control point in the game gives access to that components specific GUI and control scheme. What's even better is that a player can develop their own cockpit component or any other control point and create their own GUI and control schemes. To make things easier, the control object has access to the GUI:LoadGUI() function which loads the layout from files created in the editor app. That is the kind of thing that gets me excited about this approach. My implementation is pretty much just thrown together but it's something I'd like to see developers expand on. I'd like to open the source eventually if it doesn't make the game too susceptible to hacks.
  • 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!