Jump to content

  • Log In with Google      Sign In   
  • Create Account


shadowomf

Member Since 14 Dec 2006
Offline Last Active Jul 13 2013 03:41 AM

#5077304 Is Inspiron 15R good for programming?

Posted by shadowomf on 13 July 2013 - 03:41 AM


If you're not using OpenGL its probably better to get a laptop with a fast and reasonably big SSD, some laptops today even have both a SSD and a traditional HDD. (not having a SSD is just pure painful)

 

Can only second that, we do have a HDD-only laptop at work. The specs look fine on the paper, but the small HDD is crippling the whole thing.
As soon as I start a virtual machine I can't do anything else, even opening a browser takes minutes (no exaggeration).
 




#5059818 You spawn in a forest, in your backpack you have a...

Posted by shadowomf on 06 May 2013 - 02:25 PM

Actually, I think I would have each one start with radomized gear. That way each time you play it's a unique experience right from the beginning.

Sure they will also be players that will restart until they get the item they want, but I believe if you limit the possible starting gear and if each item on it's own is just a small step to survival then it will work.

 

 

Offtopic:

 

Also I would consider having only very few actual weapons and mostly just stuff you can find in a normal household, maybe shops, hardware stores.

For example if you take a look at the walking dead, all characters in the series are armed to the teeth. If you take a look at your own environment, would you really have easy access to such an arsenal in case a zombie outbreak happens? If you live in a country with reasonable gun controls, it's very unlikely that you can come up with a way to get your hands one some. E.g. in Germany the only places I would expect weapons are:

a) the police stations

b) military stations

c) shooting ranges

d) ambassies

e) maybe a few selected security services

f) some hunters home or maybe from one of the selected few that did actually do the paperwork to get a permit

Though even if you know that there might be guns, they are all locked up, the only way to get to them is crack the safe or get them from someone who has access to the gun. (There is always the black market, but let's assume the normal citizen doesn't shop there regularly.)

In any case, I think it's not only more reasonable, but it can also be used to make the game much harder.

Yes, for the few that do find a gun, it would be a huge advantage, people could rob you at gun point, hold you hostage and whatever they might come up with and they are more inclined to try, since the probability that the other person has a gun and shoots first are tiny. If you do combine this with a very limited ammunition supply guns could make players kings, but only as long as they can convince people that they will actually use them.




#5043791 When and why to purchase licensed software before marketing.

Posted by shadowomf on 16 March 2013 - 03:57 PM

In theory you would have to buy maya (the full version) anyway if you have already used it. And even then you would be in a legal gray zone.

 

How could you be in the software/games business and not know it would be illegal to use unlicensed or wrongly licensed software? Did you really not know or are you just looking for someone that give you another justification to use unlicensed software?

 

Even if nobody is asking you for it if you are a business you should always pay the (non-free) software you are using. Why should anybody be more willing to pay for your software than you are willing to pay for other products?

 

If you still decide to use unlicensed software in your company, remember it just needs one angry employee to vent his anger and you might face a lawsuit.




#5043785 Do You Think That Flattr Could Be Profitable For Pay-What-You-Want?

Posted by shadowomf on 16 March 2013 - 03:43 PM

I believe it would be better to offer multiple payment options.

 

Often one single payment option is not available in all countries or the user just did not participate or some other stuff.

For example I don't know a single person that uses Flattr and getting anyone to create a new account just to make voluntary payments does sound unlikely.

 

Don't limit yourself to one option.




#5024044 Version control for begginers

Posted by shadowomf on 21 January 2013 - 03:35 PM

The nice thing about Git too is that you can keep a local repository if you don't want/can't get an online one

No need for a server/internet connection; you can commit, do diffs, or view the log all on your local system

As mentioned before, you can use Subversion on your computer without having to install a server. Especially with TortoiseSVN it is a matter of less than 10 clicks.

 

With centralized version control systems (a la SVN), you've got one place you push and pull your updates to and from, which means I can't push/pull to/from different partitions or other computers like I can with git.

Why not setup your own server and do all your source control on it? I found it quite easy to do.

I already had a server in a data center (for email, ftp, http, ... so adding version control was only logical) and it is not very expensive (something like 34€/45$ /month), besides you do get a much better connection than you can get with your home broadband.

 

wouldnt use SVN anymore. Mercurial(hg) and git are the modern things.

Could you elaborate what features you do require that subversion doesn't support?

Scala is more modern than C, still I wouldn't force my worst enemy to only code in Scala. Well, maybe...

 

One more question, do you use some explorer integration? I haven't found one that is comparable with TortoiseSVN which was always a bit of a show stopper. Maybe you can recommend one (for Windows).

 

Can any of these control software be used by someone who knows little about IT and in particular game development? The reason I ask is that I know someone who is thinking about starting a company to make software. Should he just leave the version control to someone else such as the lead programmer or could he use any of this software mentioned here? The company head uses windows and would need a very user friendly sv system, so what should I recommend?

I'm using Subversion (TortoiseSVN) myself and recommended it to my sister to keep a history of her LaTeX documents. She's a nurse and no computer nerd. She does get along well for her own stuff, since she couldn't convice any of her colleagues to use it there are hardly any conflicts to resolve.

 

However I believe if someone is able to handle his own documents, organizing them in directories, it should be no problem to learn to use SVN even in a more complicated environment. Note: If he/she is having trouble creating/moving/editing/deleting files and folders or if he/she is unable or unwilling to read a manual it's probabably not a good Idea to use make him/her use any version control system.

 

If you mean with "Should he just leave the version control to someone else such as the lead programmer" that the lead programmer should set it up and maintain it, I would say it depends. Many programmers are able to do it, however programmers aren't administrators. There is no guarantee that the programmer is able to do it. Besides maybe the programmer is not willing to do it (he became a programmer not a server admin for a reason). And then there is the cost factor, maybe a sysadmin is cheaper than a developer, then the developer shouldn't be doing it. And ne more important thing, don't give this responsibility to your lead, he has already much to do, give it to a specialized tool guy/the sysadmin/someone else, make sure he has enough time so he can still do his usual tasks.

 

Actually using the version control system is a task for everyone that is working with the version controlled files. If you put you source code in, all developers need to use it. If you put your assets in, all artist and designers need to use it. In addition some other people might need it, project managers, qa, ...   All of those people have to be tought using the system. Don't assume that every developer you hire has already worked with your system. Make sure they really understand what does what, else they will create a mess and you will waste time cleaning up after them.




#5020798 portable version of game

Posted by shadowomf on 12 January 2013 - 01:00 PM

If you want your application to be just copy-able (being able to copy the whole game folder to another machine and run it) you should make sure that all required resources and libraries are located in this directory.

On Windows settings should be loaded from %appdata% and if they can't be found they should be created with some default values that make sense.

 

However if you want your game to be a single file it gets a bit more complicated.

You will have to use statically linked libraries (.lib files, not static linking of .dll's).

The resources will have to be added as actual ressource files by the linker or you just append them to your executable by using the copy command. I would prefer the second one, as mentioned before if you look for sfx archives you will find how they build their stub. The advantage is that code and resource compilation is not dependent on another. And if you're clever you will be able to remove appended ressources from you executable and replace them with new ones, no recompile neccessary.




#5020793 for loop that will repeat the number of times the user wants.

Posted by shadowomf on 12 January 2013 - 12:46 PM

where the while loops will take a couple

Remember C/C++ and as far as I know Java too, don't use line endings a seperators.

You can happily write your whole application in one line, as long as the compiler supports it and you don't miss any semicolons.




#5016378 What kind of optimization makes C++ faster than C#?

Posted by shadowomf on 01 January 2013 - 09:17 AM

Personally, I'd include all of the above inside the category of what "the engine" is made up of (not just the engine's runtime library itself).

That's where our opinions are different (which is not a bad thing).

I wouldn't count the following as part of the engine. Sure they are connected, but not part of the runtime.

  • Shaders - many provide some predefined shaders. But I believe shaders should be part of the game. Else all games use the same lighting style and materials it gets boring. Handwritten shaders often look more unique and can do so much more than shader that have been generated can. Besides aren't shaders assets?
  • Scripting - yes, provide the possibility for scripting, but I wouldn't put scripts in the engine.
  • The whole pipeline - Texture-, normal map-, lightmap-, mipmap-baking is all part of the tools. It's not shipped with the game and not part of the engine. It's part of the eco-system that engine developers provide to make it easy to use the engine. Most of the time the tools even work without the engine as well as the other way around.
  • Build tools - you wouldn't count Visual Studio as part of a game engine would you? Or cmd.exe. Just because somebody decides to replace either it's not magically becoming a part of the game engine. Would you count make as part of a piece of software that is developed with the gcc toolchain?
  • Web tools - see whole pipeline/build tools and I wouldn't count any other way to provide a pretty Gui for a simple tool.
  • Exporters - for Photoshop, gimp, 3ds max, blender, ... they are tools just as before, besides there are other ways (use standard formats).
  • The game - choose whatever language you wish to write the game. Provide multiple language bindings to use the engine. The game just is not part of the engine. Anyway if you go down that road, microsoft should start to claim that any piece of software written for windows is also a part of windows (well in some philosophical way it could be). Of course it's always possible to write a game without engine, which makes the engine somewhat a part of the game...
  • Libraries - If you use a third party library or API, for example OpenGL, the Windows API or any other library the library is not part of the engine. It's a dependency. I wouldn't count the languages used inside the library as part of the engine. Besides you can't always be certain what language it was written in.
  • Data definition languages or data in general - One of the points where we need to clarify which languages we mean. If we start counting not human readable data languages, we could include every binary file format that an engine supports. Besides the whole point only applies if you're using a data driven architecture, else it's just data and not part of the engine. Most data is part of the game anyway... so I would count this as assets.



#5016373 What makes an RTS great?

Posted by shadowomf on 01 January 2013 - 08:46 AM

Dark Reign

Nice game, at that time I never got to play it on my own computer. Only when I was visiting friends.

Didn't it also have really long firing distances for artillery and missiles? Over multiple screen widths?

 

That reminds me off Sudden Strike, there was no unit building or base management but it was still alot fun.




#5016017 What kind of optimization makes C++ faster than C#?

Posted by shadowomf on 31 December 2012 - 04:20 AM

Good engines rely on many different languages.

Sorry, but this is just plain wrong. Many different languages don't equal quality.

 

While there are many engines that are written in more than one language it's not necessary a good thing.

(I'm not counting scripting support into this, because scripting is often part of the game and the engine is only providing the possibility to script the game or game objects.)

 

Also you have to differentiate a bit more. E.g. having a library or engine that has multiple language bindings is a complete different thing than having an engine that's written in a dozen of different languages. Having many different bindings is something good, especially if the engine should be licensed to other developers. Having an engine written in many languages sounds like a horror story.

Again we are talking about the engine itself. I'm not saying that it's a bad thing to write your tools in something for appropriate (e.g. use C# for the tools and C++ for the engine itself). However if every tool is written in another language it's not a sign of high quality.

 

Thinking back over the decades of good engines I've used, the simplest engine remember was for the Nintendo DS, and it 'only' used six languages that I'm aware of. The major EA engine I work with today has no less than 15 languages, probably more if I dig deeper. They range through hardware-specific assembly and C and C++ and C# and Lua and perl and python and shader scripts and even a handful of custom languages for particle systems and audio control.

They don't use it because someone thought "hey great let us use as many languages as possible in our engine". Most of the time it grew historically and it's hard to impossible to get rid of it. Sometimes you have to add another language, for example to support a new platform or make use of a new library, however I'm pretty sure no experienced developer will make such a decision lightly.

 

And the many different tools and scripts all in different scripting languages is a sign of lack of direction. Obviously nobody decided to use only one scripting languages.

Or even worse imagine this scenario:

  1. In the beginning somebody choose perl as scripting languages, because he knew it already or he heard something about it.
  2. A few years later you decide to switch to python, because you can find more developers that also know python and in generally it seems like a nicer language or whatever. However you don't have the time to make a complete transition to python, because not all your developers are as fluent as they need to be for that. Besides your developers don't have the time to rewrite all the tools. So some modules are rewritten but most of them stay perl.
  3. Lua comes along and somebody made the decision to use it as main scripting language in the game. It's nicer for the artists and level designer and the developers do like it too. Great since you are already using Lua in-game, why not also for the tools? So without much hesitation your team decides to switch to Lua for tool development. Now most of your developers need some time to get familiar with Lua, they also have their usual tasks to do so again yo can't completly rewrite everything in the new language.
  4. You've got yourself a ten year old code base with 3 different languages (just for the tools). Whenever there is something to change on the older modules you need to find the perl or python guy. Since some of the tools are so old and complex, everybody is just saying "never change a running system" and nobody is touching the old code. If your last perl guy leaves you won't replace the perl tools, no developers will start writing tools in Lua or whatever you currently use just to integrate the old tools. "No, you need to run the converter script to make it work with tool X, when you're finished you need to run it again to make it work with our other stuff!"
  5. Of course everybody that reads this knows, a rewrite would be the best thing to do or better forget all about it and start from scratch. However if your studio can't afford it you need to make it somehow work. It gets worse every year and each project is getting more difficult, takes longer and gets more expensive. Maybe some day your studio does a complete rewrite, maybe they decide to license an engine from another developer. Or maybe your studio is slowly fading away into oblivion, like many before you.

 

Multi-language projects have many downsides, for example:

  • They are a maintenance hell. At my place of work (not game related) we have projects with Tcl, C++, Visual Basic, C# in one project (some modules stand on they own). It's just bad, I can't see any good about it.
  • Developers need to be fluent in many languages. This is especialy difficult if you have some rarely used, old or esoteric languages. Especially since some parts of the engine aren't tuched for a while and the developers aren't as familiar with it as with a piece of code they work regulary with.
  • New developers will need longer to get a grasp of the engine code.
  • It's harder to hire new developers, especially if you want them to have expierience with all of the used languages.
  • If somebody is developing a module in a different language than all the other modules you should take a close look. Is it neccessary or is he trying to make himself unfireable. If he is just trying to use arcane knowledge to make it hard for everybode else to maintain that module, he/she should be let go as soon as possible.
  • Each additional language means the development environment gets more complex. Not something you wish to achive.



#5015801 What makes an RTS great?

Posted by shadowomf on 30 December 2012 - 11:40 AM

what I miss in RTS is to have really strategy, at best you have some tactics, but I'm not a game design expert to pull out ideas for how to let the player make great strategy.

Hard to say, but I would have thought that there is a bit strategy involved. Of course there aren't many and often they don't influence the game as much as just being faster than everybody else.

 

But if you think about it, sometimes in Starcraft 2 and many other games one player tries to kill some of the enemy workers early in the game.

Now it's clear the tactic employed is hit and run. But almost all the time the player is having a strategy in mind. In this case, weaken enemy economy early on to weaken his army in the mid-game.

Sure this is a very simplistic nevertheless efficent strategy. The problem is that most of the time games don't allow for anything more elaborate.

 

I'm not even sure myself if it's possible to ask the player for a deeper strategy in this genre. When you take a look at round based strategy it seems much more deeper. However imagine doing the same in real time.




#5015732 How come many of you prefer to make games from scratch rather than use an eng...

Posted by shadowomf on 30 December 2012 - 06:21 AM

I believe,  there are as many valid reasons to not use an engine as there are to use one.

  • Learning to use an engine takes time. Sometimes it's faster to do it yourself, especially for small projects and if you don't plan on doing another similar project.
  • NIH syndrome and it's not always bad.
  • Prevent vendor lock-in. What if the engine developer decides to stop supporting the engine? What if license terms do change? What can you do when there is a bug in the engine, will it get fixed or do you have to work around it?
  • Cost, sometimes doing it from scratch is cheaper than licensing an engine. Sure there are free engines available but sometimes they don't offer what you need or have strange licenses (especially the "free" versions of commercial engines) or even unclear licensing conditions.
  • If you do it yourself you can learn how it's done. If you're using an engine, you learn how to use an engine. (Often the first one is more fun, but also less productive.)

One more thing, maybe it get's a bit offtopic (just couldn't stop). I believe doing it yourself gives your product much more value. Not necessarily value in the sense that you will get rich. But you yourself will value it much more. Even if this only means that you will be more confident it might pay of. Maybe it makes you decide to sell your games for a few dollar/euro/... more. And to tell truth I would prefer to sell a few hundred games for 20 or 30 bucks than be one in a million developers that sell their crappy app for 99cent. Even if the 99cent developer get's more money out of his game. I can't imagine have worked on a game for month and the have people pay less than a few dollar for it. It must feel horrible to produce something that is of so little value to the customer.

 

Note: I've never published a game and don't work anymore in the field, it's just my personal opinion. And I feel this even more stronger ever since I work on commercial software. You basically have a good (not perfect) product that is of use too the customer and he's paying a good price for it. If it wasn't worth it price there wouldn't be any customers...

The great thing is that even though they aren't very many customers the company is having a quite string relationship with them. Of course they exspect that, since they are paying each year to receive maintenance.

But can you imagine a 99cent app developer having a strong connection to his clients. (With strong I don't mean a facebook page and a forum or similar things.)

Sure even if you sell your game for 60 dollar you won't have the same kind of connection to your customers as a software house that is selling licenses for a couple of thousand. But you can offer much more than someone that is putting it out for 99 cent.

 

 

This is all from a developer point of view. If you're an artist it's probably not as important because your work will show on the screen and can be valued.

But to connect everything, using an engine can sometimes feel a bit like seeing an artist using poser (that strange 3d software with predone characters or something, don't exaclty know). Even if he/she might get something beautiful on the screen (most of the time poser users don't) as soon as you hear it's done in poser you think "oh well... can't have been much work".

Same thing with the unreal engine, everybody knows what the engine can do. And everytime I see the logo when a game starts, I ask myself "What did the developers do?".

It feels a bit like Java, when I hear someone say he's written application X in Java. Well did he actually develop something? Or is he only the one that is collecting pieces from the standard library, like those paint by numbers picture. (Yes, I do hate Java.)




#5015508 What makes an RTS great?

Posted by shadowomf on 29 December 2012 - 01:13 PM

For a non-competitive rts, focusing on the macro strategy level and not the math/direct counters is your best bet.

ie-Just because Race A has a unit that does a lot of damage, doesn't mean Race B needs one(copy) or even a heavy armor unit that can take the hits(counter).

 

I like that, no rock, paper, scissor as mentioned before. Look at MMORPG's most of them also have that triangle and it get's boring.

 

On the other side, many beat'm up games also have vastly different characters and not all are balanced. The developers try to make it still fun by putting a bigger selection in the game.

If there is one character that is a bit stronger in a selection of 3 available the developer has to do something about it (or everybody will use the one character).

However if you have one or two unbalaced characters in 20 characters, the chances that the players will find the proper tactic against thoose two are much higher. The developers don't have to explicitly do something about them, they can pretty much rely on the creativity of the players. Of course the players do need to have the means (in this case many different characters) to do this.




#5015098 What makes an RTS great?

Posted by shadowomf on 28 December 2012 - 10:32 AM

Actually the Idea of a connected universe sounds quite interesting.

I never liked that MMORPG's have battlegrounds and factions that are at war, but nobody ever conquers anything. Everything is static.
Maybe some kind of star chart or world map where you can see what race is currently dominating the game. Of course no race can ever really win the war or else you would have to restart it (well Blizzard is resetting their ladder every few month or did they stop doing that?).

Best regards.
-Christoph


#5015021 Game lobby as a separate application

Posted by shadowomf on 28 December 2012 - 02:29 AM

Updates and patches are also possible from within the game if the developers aren't too lazy.
Sure you can't overwrite the executable and you shouldn't overwrite the resource files while the game is running. But take a look at Diablo 2 it already had a patch downloader build into the actually game. When finished the game starts a new process (the Blizzard updater) and quits. The Updater does it's thing and then starts the updated game.

Back to he topic, when using a separate lobby application.
  • It can be easier to build complex gui's, tables and so on. You can use a Gui library that you don't want or can't use in the actual game. E.g. Qt but maybe you don't want your whole game based on Qt. Maybe you prefer to use IM gui in the game.
  • You can even replace the lobby with a webpage and somehow launch your game directly from the site. This enables you to use html, javascript, databases without having to write your own customize master server and you can take advantage of all the new web technologies (remember to check your targeted system requirements). And you only need an updater/patches for your actual in-game part of the game, the rest can be updated on the fly (test before putting it on your production system!).
  • You can make the lobby application look and feel like every other native application for that OS. Which make it look more like it was developed for that OS. Not some fancy widgets or the look of another operating system. On Windows it looks like Windows, on OS X like OS X and on Linux like Linux (is that even possible with all the different desktop managers?).
  • Bad side, if the whole thing is done wrong it feels like some loosely coupled applications that barely work together.
I really like the Gui of the old Unreal Tournament (the really old) where the developers put a whole desktop in the game. Nowadays they have switched too a more console friendly version which is not exactly great to use with mouse and keyboard.

Edit: Something more on the patcher... If you have a small skeleton application that is loading your game as a library, you can unload that library, overwrite it and the load it again. (Beware, I believe unloading is not possible on OS X!)




PARTNERS