Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 29 Jul 2004
Offline Last Active Jul 09 2016 06:52 AM

Posts I've Made

In Topic: Looking to kill IOTD as it currently exists.. Need testers

14 January 2013 - 03:57 AM

> EAT ROPE, MMO hockey, MMO in HTML with variables, MP3 beating compression, various Boolean comics (especially asking medical advice on the forums), GDNet: The Trading Card Game... I'm just listing all the memes and often referred to threads/events that I can remember...
Talk about a trip down memory lane!

I still have (and cherish) my trading card:

Anyways, Michael, I started clicking through the showdown and I don't particularly like the format. The best explanation I have to why I feel that way comes in the form of a question: "Do the screenshot necessarily need to compete with each other, or should a screenshot only compete with itself to the viewer?"

I think a "vote/no-vote" system would be more appropriate for the screenshots. Either the screenshot is such that it invokes a viewer to "vote" for it, thus giving it a point, or "no-vote" it and go to the next screenshot.

With that sort of system, the screenshots that are appealing for whatever reasons will bubble to the top with votes, while those that don't simply "don't have votes", which is not negative, just not positive.

For something that is supposed to be fun and entertaining, I think a model like that one would better suite the screenshots while not taking anything away from the screenshot itself.

In Topic: My First try in HTML5 game

08 November 2012 - 02:43 PM

I found Level 6 to be pretty tricky compared to all other levels around that set.

Level 12, 13, and 14, you don't extend the blocks at the top off-screen, so you can just aim straight up and shoot over easily, bypassing the challenges.

The pineapples and their vision mechanic don't make the game any more challenging; they just waste the time it takes to fire your one shot. That mechanic needs to be reworked.

Level 23, you can't zoom out far enough really. The text covers a top block and that's a little annoying.

I played through all 24 levels, but the game just went to the title screen after completion. So there's no end game credits or "you won" message. That makes it feel like an incomplete game.

Overall, it's a cute little game, but too repetitive, not enough mechanics to make it challenging. There's pretty much only one way to solve most of the puzzles and it's more based on consistent timing than anything. I think it needs more varied music as well. You always start out on the left side of the screen and your objects are on the right. Just an observation.

Nonetheless, congratulation on your first HTML5 game! It's a really good start, but there's a lot more work to be done on it. Good luck!

In Topic: Software patents

26 July 2012 - 11:18 PM

I have heard you and I am granting the open source community immunity from this patent.

Seems like this won't be an issue.

It still is an issue, and it will always continue to be one for any oss project threatened with patent violations.

If you accept him saying that, then you are operating under the assumption the project actually does violate the patent (or admitting it did violate the patent). Just because he thinks the project violates his patent, doesn't mean it actually does; that is for the legal system to decide.

Looking past that important point, will that statement on a blog be upheld in a court of law a legally binding agreement? I think not, but that's not up to me to decide. There needs to be two sides to the agreement. What does it mean to be a part of the open source community? Which one (there are public and private ones)? What about commercial usage? There's too many questions to simply take that at face value and think it's "ok" now.

Maybe he changes his mind, maybe he sells the patent to someone else who has a different opinion, or maybe he means it, and won't ever take action. Who knows, it doesn't matter. What does matter is that before you use the library, or any library for that matter, you have to be aware of patent issues and be able to handle them accordingly. In this specific case, it's been shown that you might run into patent issues, so you will have to plan for the worse and seek legal counsel if you really want to be sure.

FWIW: I think Doug Rogers got the short end of the stick here. Looking at the released initial e-mail, I think it was pretty civil, done in a respectful matter, and in a way that was not meant to have things blown out of proportion. But what about the title you might say? Well it's an appropriate title to ensure the e-mail gets read. If I saw an e-mail with that title in my inbox, I'd surely click on it. But as with anything on the internet, things tend to get blown out of proportion way too easily. It's not like he was threatening a lawsuit in the shown e-mail or had actually filed a lawsuit, he seemed to want to try and talk things out and now look where that got him.

It really sends a bad message because perhaps people might feel less inclined to try and open a dialog in the matter rather than just rushing straight into a lawsuit. Compare the e-mail Rich got vs the one Notch got. Which would you rather...? Anyways, I'm just commenting about the specific stuff at hand rather than patents in general. There's no need to beat a dead horse; the patent system needs to be drastically overhauled when it comes to software.

In Topic: Existing c# socket server library using SocketAsyncEventArgs?

22 July 2012 - 04:08 PM

Based on your other thread, I'd strongly urge you to slow down and actually work out you current problem rather than rushing to potentially solve the wrong one.

The alternate asynchronous pattern SocketAsyncEventArgs provides is a very advanced model that caters to very specific needs. When they (Microsoft) say the model is for "specialized high-performance socket applications", they mean a very specific thing, not a general thing that you are thinking about. The model is meant to help developers control almost all aspects of resource costs for servicing 1000s, 10s of thousands, to even 100s of thousands+ worth of concurrent connections or an extremely high network I/O throughput. If you do not properly implement all aspects of this model, your solution essentially degrades into the same model provided by the Being/EndXXX API, just more complicated and bug filled.

There's more to using the model than just the networking aspect. The rest of your code is vital in determining whether or not the networking can even scale to its max potential on the hardware you provide. The most basic and specific example is "global shared state". The more "global shared state" you have, the less efficient async models become due to locking. While there are certain ways around this, it is a very advanced topic.

What's the point about talking about all this? The point of using this model is that you control all aspects of it. You would be hard pressed to find a generic socket server library that utilized SocketAsyncEventArgs because of how specialized the solution is. Whatever you might find, you certainly wouldn't want to use without understanding the core concepts first because typically speaking, you will be finding unsupported code that will have tons of bugs in it that will negatively affect your application down the road. If you needed a library that did all of this for you, then use the Begin/EndXXX API!

The bigger issue at hand though is that if you are having issues with the Begin/EndXXX API, the XXXAsync API functions will not magically solve your problems, especially if you do not understand what the problems are in the first place. That is why you need to try to figure out the real problem first. If there's one thing I've learned over many years of working with networked applications is that there's nothing worse than solving the wrong problem using an even more complicated solution because you did not take the time to understand the inherent flaws in your code.

You should really post code in your other thread if you want to get more help as right now, all people can do is guess. Programming and guessing do not go together, especially if you hope to get a problem solved.

In Topic: What are the basics to making a Game Engine?

16 July 2012 - 06:36 AM

So tell me, if I am speaking to anyone who has ever made an engine of their own. How did YOU do it? How did YOU get started?
I would like to see some unique and helpful answers from you guys.

In the past, I've made a few simple games and I've made a few simple engines. Nothing commercial, just indie stuff. I hope this doesn't sound too cynical, but it's the truth. I started out on GameDev back in 04-06 with aspirations to become a game developer. Unfortunately, I got caught up in the whole "making engines rather than games" deal. Ultimately, it lead to the demise of my game development career and I moved on at the time. I'm not a person with regrets, but if I knew now what I did then, I'd have not wasted my time.

The matter of the fact is, a game engine isn't an end, it's the means. But, you have to ask yourself the means to do what?

If you want to make a game engine to understand how game engines work, there are far superior ways, such as studying and using existing successful game engines, whether they are commercial or not. I'm a strong believer in trial and error, but in terms of a time investment, getting experience and actual portfolio end product work on commonly used engines looks and feels a lot better than unpolished tech demos on an engine that you might think is great, but everyone else just shrugs at.

Don't believe me? Just take a look at some job offerings for "engine programmer/developer". I'm not going to link specific postings, because it might feel a bit like advertising, but hopefully you'll get the idea. Having your own experience is not bad, but the way you do things certainly won't always be the way the "industry" does things. If you want to compete in the "industry", you have to play their game. Even if you don't want to get into the industry, part of becoming a good programmer is finding the right tools for the job. The sooner you get over the hump of trying to do everything yourself, the sooner you can actually make your dreams come true and get stuff done.

If you want to make a game engine to make games, then you should really just make games. Here is the obligatory, Make games, not engines article. The entire read is good, but the third from last paragraph is what I want to draw the most attention to:

Most hobby developers who “finish” an “engine” that was designed and built in isolation (with the goal of having an engine, not a game, upon completion) can’t ever actually use it, and neither can anybody else. Since the project didn’t have any goals, any boundaries, or any tangible applications, it essentially attempted to solve aspect of the chosen problem space and consequently failed miserably. ....

Looking back now, as I know a lot more than I did in the past, this is exactly what happened to me, and most other people who went down this route. In a sense, this quote highlights the main problem most people have with "learning" anything. Trying to learn something as an "end" rather than as a "means" most typically leads down a hard and unsuccessful path compared to people who use it the other way around. Sure, there are exceptions, but that's why they are called exceptions.

How should you view game engines? As a manufacturing factory whose sole purpose is to speed up the production of games. You wouldn't build a factory without knowing what product you are producing, right? Unfortunately, most people do when it comes to game engines and games.

So my advice to you would be simple. Forget about the concept of "making a game engine", completely. As saejox mentioned, learn graphics rendering, physics, sound, input, scripting, multi-threaded programming, scripting, databases, tool development, etc... typical software development stuff applicable to game development. Once you learn those things, make games using them. When you have enough games made, you will see commonly recurring patterns of functionality and tools. Take all of that stuff and get it interconnected into a new project. You now have a game engine, without having made a game engine. From there, it's all about evolving the project as you continue to make more games from it.

If you have made games already, great! You are ahead of most people who want to start their own game engine. However, you still need to keep making games in order to understand the type of engine that you need to help speed up game development of similarly typed games. Making simple board games doesn't mean you are ready to make a generic game engine for a FPS, RTS, or anything like that. If you have interest in developing a broad range of games, then focusing on an engine is not a good idea, as the game development concepts can vary between game genres (e.g., action based mmorpg vs turn based rts).