Another thing that's odd wrt jumping is that it seems you actually jump higher when you just tap the button as opposed to holding it longer.

Didn't make it to the first Bossus so far, found constantly dropping off the tree too annoying, but that's probably due to my suckage.

Huh. I hadn't noticed that, but I'll check it out.

An entire physics engine just for moving platforms and bouncing arrows? Seems like the kind of overkill I'm privy to.

Yeah... One of the reasons I'm doing this is to try out my engine doing something real, and rigid body dynamics is all I've got right now. The engine is kind of high-end and not anywhere near done, so I haven't had time to tweak the platform movement - which, being based on floating-point numbers, is very ill suited for the precision you'd expect from a pixelated game to begin with. But hopefully I will have some time to do that before the deadline.

I couldnt run it...throws some errors about not being able to install the aplication

Interesting. I seem to get a similar problem on another machine, internet whispers of an SP2 problem. I'll look into it tomorrow and try to get a new build.

I do have a couple of crits about the jumping though.  Pogo jumping can be pretty damn annoying.  Is there a way you could make him jump only once for every press of the jump button?  Also, the player sprite seems to stick to the side of walls when I'm trying to jump up a ledge, and I can't make the jump unless I back up and clear the top completely.

Good point, I'll remove the pogo jumping. The wall-sticking is slightly trickier since everything that's moving in the game is controlled by a physics engine and I can't fiddle too much with the inner workings of it in order to get this one game working. I'll experiment some with friction and see what comes out of it.

Demo available. See first post.

Really liking the sprites and tilesets here! Is that Mode 7-style rotation I see in the second screenshot at the top, too?

Thanks! ... Though I'm a programmer and no artist, really, This will probably become painfully apparent in the lack of detail.

Yes, I have some rotational background emulation going on... Although I cheat a bit and don't preserve the shape of the pixels when rotating, this is why the arrows look straight even though they are very low-res and should be aliased.

Update!

First encounter is finished and I would post a demo, if I didn't fear that I might not have any more time to work on this. I'll submit the game now, at least.

I do hope to add some sort of shrine and level beside the fighting area, though. Also, I have plans for a couple of other encounters though since the first one took more than a full day's work to finish I'll be lucky if I have time for one of them.

But enough complaining. I don't really have any new, fancy screenshots so here is an
image of when I tried to find a physics bug a few days ago;

Awesome.

You left a "Prey" in the beginning of the last paragraph, though.

I don't know, that doesn't sound too enticing to me. Would you enter your PayPal/credit card credentials into a proprietary piece of software where you don't even know what it's going to do with them when you can simply do it via the relatively trusted browser interface?

Yes, that is of course an issue.

I do agree that one less hurdle could impact sales, though, so it might be worth trying to come up with solutions for this.

But what I have never seen is a game which lets you pay to register the demo directly from within the game, without opening a web browser. Obviously, most indie developers don't have the skills to do that, but I reckon it would make a massive difference to sales. Someone should make an open source API or something.

Hmm, I while I do think I have seen that I think you're definitely on to something. I see a couple of other different ways to do this, though...

- Make an open-source library that connects to a paypal (or similar) account and does a paypal transaction in-game. This would be fairly easy to do as the http/https protocols can be implemented without too much of a hassle, but it would alienate people that don't have paypal.

- If you're going to charge by credit card, you'll likely have to use some service for the security and transaction issues so it might be a good idea for them to provide a closed library that you can easily implement to handle transactions. In fact, if there isn't a company like this already starting one up might be profitable.

Anyone know if this is offered already?

I agree that he comes off as whining. Honestly, he says he wants to learn something from asking for peoples opinions, yet at the same time he says that "I get a lot of comments from people who defend piracy", and when he gets responses he just complain about the ones that bug him. Sure, he's nicer than your average foaming "piracy is theft and all the pirates should be shot!" - type person, but I don't get the feeling he's actually out to learn something - If he truly did, he'd try and get something out of the comments first and not complain when he didn't like what he found.

To me, the big problem about the piracy discussion is that the different parties talk about different things, or at least from vastly different perspectives. A pirate would argue about the single case; that in extremely few cases would he really buy the game if he couldn't get it for free, but he might like it and make amends later in his life. Or more likely, recommend it to others who in turn might pay for it - so it would ultimately be better for everyone if he was allowed to pirate. The publisher, on the other hand, talks about the culture surrounding games and their fear that games (and other media) are perceived at something that should be free.

Very few - possibly none - of the pirated copies are actually lost sales as most people pirating them wouldn't have bought it if in this particular case they couldn't have pirated it, so if you talk about the unique cases the pirate argument is solid. If however you take the publishers viewpoint the very idea that you can get commercial games for free is the problem and you can't reasonably argue about any single case.

My point is that the question that need to be answered isn't "why do people pirate games", as I think the reasons are pretty obvious (even though some might not like them). Rather, I think the way to find common ground is for pirates to honestly answer the question "If it was impossible for me to pirate any games at all, what would I do with the time I now spend playing new games?" and for others to consider "If we lost all of our non-paying players, how would this potentially huge loss of interest in games affect our business and the games industry at large?"

</rant>

OMG Screenshots!

I may have used up my free time this month doing this so chances are I'll finish the first encounter, clean it up a little and maybe add some shrine you start in and the call it a day. But hopefully that'll make at least someone happy

Isn't Shadow of the Bossus the name of a level from Karoshi 2.0?

Indeed it is =)

I couldn't think of a good name by using thesaurus so in order to get that extra indieness I just used a reference to a Karoshi 2.0 level. 

[Stroll]

Join the hero Stroll on his quest to bring down the huge bosse... Bossuse... Bossii! A whole new world awaits you in this platform action-adventure of epic proportions. Available for PC:s!




The following version of the game is complete, but may still contain some bugs.

I have made the game in my prototype engine so while it's not very demanding, it requires you to have an OpenGL 1.5 - enabled Graphics Device to run, and it doesn't handle failure to render very gracefully so if it doesn't work, the renderer is probably to blame. Anyway, ATI has done a lot of work on their GL drivers the last 8 months so if it fails on a Radeon card, try updating.

Version 1.0( http://ekermo.se/tmp/sotb/sotb_v1.zip )
alpha
demo 1.1
demo 1.0





Controls :
Arrowkeys: Move, aim, crouch
Z: Jump
X: Attack
A, S: Change weapon
Esc: Return to menu

I had some more ideas for this, but I don't think I'll have the time to add anything more. Please tell me of any suggestions you might have or bugs you find and I'll try to patch it.

Bootleg Demakes begins in August.  Start gearing up.

Oh, I am so in on this one.  :D

A common misconception about using established engines - in fact, a common misconception about using many kinds of 3rd party software - is that you actually can spend 0% of your time maintaining it. My point is that you'll never find a framework that is completely the way you like it so you have to sometimes expand and change the framework, and sometimes change the way you yourself work so it better fits how the framework functions. You save some time using a pre-made engine (most of the time, a lot), but you don't save all of the time so when assessing new frameworks you should take that into consideration instead of just assuming you'll be stuck with what the community shells out. So I would say go with Ogre or Irrlicht if you don't enjoy writing engines for the sake of it.

As for software 3D, I wouldn't say that is considered a requirement anymore. Seeing as the gaps between what you can do with low-end CPUs and average 3D accelerator cards is so incredibly large, any software fallback wouldn't resemble the hardware renderer to any meaningful degree if you were to use the engine to it's fullest. Again, I would suggest you do your own testing for hardware support or plug in your own software renderer (or check the community if someone else has written one already).

Finally, I don't know of anyone in commercial games using MinGW, and .net is actually very nice, but if Windows is not your main development platform I don't think it would be worth getting it. All depends on what your goals are with your projects, really.

Well... if you have something to show, why don't you just send it to them then? or a video of it? What kind of approach have you taken when contacting publishers? If your offer is "we have this really good game we want to sell you, but we can't present anything about it until we meet you face-to-face!" Then nobody is going to pick up on it. You need to start selling the product to get people interested. I get that you think you need to protect your idea, so I suggest you read this article.

If you can't get a publisher interested, you could try and present it to someone at a development studio; a studio with a track record has a much easier time getting publishers to back them so presenting it in their name could make doors open, and getting a developer interested in a game is usually easier than getting someone whose job it is to approve projects interested. And you should be able to find a studio close to where you live as well since games are being developed all over the place.

Finally, all of the big publishers have offices in Europe (and some Asia) as well as the US, so going there would likely be a waste of money. If you can't think of anything else, try and hit competitions and trade shows with your game to create some buzz around it, there are always buyers present at those.

I don't think it would be a good idea to give the player a choice between good and evil though, because nobody would ever choose evil.

Agreed... Well, at least for non-sadistic purposes.

I do like the original idea better though, having you playing as the "evil" part since I think the experience could be more valuable. Everyone likes to think that had they been around in Nazi Germany and had some position of influence, they would be Oscar Schindler. Truth is that very few actually did the right thing, a game like this could, if handled gracefully, help people grasp why this was. Assuming that an entire generation of Germans grew up evil and/or retarded doesn't help anyone understand anything.

If you can send and receive data in 60 fps, that's fine - the important part is what you're doing when you can't. What protocol and methods are you using?

If you play on a LAN it doesn't matter so much but over the internet you need to deal with slow lines and packet loss - if a few packets are lost or the line is clogged (leading to lost packets), the client won't get any new information and you need to be able to handle that gracefully and not just re-send the information - that will clog the line further and slow the game to a halt.

For an internet game, I would suggest doing a simulation with prediction on the clients to account for latency, and only send the information that's actually changed. You could also try to send only the key commands from each client and occasionally send a checksum to verify that the game state is correct. There are some more information in these papers...
http://www.gamedev.net/reference/articles/article1370.asp
http://www.gamasutra.com/features/19990903/lincroft_01.htm
http://www.gamasutra.com/features/19970905/ng_01.htm
http://www.ddj.com/184410430
http://www.gamasutra.com/features/19970919/aronson_01.htm
http://www.gamasutra.com/features/20000511/bernier_pfv.htm
http://www.gamedev.net/reference/articles/article712.asp
http://www.gamasutra.com/features/19970801/ng.htm
http://www.gamedev.net/reference/articles/article1138.asp
http://unreal.epicgames.com/Network.htm

Also remember that packet headers can be brutal. On the XBox 360, for example, the protocol header is close to 1 kb, meaning if you send 60 packets a second the overhead alone amounts to around 512 kbps. So, less is more.

... Hope that helps.

Ah, I see.

Another thing that came to mind is something that's a problem in most RTS games; once you overpower your enemy he doesn't really stand a chance but you still have to go about the tedious business of clearing out all of his hideouts before you beat the level. Varying win conditions, AI that surrenders, systems for kicking loosing teams back into the game or secondary objectives that can provide a challenge even when you are winning the main battle could be employed to counter this, I guess, but on the other hand some players (myself included) thoroughly enjoy overpowering a weak enemy's last defenses so maybe it's not a problem at all.

Something to think about, at least.

First things first, I really liked the game. Great work!

Fullscreen works fine on my 4:3 display (Didn't notice any aspect differences between that and the widescreen display).

Also, what kind of changes are you evaluating? I guess I could read the PGC thread, but it seems like a good idea to sum it up here. Myself, I would like to see some more differences between asteroids (size of the visual representation, amount of trees you can plant, max number of agents they can hold etc) ... It would also be nice to have shortcut keys for sending, say, one-half or one-quarter of the agents, but maybe these things have been said already.

What do you consider a programmer? Do you want people with some sort of education or just some "I can write hello world in C" kids right off school? For the latter this may be challenging but the former should really be able to do that. If somebody cannot implement a simple Dijkstra or A* search algorithm, he's no programmer

A very valid point, but it's not so much that we don't expect people to know these things, rather we don't want to include things in the test that we're not going to be looking at anyway - seeing as we want as many as possible to apply they shouldn't have to do any unnecessary work in order to complete the task.

We will provide systems for rendering and input as well as assets, for the same reasons. Now, if people want to go the extra mile and do it themselves then by all means, but seeing as low-level rendering is done by the engine programmers it's not likely to be of importance.

I'd mention a few abstract key aspects like maintainability, changeability, application of design patterns, etc. and see how they realise them. Also consider not choosing something too generic and well-known, in order to reduce the risk of them copying somebody else's code

Yeah, maybe pointing out what the applicants should think about instead of just dropping the SDK in their lap is a good idea. I'll be sure to keep it in mind, thanks!

As for not choosing something too generic, we talked about that and while it certainly is something we're trying to avoid it's just a test to see who gets an interview. Any cheaters are likely to get caught in the interview or when their references are checked, and the worst case scenario is that they'll have to leave during their trial employment.