Tag Archive for 'zinger'

Blog updated

I decided my blog needed to be tinkered with. I didn’t do an overhaul or anything, just messed with fonts and added some more CSS3. I uploaded two more headers into the rotation, too.

I need to start writing more about what I’m working on. People are always asking me and I never know where to begin. Here’s the thing: I’m always working on something. What it is can be totally different each day. Although right now I’m pretty focused on Zinger!. We’re closing in on the deadline for the Fretta Contest and we’re really excited about it. Not much is left, actually we’re just finishing up a few odds and ends.

I’m going to be writing a few articles related to Lua soon so you can look forward to seeing those. Actually I’ve already started… I just need some spare time to finish the first one (work has kept me so busy lately!). Technically I shouldn’t even be writing this now, I should be writing those… GOTTA GO!

Zinger! Gameplay Introduction

(this post will also serve as a test of WLW… thanks Garry!)

 Zinger!

Work! Work! Work! We’ve been busy on the newest installment of Zinger! designed to be a contest entry for the Fretta Contest.

For those of you who played the original, there has been some changes to the gameplay. We haven’t discussed much of the gameplay in the contest thread, so let me go over what we changed and why:

 

Teams

 Blue Birdies FlagIn the original Zinger! it was 1 vs. all. This was fine and we had great fun with it, but most of the time people teamed or paired up and beat the crap out of other people. Which again was just fine, but it normally pissed said people off because they didn’t have a chance in hell of winning. The other problem was as much as everyone wanted to mutilate others with their weapon arsenal, they had to focus on getting to the cup first or they end up losing anyways. So now, with teams, you can work together by helping one guy get to the cup while you collect items to protect him.

 

Asynchronous Turns

Many of you are probably thinking “wtf does that mean?”. Basically it means everyone has a turn at the same time, you’re not waiting on each other. Once you hit your ball, the game waits for you to stop moving then its your turn again. You don’t have to wait in a queue for your entire team to go before its your turn again. Why did we do this? Simple answer: Speed. In the previous Zinger! you spent a lot of time waiting for your turn to come around, which led to a lot of down time. We wanted to remedy that. This accomplished two things: a) less waiting around doing nothing, and b) increased the speed of the game dramatically.

 

Rings

We wanted to give the mappers the ability to create a less linear hole. Instead of just Ringsstarting at point A and trying to get to point B, we added in a feature to move the players around in all different directions. Basically there are a set amount of rings the mapper places on each hole; your team needs to go through each ring before you can finish the hole and sink the cup. This added in another element to the teamplay environment: working together to activate the rings as fast as possible while making progress toward the cup.

 

Randomizing

No longer do you have hole 1, hole 2, hole 3, and progress through in the same order each time you play a map. Now, all the holes are randomized and played in a different order. We’re also considering randomizing the rings, as in, let the mapper place 8 of them but only spawn 4 random ones.

 

Tee Off

Tee Off

The mapper also has the ability to create more than just 1 tee per hole; actually we’d prefer they make 2+ tees. 2 of the tees would be picked at random and assigned to each team. Once the hole starts, teams tee off player by player. Once the last player has teed off, the tee is removed.

 

This should shed some light on what we have planned. Remember, this is all preliminary and we reserve the right to change anything/everything before the official release.

From the ground up

Even though most of us are slightly derailed with real life shit, Arcadium Software has continued to progress on our flagship game, Zinger.

One interesting thing I keep reading on different sites is people referring to XNA as a beginner language for writing games. Although it can be interpreted this way, I have to disagree. In my opinion XNA (or C# w/ the XNA Game Studio… whatever) isn’t as much of a beginner language, but more that it has the possibility to be a rapid development language.

Yes, working with managed code is always easier than unmanaged code, but that doesn’t mean its anymore beginner friendly than the next. There is just as much of a learning curve writing C# applications as there are C++ applications. In the first few steps of writing a C++ application you echo “Hello, World!” to the console… and in C# its pretty much the same thing except you’re printing “Hello, World!” to a windows form.

Aside from that, coining it as beginner tends to assume it lacks the ability to be mastered… that there’s a skill cap on it. I’ve only been working with XNA a few months now and have already learned things I wish I knew at the start. Which is a perfect segway into the meat of this post…

When we first started writing Zinger it was with the mindset of “hurry! go go go go! do it! do it!”. We didn’t pay much attention to anything other than making leaps and bounds of progress. And it worked really well! We accomplished goals and milestones we could only dream about in the past. Only problem was the code became so concrete in its current application it made us worry. What if we want to use this code in a different game? Would we need to tear it all apart? Would it even be worth the effort?

About that same time we also started to notice a few issue with some of our implementations. There we limitations on features we knew needed adaptability down the road. Things like the GUI scaling properly as the resolutions changed while in-game… or the XML based menus requiring tricks and hacks for displaying screen resolutions. If you’re writing anything from scratch, you should NEVER have to use a trick or hack to make something work. Yes, I am personally responsible for most of the problems but hey… I’m new to the language and we didn’t set out to make an engine. That had to change.

After exploring a variety of artist styles, we’ve designed a new style of graphics we want our game to use, and we’re going to write an engine tailored to it. Why? Because we absolutely love the style and its very unique. Once we’ve completed the engine and Zinger, you will forever recognize the style to be an Arcadium Software product. Sort of how you can play almost any Source Engine game and say “yea, this is totally the Source Engine”.

As much as I would like to refrain saying we’re rewriting what we had from scratch, that’s exactly what we’re doing. Except now we already know how to do everything and have our code right in front of us to reference, which speeds things up tremendously. This time we have the right layout and I can’t even begin to explain how much better its already turning out.

In before tl;dr

Zinger! progress and stuff

New splash screen, the sunbursts are actually animated so they spin around… quite a trippy effect in full screen:
Arcadium Software

We made that for S & G’s. And now for a something completely different:

Chad started some clientside interpolation for our prediction. Our goal is to have a smooth and enjoyable multiplayer experience. Basically what happens is the client (you) doesn’t rely on the server 100% for exact values of visual things like, for instance, the position of a ball. If your screen rendered exactly what the server told you and the game happen to have a little bit of lag, you’d see the ball warp across the screen. Instead using prediction and interpolation, it smooths out the movement to look more realistic even though the lag is still there.

Additionally, Chad just barely started implementing the physics, BulletX. Really looking forward to see what he’s going to manage.

Me? I’ve been doing crappy shit like advancing our GUI library to include tools for building a settings menu and shit. It’s really boring and I can’t wait till its done. Even though I hate it so much, I know its really needed. Such a simple tool yet so necessary for any decent game. Some games missed out on this feature and it really shows the lack of attention to detail. Although Infiniminer is a wicked fun game, it really blows ass to have to exit the game and edit a text file to change settings… oh well.

I’ve also been reworking the audio system thus far. Mainly improving performance and moving away from the MediaPlayer library. That thing sucks all sorts of donkey anus and I won’t go into how laggy it can be (you play a song and it waits 3 seconds while it blocks the rest of the application before you can actually hear anything).

I also emailed Steam, which you can keep up-to-date with here.

Zinger: Milestone 2

Zinger screenshot

Not going to bother reposting everything here, so visit this link.

Zinger! XNA

arcadiumlogo

Arcadium Software is well on its way into the Zinger! game developed in XNA.

Chad and I have had our struggles trying to create a game… mainly because we go “too big”. For two guys programming a game in their spare time, its a bit overwhelming to try and write a fully networked game engine from scratch… and then create a game for it. We gave it a shot but it was just a bigger undertaking than we had expected.

Seems like we couldn’t get our footing when it came to developing a stand alone game. We went back and forth on a “company” name (I use that term loosely, as its just a branding we’ve put on the software we develop), then it was the game engine itself, which we kept redoing and redoing from the ground up… ugh! What a mess!

We finally found the sweet spot. Not only do we have a name we love, but a game we love too! We said the hell with doing it all from scratch and use what tools are available to us out there. XNA has been a godsend! Sure its managed code and adds some prerequisites for the end user; like .NET Framwork 3.5 and XNA 3.0 Runtime, but it speeds up development time exponentially!

So far we have a working GUI, console and basic commands. Plus we’ve been able to connect to the server and transmit data back and forth (including syncing entities). We’re super excited!

One thing that’s really helped is we’ve set milestones for ourselves. Stuff like “compiling a level by tomorrow”, “connecting to the server in the next 6 hours”, “syncing the entity list by yesterday”. These are what keeps us driven and going in the right direction. We don’t always code the cleanest, but once its working we go back and sort it all out. SEEING our OWN progress has helped so much too, keeps us motivated.

If you want to see what we’ve got so far you can download it here. There’s no server to connect to right now, but enjoy anyways. Make sure you download the stuff I mentioned above.